 So access control is controlling who can do what on our system. We'll talk about the some general concepts. Then we'll go through three different types. And they're quite similar. Discretionary access control. We'll go through first and we'll see that using our Linux file system as an example, we'll see discretionary access control. Role-based access control has some similarities but doesn't talk so much about users. It talks about roles of users like manager, lecturer, student as opposed to user one, user two, user three. So some slight differences. And mandatory access control very briefly we'll mention is like you've heard of top secret. Top secret, confidential, we'll see how they are used for mandatory access control. Let's go through some concepts. A definition, access control. The prevention of unauthorized use of a resource including the prevention of a resource, use of a resource in an unauthorized manner. So we try to stop people using our resources when they're not authorized to do so. What resources? What resources are we trying to protect? What's an example of a resource? With respect to computer systems what could a resource be? A file. A file is a resource. But other storage items so it could be part of a file. We could be very fine grained and try and protect certain parts of a file. Parts of memory. Memory is a resource. Hard disk. Parts of a database. So the database or the objects in a database blocks on a disk. They are all resources. So where we store information can be resources. Pretty much in most of the examples we'll use we'll talk about files. Because they're easiest for us to picture. But other resources may not be file based. So it could be to execute, to use the CPU, to execute a program, to run a program. So we want to control who can do what on our computer. The general setup, we have our system resources. We have our files, we have our databases, the information on our system we want to protect. And there are four main functions that are involved. We have our normal user who wants to access those resources. So first we need authentication. How do we authenticate our user? Passwords, say. So the previous topic on authentication is about checking if this user is allowed to access the system. Confirming who they are. Is this person really Steve or is it someone pretending to be him? So we know how to do authentication. And then once the user is authenticated we have an access control function which determines once they're allowed to use the system what can they do with our resources. Because just because they can use the system it doesn't mean they can do anything they like. We would like to restrict what files they can access and what other resources they can access. So that's the role of access control. To set to work someone has to be the administrator and say set the policies of what this user is allowed to access. So the administrator says this user is allowed to access these files. And that comes from the policy of the organization, the company, the university, the owner of the system. So they have some aims. The student user is only allowed to access these particular items in the database. So they would perform the authorization and they would authorize particular users to do and access different resources. And then we use the system and hopefully it works. Well we don't just hope we would normally do some auditing and check that it works. So we do some monitoring and check that we set up our access control. This user is allowed to access these resources. Maybe we'll do some logging and check, is anyone else accessing those resources? Or is that user accessing other resources? So some auditing would check whether our policy is being implemented correctly and maybe give some feedback to fix it if it's not. So four steps there or four functions. Authentication, access control, authorization and auditing described there. Access control, control what the users can do with resources. Authentication, check who the user is. Authorization, grant or revoke permissions. And auditing, check that everything is working correctly. Make sure that our implementation meets the policy. We're going to look at access control. There are three types of access control policies. We call them discretionary, mandatory and role-based access control. We'll go through each of them. First, they are not mutually exclusive, meaning you can combine them. You don't just use one and not the others, you may use a mix. So some go together. Discretionary and mandatory are quite similar. Discretionary access control, the user, let me say the ID of the requester, the someone who wants to access a resource, we use their identity to control what they can do with it. For example, the resource may be a file, the identity may be the user's username and we may have permissions on that file, read, write and execute. So that's an example of discretionary access control. Why is it called discretionary? In this type of system, the users are allowed to modify what people can do with resources. So a user may be able to say, has some discretion to say this file that I own and I can read, I'm going to change it so someone else can also read it. So they've got the discretion to make changes. In mandatory access control, they don't. The users cannot change the access to resources. They are fixed by the administrator at the start and they don't change. So it's a more secure approach and you will see this is similar to the concept or uses the concept of like security clearances. Top secret, secret, confidential. We'll see that when we look at mandatory access control. Role-based access control is like discretionary, but we don't really think about individual users. User Steve can do this. We think about roles. The lecturer has these permissions. The head of school can do these things. A student can do these things. A student in this class can do these things. So we talk about the roles of the users. So we'll quickly go through those three. Before we go through those general requirements, let's first introduce the basic elements. We'll talk about a subject, an object and an access write. The subject is the entity that is capable of accessing the resources. Sometimes we think it's the user, the human. But often the subject is actually a piece of software. When you're using your operating system, you've logged into your computer and then you click on some keys or run a command, then the operating system determines whether the software you're using can access the file or not. So the subject, in fact, is that piece of software that's trying to read the file. But we often think of that piece of software as being run by a particular user. We'll sometimes classify or group subjects. And if you're familiar with Linux and most of you are, now you know we can have groups like the owner of a resource or the non-owner or a group that's related to the resource or everyone else. So we'll see that we can classify or have classes of subjects. The object is the resource. So instead of resource, sometimes we'll say an object. And it may not just be a file, it may be parts of files, it may be blocks on a hard disk, pages in memory, directories, not just files but directories, but other things, database entries, database objects, emails, email inboxes, software. Communication ports are ways that we can communicate with other pieces of software or other computers. So the subject has tried to use these objects. They have rights. The access rights describe how the subject can access those objects. And there are different types of rights. Different systems will use different terminology and have different meaning. Some of them may be to read an object, write to an object, execute, and you've used Linux a little bit so you've seen read, write, and execute. But they don't have to be called that. They can be called other things. We can talk about a delete right. Do you have the right to delete that object? Create. To create a new object. Search. Maybe write, maybe split into different sub-permissions or sub-access rights. Different systems will have different set of access rights, but usually they'll be defined up front. So a subject accesses objects and in the way described by the access rights. What's another name for access rights? It starts with a P. I may have used it. Permissions. So the permission that you have to do something. Sometimes we talk about the permissions on the file, the access right, objects or resources. What do we skip here? In all of the access control mechanisms, we'd like to build a system that meets these general requirements. I don't know if you need to remember them, but we'll go through them. To have correct access control, we need reliable input. That is, we need to know that it's the correct user. So the authentication must work correctly. If the system allows someone to take my username, then the access control will not meet the requirements. So we rely on the input of the system to be correct. Fine and coarse specifications. Fine specifications means, say, we can go down to a very fine detail and say, this user can access this part of the file at this time. It's a very detailed course. May mean that we can group things and say, this set of users can access this set of files. So sometimes we'd like both. Sometimes we need to have very fine grain control. Sometimes we allow very coarse specifications and say a group of people can access a group of files. So it's easier. Least privilege is a principle that is we should... When we give privileges for users or permissions, we should give the least which is sufficient for that user to do what they need to do. An example, I am the... If I'm the instructor in the network lab, then as the instructor I may need to do things more than the students do, but I don't need to maybe install software. I don't need to run all the programs. I don't need to access all directories. So least privilege principle means that set up the access control so that I can only access what's needed to do my job as the instructor. Don't give me access to everything. Even though it's easy just to say, okay, you can do everything because you're the instructor, give me the least privileges that are necessary for it to work correctly. Don't give it me more than I need. That's the idea there. Similar comes in, you're trying to apply that principle when you log into your Windows system. Who do you log in as? Do you log in as a normal user or an admin user? Well, admin, if you log in as admin, then you're not using the principle of least privilege. You should log in as the normal user because you don't need those privileges of the admin user most of the time. Most of the users, they don't need to be admin to run their game or to open Microsoft Office so they should log in as the normal users and they get the privileges necessary to do what they need to do. And that gives less chance of things going wrong, making mistake and getting access and doing the wrong things with different resources. Separation of duty means that similar to the least privilege that the users or in an organization we should say that particular users have particular roles or duties. So like the instructor, his duty is to set up the computer to reboot everyone else's computer and to display some slides. This one's just saying that we should assign duties to different users so that we can have least privilege for those users. We shouldn't just say everyone does the same. That's not a separation of duty. Normal users in an organization have different duties, so we should make sure that they are allocated. Open and closed policy is the normal one we think of. A closed policy in access control says that you're allowed to do these things, you're allowed to access these resources, anything else that's not specified you cannot access. So we specify what you're allowed to do. By default you cannot do other things. For example, the file permissions are set up so that I can access three files, I can read three files. Every other file on the file system, by default, I cannot read. That would be a closed policy. The norm, I specify what I can do, everything else is closed to me. An open policy is the reverse. The system specifies what I cannot access. You cannot access this file, you cannot access this file. All other files you can access. That's an open policy. And that's not very common and generally considered less secure, but maybe needed in some cases for convenience. An open policy means the system specifies what you cannot do, everything else by default you can do. That's open. So depending upon your requirements, you may choose one of those. Most of the examples we'll see are closed policies. What else? In some systems we can say, okay, the instructor user is, so one policy may say, the instructor user can access file X, but another policy may imply that the instructor cannot access file X. So we have a conflict. What do we do in the case of the conflict? The conflict may come at the policy level, that is, that's our aim. The instructor can access all files for the students in the lab, but another aim may be the instructor is not allowed to access this particular set of files, and there may be a conflict amongst those policies. So we often need ways to resolve those conflicts. That will come up a little bit in role-based access control. We need ways as who's the administrator, policies that say who can be the administrator and what they can do, because the administrator can set the authorizations. The administrator says who can do what, so who is allowed to be the administrator, then an organization needs to set that policy. This may not be set in software, this may be set at a policy level within an organization. Last one, dual control means we'd like in some cases to have multiple people access the same resource in parallel at the same time. You can think of this as two people can supply a key to unlock something at the same time, and they both need to supply the key for it to be unlocked. So some systems would like to allow the dual multiple people can control what we can do with a particular resource. In Linux, you'll notice that normally the user controls what they can do with the resource. We're allowed to have multiple people do that. We may see an example shortly. Let's introduce discretionary access control today. Very simple concept, because you've dealt with access control in practice. What we do, an entity may be granted access rights, and that may allow that entity to give rights to other entities. That is, an entity may be able to access a resource, a file, and they may be able to say other people can also access that file. So this is the discretionary part. The entity is allowed to change who can access that resource. And you've done that in Linux command line. You've sort of seen with changing the ownership of the file, changing the group. So if you own the file, you can change the group that owns the file, essentially giving other people access to that file. So you're allowed to make changes to the access rights. You're not the administrator of the system, you're the entity using the system. With mandatory access control, you'll see you can't do that. You cannot make changes to what the current access rights are. In discretionary, you can. It's very common in operating systems, in Linux and Windows and others, and in database management systems used in the back end for websites as well. The way that it's implemented, there are really four different approaches. We can think of an access matrix that specifies the rights of subjects on objects. But a matrix in practice will often be very large and many entries will not need to be specified. So we'll say it's a sparse matrix. So we'll often either implement it as a list of who can access which objects, access control lists and capability lists, and maybe even a table. And the next four slides show those four implementations. Very simple examples. An access control matrix. Here we have four objects and three subjects. A very simple system. And in the matrix in each element, we specify the access rights. What can user B do with file three? So if we have file three on the system, user B tries to do something with that, then this matrix says the only thing user B can do with file three is right to that file. So this would be implemented by the operating system. The operating system has this matrix stored. When user B tries to access this file three, the operating system checks. What can they do? Well, they can write only. If it was user C on file one, the operating system would see they can read and write. So we have access rights, objects and subjects, and the access rights are specified in the matrix. Now this is not these access rights. Let's look at the examples. What do they mean? What does own mean? Here in this example, we can think of it, they own the file. Usually ownership of the file means you can change the access rights. If I own the file, I can change what others can do with that file, and even change what I can do with the file. So if I'm user A, I own files one and three. Currently I can read and write file one and three. With discretionary access control, I may be able to change it so that I cannot write file three. So I've got the discretion to make changes to the access rights. Usually one file or one object is owned by one user, but it doesn't have to be the case in general. But normally it would be a single owner. So here we just have own, read and write. What does, what can user B do with file three? When it says write, what do you think they can do with file three? Can they open it and look at the contents? Maybe not. Okay, so that's a bit confusing. They can write to it, but they can't read it. So if they can't open the contents, what can they do with it? If they can write to it but not read, what can they do with the file? If you can't see the contents, how do you write to it? Let someone else write, maybe user A can read it. But what can I as user B do with this file? I can't read it to see the contents. Maybe write means also delete here. Write often means delete. If I can write to the file, I can actually delete the file. Because really deleting means replace all the contents of the file with nothing. To delete a file. So commonly write means delete. So maybe I can delete the file even if I can't see what's in it. But that may be not so common to see just the right access right. This is the same matrix but adds a set of access control lists. So the problem with a matrix on your laptop, on your Mac, how many files do you have? Give me an order of magnitude. Approximately, guess. A thousand is a very limited operating system with a thousand files. I would guess tens of thousands of files maybe. So we have thousands, tens of thousands of files in a normal computer. So we may have hundreds of thousands of objects. And in large computer systems, not just your laptop which may only have a few users, but in large multi-user system we may have hundreds, even thousands of subjects. So if we have thousands of subjects and hundreds of thousands of objects, this matrix becomes very large. And many of the elements in the matrix would be empty. So let's say I have a hundred thousand files. Many of those files users will not be able to do anything with. The operating system files the normal users may not be able to read or write or execute. So you'd think that the elements would be empty in those cases. So we'd have a very large matrix. Most of them would be empty. Only a few have entries in them. So using a matrix doesn't make sense. It's a little bit wasteful. So here's the same information but expressed as a set of lists. An access control list. One list per subject, sorry, per object, per file. File one has a list that says user A owns the file. They can read and write. User B reads and user C can read and write. And if you check back to the previous slide, file one, it's the same information. User A owns, read, write. User B read, user C read, write. File two, similar. For user B and C, file three, A and B. So in this case, each file, each object, has a list that determines what subjects can do with it. If a subject's not on this list, what can they do with it? In the case for file B, what can user A do? They can do nothing. What type of policy is this? Open or closed? It's a closed policy and then we say that if we specify what the users can do, if we don't specify, they can't do anything. It's closed to them. That's what we mean by a closed policy. The default is you can't do anything. This is just a more efficient implementation of a matrix. But if you check, it's exactly the same access control. This is exactly the same, but it's swapped. For each user, specify what they can do. User A can access or own, read and write file one and three. User B can do things on four files. User C on those three files. So just the opposite dimension from the access control list. And if you want, you can express it as a table. Subject A has access rights on objects, files. Access rights are sometimes called access modes. And your expert are changing the access mode because you change, use the command chmod, change mode in Linux. Change the mode of which a subject can access an object. So these four are examples of the exact same system, but just different implementations. And depending upon your application or system, you choose one which best suits your needs, normally of the last three. What we'll do is next week we'll talk about the other two, role-based and mandatory access control, and then go through a few more examples on Linux, on the command line, show a few things that we can do with changing the mode and changing the ownership and see access control lists. Access control, we said, is about controlling how users can access resources. Those resources may be files, but they may be other objects on our computer system, parts of memory, database records, parts of files. And the users, we talk about the subjects that access different objects. And we said there are three types, discretionary, role-based, and mandatory. We briefly introduced discretionary access control, and it's the common one that we come across. Our file systems, our operating systems, normally in the normal mode use discretionary access control, where we use some data structure to keep track of who can access what. So we have a set of objects, a set of subjects, and a set of permissions or access rights for a particular system. And we define what subjects, what access rights subjects have on the objects. So one way to think of that is as a matrix, we say the subject user B has the access right of read on the object file one. So we define for all the objects in our system and all the subjects, all the access rights. Of course the access rights need to be defined. What does read mean? What does write mean? And different systems may have their different definitions of that. But often we interpret read, meaning we can see that object, the file contents, write, meaning we can modify, usually including delete, but sometimes delete can be a separate access right. Ownership usually means that we can, in a discretionary access control, we can change the access rights. The discretionary means the subject has the discretion to change these rights. They're not fixed. So if I own an object, it usually means I'm allowed to change the access rights for other users for that object. If I own file one, maybe I'm allowed to set user B so that they can now both read and write file one. So that's the discretionary part. In mandatory access control, the users cannot do that. The initial access rights are set up by the administrator and then they're fixed. So that's the key difference between discretionary and mandatory. So mandatory we'd consider more secure. It's more strict on what the users can do. But discretionary maybe gives the users more flexibility, which better suits many of our systems that we use today. Of course, when you have thousands of files and maybe hundreds of subjects storing this so that you think our computer system, like the operating system, stores this data structure. And every time someone tries to access a file, first the operating system checks. Does this user have the right to access this file? It looks up the matrix. If we have a large number of files and users, the matrix gets very large and many of the entries are empty because many of the files, users cannot do anything on them. So it makes sense to sometimes have a different data structure that stores the same information. We can do it per file. What different users can do with the file? So for every file, store some data structure, a list that says what the subjects can do, what access rights they have, called an access control list, capability lists, so per user, what this user can do. So you think the operating system will keep track. For every user on the system, it'll have a data structure that says which files that user can access and what rights they have on that, like in this case, or an alternative, some form of table. So the system keeps a table in memory that says for all, so one row for each combination of subject, access right and object. The other way we describe access right is permission. What permission do they have, or access mode? Mode, right or permission usually means the same thing here. So they're just different ways to store that information. We'll talk about the other two techniques now, and then we'll come back to discretionary with maybe a bit more of a detailed example using Linux. And you're all experts now using basic permissions in Linux because you've done it in the lab. So we'll just show a few different examples with Linux discretionary access control. But first let's talk about the others. Role-based access control. The users are assigned roles. So, you know, discretionary, the users are the subjects. Here the users are still the subjects, but they are all assigned a role. And access rights are not assigned to users but to roles. So someone in this role has the right to access this file as opposed to a user has an access. And this usually closely aligns with the job functions in an organization. For example, the role may be student, undergraduate student or graduate student, staff member, faculty member. So the roles that may be assigned depend upon the organizational structure. In a company, maybe programmer, software tester, engineer, manager, finance officer. So the roles depend upon the organization. Particular people, the subjects are then assigned to one or more roles. For example, in the university setting I have a role of faculty member. You may have a role of student. Our head of school, Dr. Egwit, may be the role of faculty member and may also take the role of management team in the executive team for the institute. So users may be assigned multiple roles and it may change. It may be a static at the start and it's set and fixed or it changes. The roles may change during the operation. We may be able to temporarily assign users to roles. So just for a short case, I may be able to assign a faculty member to a role of a student. I may take the role of a student. I'm a faculty member, so that's my normal role, but for testing or for seeing what the student can do, I may be able to temporarily assign myself to be or be assigned to be a student. So that I can do the things a student can do and see what they can access. And many web-based systems use this type of access control. For example, you have the role of a student in the course. I have the role of the instructor, but I can temporarily change my role to be student. So when I log in, I see what a student sees. I may see the grades of students and I cannot see the quiz answers as the role of student. So that's used in some systems. To implement this, we basically have two matrices, two data structures, one that maps users to roles and one that maps roles to objects, the access rights. Here's an example. A general example, the first matrix on the left is a mapping of users to roles. So the columns are roles, R1 through to R4 or RN, and the rows are users. So we have a set of users in our organization and we define what roles they can take. For example, user 1 may be student, user 2 student, user 3 faculty member and executive team and so on. So some users may take multiple roles. So our system must keep track of this mapping of users to roles. The access rights are defined per role. So the second matrix, it's a bit confusing. What have we got? On the rows are the roles and on the columns are the objects. I can't remember why it's RF and so on, I think file, process, maybe disk and another resource. But think of the columns as just files if we have a simple system or the objects and the rows are the roles. So whoever is in role 1 can have these permissions or access rights on these objects in the columns. So this is similar to discretionary access control except we don't specify access rights per user, we specify per role and users can be in different roles. So this is common in systems which are closely related to how the organization is structured. So many web-based systems, many company applications, company-wide applications which have access control may use role-based access control. Whereas a general-purpose operating system like Windows or Linux on your computer normally uses discretionary access control because there's no definition of roles. There's no close relationship. So as the administrator what you need to do is to find the access rights per role. What can a student do? What can a faculty member do on different objects? And as there are new users next semester there's another 1,000 users join. We don't need to change the access rights. We just need to add those new 1,000 users to the role table to say those new set of users all have the role of student. There's no need to modify the access rights because the access right is specified per student, per role. So that can simplify the management and it makes it easier when we have that clear separation of roles. In the arrangement of the roles there may be some hierarchy in way they are connected with each other often associated with a hierarchy in an organisation. So many organisations have a hierarchy. There's the boss and there's people under them and there's some teams and so on. So an example in this picture the roles may be based upon the job functions. So the engineering department has some engineers those engineers have different specific roles so an engineer may be a production engineer or a quality engineer in terms of software maybe there's a software developer and more specifically maybe there's the software designer software tester quality assurance and so on. So different roles as what a software developer may have. There may be teams. So there may be a set of engineers in a team and some project leader or manager and a set of projects or leaders or report to a director. So there's usually some organisation or some hierarchy in the organisation and with the roles we also reflect that hierarchy and it's common that we will allow that a higher role may include access rights of a lower role so whatever the production engineer can do we assign the access rights to that role they may be inherited by the project leader if they are higher up in the hierarchy. So that's one thing that we can do with role-based systems and explicitly defined in a table such as this the engineer has these access rights but if we also define the hierarchy we could say anyone who's the leader of an engineer inherits those access rights. So that's a little bit easier to manage because again we just specify the access rights per role but those rights can be inherited by other roles depending upon the hierarchy. So some computer systems, web-based systems will allow you to have a third data structure which defines the hierarchy, the relationship between the roles and you may have other constraints on the roles so something that defines how the roles are related or some conditions on the roles. For example, so some of them are listed here some examples, we could say a higher role includes or inherits all the access rights of the lower role so that's one constraint or condition we can allow in the system quite easily. If the faculty member has these sets of access rights then the boss of the faculty member automatically inherits all those access rights so that would be easy to allow that. We may have mutually exclusive roles but as a user, we said a user may be able to be defined to take multiple roles but we could set up some conditions such that they can only be in roles of a particular set at any one time. That is you can be in this role but if you're in that role you cannot be in another set of roles so the system could be set up to control that. There can be some limits on the roles. For example, the maximum number of users assigned to a role the director, maybe the maximum number of people that can have the role of the director is one because within the organisation there should be only one boss in the organisation or a user cannot be assigned to more than some number of roles so a user maybe there's a limit they can only be assigned to two roles at any one time so by allowing our system to set these limits it makes it easier to administrate the system less chance of things going wrong less chance of assigning someone a role that gives them an access right to do something that they shouldn't be able to do and that's the difficulty with access control ensuring that users can only do what the system intends them to do what the policy allows as you have a large number of users that becomes a difficult challenge so having some limits on things simplifies it you can have limits on the number of roles that can be granted particular rights how many roles can allow access to a particular file or database and you can have prerequisites for example a user which has needs to be assigned to say a senior programmer role they can only do that if they're in the past they've been a junior programmer so there may be some connection between the hierarchy and you must take one role before you can take another role so in brief role based access control allows makes it easier to administrate systems especially when those systems have some hierarchical structure in the organisation and the set of users because it allows the administrator the person who sets up and applies the initial access rights to do it not per user but per role and also to place some constraints or limits on what those roles can do the third technique, mandatory access control here we compared to discretionary access control we consider a stricter form of access control and the idea is that once the access rights have been set up by some administrator then they cannot be changed those access rights are mandatory we have no discretion to change them and it's based on the concept of what's called multi-level security one example of multi-level security is we give objects some classification at different levels so an example of levels so we don't have to use these levels but one that is used in a military context or in a government context we can think about objects maybe top secret secret confidential, restricted, unclassified that's one example of having five different levels where one is greater than the other this is called a classification if we apply it to objects and then users the subjects have a clearance level so if you are cleared at secret level you're a subject, your clearance is secret what can you do with an object which is classified as confidential what can you do with that object what do you think? if you are cleared at a secret level in this example and you want to access an object which is classified at the confidential level can you access that object? yes we have multiple levels defined where we say secret is greater than confidential and we have the ability that if we are classified an object say confidential if we are cleared at a higher level then we can access or read that object so we normally say if we are cleared at a higher level than the classification we can read that object the file or the resource so if there is a document which is classified confidential if you are cleared at secret then you can read that document that's the concept if you are cleared at secret and there's a document marked top secret are you allowed to read it? you are cleared to be secret there's a document marked top secret are you allowed to read that document? I say yes, I say no hands up for no right we are secret so the object is top secret classified the subject is cleared to be secret top secret is above secret so you cannot read something that's at a higher level than you and this is the concept of no read up a subject can only read an object of a less or equal security level if I'm cleared at secret I'm allowed to read anything that is classified as secret confidential, restricted or unclassified but I cannot read anything above me that's the concept of no read up now we don't need to use these five levels just one example you can have a different set so the next property no write down let's say what it is and then try and answer why so that we require two properties no read up no write down the subject can only write into an object of greater or equal security level so we talk about the permissions of read and write I cannot read something that is classified above me no read up and I cannot write to something which is classified below me why? that is if I am cleared to be secret and I'm trying to write into a document which is classified as confidential I cannot why? why do we want this property? so that's the requirement why? what does that prevent? I'm cleared as secret I'm not allowed to write into a document marked confidential no write down what's it provide for us? so it's not so obvious that one no read up this information from one higher level down to a lower level because we want mandatory access control if something is marked as secret I cannot as the user I cannot take that content and make it at a lower level if I could write to a lower level what I could potentially do is I read the document marked top, marked secret I am cleared as secret so I can read it if I can write that down to a lower level then someone else at a lower level can read what was originally secret so if I can write my secret document as confidential then someone who's cleared at confidential can now read that content which was secret so we cannot allow the user to move content from one classification down to another and that's why we have the no write down property to prevent a user from releasing information from a high level down to a lower level so we can't read up we can't read what's above us and we cannot write into lower levels any questions on those properties are they clear you answer a quiz question about that or an exam question explain no write down why so we don't release the information inappropriately not so hard these access control schemes very quick on them now who sets the clearance and classification it's set by an administrator so if you remember back to the first picture on these slides there's always an administrator to fix them in discretionary access control the administrator sets the original access rights but the users can change them in mandatory access control the admin sets the clearance of all objects sorry the clearance of all subjects the classification of all objects and they cannot be changed it's mandatory and that's why we need these two properties such that we cannot release higher level information down to a lower level there are different ways to model and analyse such systems so there are different mathematical models or approaches to define this because this is trying to provide very strict security and it's important that the techniques that are used do not allow inappropriate access so mandatory access control is used when we need a high level of security most operating systems use originally discretionary access control many web based systems or applications for organisations you'll see start to use role based access control some specialised systems will use mandatory access control and in fact with your operating systems you can enable mandatory access control if you want to have a very secure operating system then you can turn on the features that force it to use mandatory access control more secure in that there's less chance of for example a virus infecting and writing to the wrong files or writing to files so that the virus can be executed that's some of the implementation so most operating systems have features that you can enable that implements mandatory access control Windows has something called mandatory integrity control BSD, Linux and OSX also have features that you can turn on usually not enabled by default normally they use discretionary access control so that summarises the three approaches to access control they are not mutually exclusive you can combine them so you can use some components of each but it's important to be aware of the three we'll go through an example now just on the screen of showing some cases of Linux access control discretionary access control which I think most of you know about or are aware of but we may introduce one or two new things as we go and then we'll summarise well the summary we can look at access control prevent unauthorised use of resources we can talk about subjects we refer to subjects as the users but in fact on a computer system it's actually a software process that the user has access to so with respect to a file who can read a file well it's a software, a piece of software that reads the file that an operating system controls we often can classify subjects for example owner, group, world but there can be other classifications that's just something we see in Linux examples objects can be files easy to demonstrate as files but they can be other things parts of a database parts of a disk, memory software processes so we can perform access control to say who can run a particular program not just who can run a particular process there are different sets of access rights also called permissions or modes, access modes read, write, execute delete, create, there may be others depending upon the system discretionary access control the administrator sets some initial permissions but users may change them they have the discretion to change them it's common in operating systems databases role-based access control is similar but we now assign users to roles and permissions to roles common in applications for a particular group of users websites, web-based systems organizational software mandatory access control we have defined levels and we can't change them those levels are mandatory and that's used in highly secure systems in all cases that security of the system depends upon the original assignment so the administrator sets some permissions if they do it wrong then the users may be able to do things that they shouldn't be able to do so that requires some human intervention and that can be a challenging task when you have thousands of users and objects so that's a challenge and it will be a challenge that you have to experience on a very small level in your next homework I'll say assign these permissions to these files I will give a general description you must implement that so you need to interpret what the policy is and there are a number of other issues that are interesting regarding access control of how to really with operating systems and even computer hardware the computer is trusted that we can trust what happens all the way from when the computer boots the operating system loads and it loads all the applications that there are no things that can access the resources without the intended desire and there are technologies, secure boot and trusted computing technologies so let's stop there and look at an example