Chapter 6 - 6.2.4
Then along came machines that would run more than one program at once, and the protection problem of preventing one program from interfering with another.
Access controls at the application level may express a very rich, domainspecific security policy. The call centre sta↵ in a bank are typically not allowed to see your account details until you have answered a couple of security questions; this not only stops outsiders impersonating you, but also stops the bank sta↵ looking up the accounts of celebrities, or their neighbours.
The applications may be written on top of middleware, such as a web browser, a bank’s bookkeeping system or a social network’s database management system. These enforce a number of protection properties.
Your Android phone treats apps written by di↵erent companies as di↵erent users and protects their data from each other
Finally, the operating system relies on hardware protection provided by the processor and its associated memory-management hardware, which control which memory addresses a given process or thread can access.
I will start o↵ by discussing operating-system protection mechanisms that support the isolation of multiple processes. They are often described as discretionary access control (DAC) mechanisms, which leave protection to the machine operator, or mandatory access control (MAC) mechanisms which are typically under the control of the vendor and protect the operating system itself from being modified by malware.
These help us tackle the toxic legacy of the old single-user PC operating systems such as DOS and Win95/98 which let any process modify any data, and constrain the many applications that won’t run unless you trick them into thinking that they are running with administrator privileges.
Another way of expressing a policy of this type would be with access triples of (user, program, file). In the general case, our concern isn’t with a program so much as a protection domain which is a set of processes or threads that share access to the same resources
Access control matrices (whether in two or three dimensions) can be used to implement protection mechanisms as well as just model them. But they don’t scale well: a bank with 50,000 sta↵ and 300 applications would have a matrix of 15,000,000 entries, which might not only impose a performance overhead but also be vulnerable to administrators’ mistakes.
When we look at large organisations, we usually find that most sta↵ fit into one of a small number of categories. A bank might have 40 or 50: teller, call centre operator, loan ocer and so on. Only a few dozen people (security manager, chief foreign exchange dealer, ...) will need personally customised access rights.
Some vendors (such as Microsoft) use the words group and role almost interchangeably, but a more careful definition is that a group is a list of principals, while a role is a fixed set of access permissions that one or more principals may assume for a period of time.
Groups and roles can be combined. The ocers of the watch of all ships currently at sea is a group of roles. In banking, the manager of the Cambridge branch might have their privileges expressed by membership of the group manager and assumption of the role acting manager of Cambridge branch.
The group manager might express a rank in the organisation (and perhaps even a salary band) while the role acting manager might include an assistant accountant standing in while the manager, deputy manager, and branch accountant are all o↵ sick.
The traditional way to simplify the management of access rights is to store the access control matrix a column at a time, along with the resource to which the column refers. This is called an access control list or ACL (pronounced ‘ackle’).
ACLs have a number of advantages and disadvantages as a means of managing security state. They are a natural choice in environments where users manage their own file security, and became widespread in Unix systems from the 1970s. They are the basic access control mechanism in Unix-based systems such as Linux and Apple’s macOS, as well as in derivatives such as Android and iOS. The access controls in Windows were also based on ACLs, but have become more complex over time.
ACLs are simple to implement, but are not ecient for security checking at runtime, as the typical operating system knows which user is running a particular program, rather than what files it has been authorized to access since it was invoked. The operating system must either check the ACL at each file access, or keep track of the active access rights in some other way.
Finally, distributing the access rules into ACLs makes it tedious to find all the files to which a user has access. Verifying that no files have been left worldreadable or even world-writable could involve checking ACLs on millions of user files; this is a real issue for large complex firms.
In traditional Unix systems, files are not allowed to have arbitrary access control lists, but simply rwx attributes that allow the file to be read, written and executed. The access control list as normally displayed has a flag to show whether the file is a directory, then flags r, w and x for owner, group and world respectively; it then has the owner’s name and the group name.
However if this is zero (root), then the access control decision is ‘yes’. So root can do what it likes – access any file, become any user, or whatever. What’s more, there are certain things that only root can do, such as starting certain communication processes
This means that the system administrator can do anything, so we have difficulty implementing an audit trail as a file that they cannot modify. In our example, Sam could tinker with the accounts, and have diculty defending himself if he were falsely accused of tinkering; what’s more, a hacker who managed to become the administrator could remove all evidence of his intrusion.
Second, ACLs only contain the names of users, not of programs; so there is no straightforward way to implement access triples of (user, program, file). Instead, Unix provides an indirect method: the set-user-id (suid) file attribute. The owner of a program can mark the file representing that program as suid, which enables it to run with the privilege of its owner rather than the privilege of the user who has invoked it.
Programmers are often lazy or facing tight deadlines; so they just make the application suid root, so it can do anything. This practice leads to some shocking security holes.
Managing stateful access rules is dicult; they can complicate the revocation of users who have just been fired, as it can be hard to track down the files they’ve opened, and stu↵ can get stuck.
Third, ACLs are not very good at expressing mutable state. Suppose we want a transaction to be authorised by a manager and an accountant before it’s acted on; we can either do this at the application level (say, by having queues of transactions awaiting a second signature) or by doing something fancy with suid.
set-user-id (suid) file attribute.
Fourth, the Unix ACL only names one user. If a resource will be used by more than one of them, and you want to do access control at the OS level, you have a couple of options.
Fourth, the Unix ACL only names one user. If a resource will be used by more than one of them, and you want to do access control at the OS level, you have a couple of options.
The strengths and weaknesses of capabilities are roughly the opposite of ACLs. Runtime security checking is more ecient, and we can delegate a right without much diculty: Bob could create a certificate saying ‘Here is my capability and I hereby delegate to David the right to read file 4 from 9am to 1pm
On the other hand, changing a file’s status becomes more tricky as it can be hard to find out which users have access. This can be tiresome when we have to investigate an incident or prepare evidence.
The IBM AS/400 series systems brought capability-based protection to the mainstream computing market in 1988, and enjoyed some commercial success. The public key certificates used in cryptography are in e↵ect capabilities, and became mainstream from the mid-1990s. Capabilities have started to supplement ACLs in operating systems, including more recent versions of Windows, FreeBSD and iOS, as I will describe later.
In early systems based on traditional ACLs, each access control decision required a reference to administrative systems to find out which nurses and which patients were on which ward, when – but this made both the HR system and the patient administration system safety-critical, which hammered reliability. Matters were fixed by giving nurses ID cards with certificates that entitle them to access the files associated with a number of wards or hospital departments [522, 523]. If you can make the trust relationships in systems mirror the trust relationships in that part of the world you’re trying to automate, you should.
Then along came machines that would run more than one program at once, and the protection problem of preventing one program from interfering with another.
And many reliability problems stem from applications misunderstanding each other, or fighting with each other.
Access control- Its function is to control which principals (persons, processes, machines, . . .) have access to which resources in the system – which files they can read, which programs they can execute, how they share data with other principals, and so on.
Access control works at a number of different levels, including at least:
Access controls at the application level may express a very rich, domain-specific security policy.
The call center staff in a bank are typically not allowed to see your account details until you have answered a couple of security questions; this not only stops outsiders from impersonating you, but also stops the bank staff looking up the accounts of celebrities, or their neighbors.
The applications may be written on top of middleware, such as a web browser, a bank’s bookkeeping system or a social network’s database management system
These enforce a number of protection properties. For example, bookkeeping systems ensure that a transaction that debits one account must credit another, with the debits and credits balancing so that money cannot be created or destroyed; they must also allow the system’s state to be reconstructed later
As the operating system constructs resources such as files and communications ports from lower level components, it has to provide ways to control access to them
Your Android phone treats apps written by different companies as different users and protects their data from each other. The same happens when a shared server separates the VMs, containers or other resources belonging to different users
Finally, the operating system relies on hardware protection provided by the processor and its associated memory-management hardware, which control which memory addresses a given process or thread can access.
As we work up from the hardware through the operating system and middleware to the application layer, the controls become progressively more complex and less reliable. And we find the same access-control functions being implemented at multiple layers.
operating-system protection mechanisms that support the isolation of multiple processes:
discretionary access control (DAC) mechanisms, which leave protection to the machine operator
mandatory access control (MAC) mechanisms which are typically under the control of the vendor and protect the operating system itself from being modified by malware.
The access controls provided with an operating system typically authenticate principals using a mechanism such as passwords or fingerprints in the case of phones, or passwords or security protocols in the case of servers, then authorise access to files, communications ports and other system resources.
Access controls can often be modeled as a matrix of access permissions, with columns for files and rows for users.
access triples of (user, program, file)
a protection domain- which is a set of processes or threads that share access to the same resources.
Access control matrices (whether in two or three dimensions) can be used to implement protection mechanisms as well as just model them. But they don’t scale well- We will need a better way of storing and managing this information, and the two main options are to compress the users and to compress the rights. With the first, we can use groups or roles to manage large sets of users simultaneously, while with the second we may store the access control matrix either by columns (access control lists) or rows
a group is a list of principals, while a role is a fixed set of access permissions that one or more principals may assume for a period of time.
The traditional way to simplify the management of access rights is to store the access control matrix a column at a time, along with the resource to which the column refers. This is called an access control list or ACL (pronounced ‘ackle’).
ACLs are suited to environments where protection is data-oriented; they are less suited where the user population is large and constantly changing, or where users want to be able to delegate their authority to run a particular program to another user for some set period of time.
ACLs are simple to implement, but are not efficient for security checking at runtime, as the typical operating system knows which user is running a particular program, rather than what files it has been authorized to access since it was invoked. The operating system must either check the ACL at each file access, or keep track of the active access rights in some other way.
Finally, distributing the access rules into ACLs makes it tedious to find all the files to which a user has access. Verifying that no files have been left worldreadable or even world-writable could involve checking ACLs on millions of user files; this is a real issue for large complex firms.
In traditional Unix systems, files are not allowed to have arbitrary access control lists, but simply rwx attributes that allow the file to be read, written and executed. The access control list as normally displayed has a flag to show whether the file is a directory, then flags r, w and x for owner, group and world respectively; it then has the owner’s name and the group name.
Ex: -rw-r----- Alice Accounts
This records that the file is simply a file rather than a directory; that the file owner can read and write it; that group members (including Bob) can read it but not write it; that non-group members have no access at all; that the file owner is Alice; and that the group is Accounts.
The program that gets control when the machine is booted (the operating system kernel) runs as the supervisor, and has unrestricted access to the whole machine. All other programs run as users and have their access mediated by the supervisor.
Access decisions are made on the basis of the userid associated with the program. However if this is zero (root), then the access control decision is ‘yes’. So root can do what it likes – access any file, become any user, or whatever. What’s more, there are certain things that only root can do, such as starting certain communication processes. The root userid is typically made available to the system administrator in systems with discretionary access control.-- ROOT IS BASICALLY GOD
This means that the system administrator can do anything, so we have difficulty implementing an audit trail as a file that they cannot modify
Second, ACLs only contain the names of users, not of programs; so there is no straightforward way to implement access triples of (user, program, file). Instead, Unix provides an indirect method: the set-user-id (suid) file attribute.
The owner of a program can mark the file representing that program as suid, which enables it to run with the privilege of its owner rather than the privilege of the user who has invoked it. So in order to achieve the functionality needed by our second example above, we could create a user ‘account-package’ to own file 2 (the accounts package), make the file suid and place it in a directory to which Alice has access. This special user can then be given the access that the accounts program needs.
Third, ACLs are not very good at expressing mutable state
Fourth, the Unix ACL only names one user.
The next way to manage the access control matrix is to store it by rows. These are called capabilities,
The strengths and weaknesses of capabilities are roughly the opposite of ACLs. Runtime security checking is more efficient, and we can delegate a right without much difficulty
On the other hand, changing a file’s status becomes more tricky as it can be hard to find out which users have access. This can be tiresome when we have to investigate an incident or prepare evidence.
Chapter 6 - 6.2.4
Then along came machines that would run more than one program at once, and the protection problem of preventing one program from interfering with another.
Access controls at the application level may express a very rich, domainspecific security policy. The call centre sta↵ in a bank are typically not allowed to see your account details until you have answered a couple of security questions; this not only stops outsiders impersonating you, but also stops the bank sta↵ looking up the accounts of celebrities, or their neighbours.
The applications may be written on top of middleware, such as a web browser, a bank’s bookkeeping system or a social network’s database management system. These enforce a number of protection properties.
Your Android phone treats apps written by di↵erent companies as di↵erent users and protects their data from each other
Finally, the operating system relies on hardware protection provided by the processor and its associated memory-management hardware, which control which memory addresses a given process or thread can access.
I will start o↵ by discussing operating-system protection mechanisms that support the isolation of multiple processes. They are often described as discretionary access control (DAC) mechanisms, which leave protection to the machine operator, or mandatory access control (MAC) mechanisms which are typically under the control of the vendor and protect the operating system itself from being modified by malware.
These help us tackle the toxic legacy of the old single-user PC operating systems such as DOS and Win95/98 which let any process modify any data, and constrain the many applications that won’t run unless you trick them into thinking that they are running with administrator privileges.
Another way of expressing a policy of this type would be with access triples of (user, program, file). In the general case, our concern isn’t with a program so much as a protection domain which is a set of processes or threads that share access to the same resources
Access control matrices (whether in two or three dimensions) can be used to implement protection mechanisms as well as just model them. But they don’t scale well: a bank with 50,000 sta↵ and 300 applications would have a matrix of 15,000,000 entries, which might not only impose a performance overhead but also be vulnerable to administrators’ mistakes.
When we look at large organisations, we usually find that most sta↵ fit into one of a small number of categories. A bank might have 40 or 50: teller, call centre operator, loan ocer and so on. Only a few dozen people (security manager, chief foreign exchange dealer, ...) will need personally customised access rights.
Some vendors (such as Microsoft) use the words group and role almost interchangeably, but a more careful definition is that a group is a list of principals, while a role is a fixed set of access permissions that one or more principals may assume for a period of time.
Groups and roles can be combined. The ocers of the watch of all ships currently at sea is a group of roles. In banking, the manager of the Cambridge branch might have their privileges expressed by membership of the group manager and assumption of the role acting manager of Cambridge branch.
The group manager might express a rank in the organisation (and perhaps even a salary band) while the role acting manager might include an assistant accountant standing in while the manager, deputy manager, and branch accountant are all o↵ sick.
The traditional way to simplify the management of access rights is to store the access control matrix a column at a time, along with the resource to which the column refers. This is called an access control list or ACL (pronounced ‘ackle’).
ACLs have a number of advantages and disadvantages as a means of managing security state. They are a natural choice in environments where users manage their own file security, and became widespread in Unix systems from the 1970s. They are the basic access control mechanism in Unix-based systems such as Linux and Apple’s macOS, as well as in derivatives such as Android and iOS. The access controls in Windows were also based on ACLs, but have become more complex over time.
ACLs are simple to implement, but are not ecient for security checking at runtime, as the typical operating system knows which user is running a particular program, rather than what files it has been authorized to access since it was invoked. The operating system must either check the ACL at each file access, or keep track of the active access rights in some other way.
Finally, distributing the access rules into ACLs makes it tedious to find all the files to which a user has access. Verifying that no files have been left worldreadable or even world-writable could involve checking ACLs on millions of user files; this is a real issue for large complex firms.
In traditional Unix systems, files are not allowed to have arbitrary access control lists, but simply rwx attributes that allow the file to be read, written and executed. The access control list as normally displayed has a flag to show whether the file is a directory, then flags r, w and x for owner, group and world respectively; it then has the owner’s name and the group name.
However if this is zero (root), then the access control decision is ‘yes’. So root can do what it likes – access any file, become any user, or whatever. What’s more, there are certain things that only root can do, such as starting certain communication processes
This means that the system administrator can do anything, so we have difficulty implementing an audit trail as a file that they cannot modify. In our example, Sam could tinker with the accounts, and have diculty defending himself if he were falsely accused of tinkering; what’s more, a hacker who managed to become the administrator could remove all evidence of his intrusion.
Second, ACLs only contain the names of users, not of programs; so there is no straightforward way to implement access triples of (user, program, file). Instead, Unix provides an indirect method: the set-user-id (suid) file attribute. The owner of a program can mark the file representing that program as suid, which enables it to run with the privilege of its owner rather than the privilege of the user who has invoked it.
Programmers are often lazy or facing tight deadlines; so they just make the application suid root, so it can do anything. This practice leads to some shocking security holes.
Managing stateful access rules is dicult; they can complicate the revocation of users who have just been fired, as it can be hard to track down the files they’ve opened, and stu↵ can get stuck.
Third, ACLs are not very good at expressing mutable state. Suppose we want a transaction to be authorised by a manager and an accountant before it’s acted on; we can either do this at the application level (say, by having queues of transactions awaiting a second signature) or by doing something fancy with suid.
set-user-id (suid) file attribute.
Fourth, the Unix ACL only names one user. If a resource will be used by more than one of them, and you want to do access control at the OS level, you have a couple of options.
Fourth, the Unix ACL only names one user. If a resource will be used by more than one of them, and you want to do access control at the OS level, you have a couple of options.
The strengths and weaknesses of capabilities are roughly the opposite of ACLs. Runtime security checking is more ecient, and we can delegate a right without much diculty: Bob could create a certificate saying ‘Here is my capability and I hereby delegate to David the right to read file 4 from 9am to 1pm
On the other hand, changing a file’s status becomes more tricky as it can be hard to find out which users have access. This can be tiresome when we have to investigate an incident or prepare evidence.
The IBM AS/400 series systems brought capability-based protection to the mainstream computing market in 1988, and enjoyed some commercial success. The public key certificates used in cryptography are in e↵ect capabilities, and became mainstream from the mid-1990s. Capabilities have started to supplement ACLs in operating systems, including more recent versions of Windows, FreeBSD and iOS, as I will describe later.
In early systems based on traditional ACLs, each access control decision required a reference to administrative systems to find out which nurses and which patients were on which ward, when – but this made both the HR system and the patient administration system safety-critical, which hammered reliability. Matters were fixed by giving nurses ID cards with certificates that entitle them to access the files associated with a number of wards or hospital departments [522, 523]. If you can make the trust relationships in systems mirror the trust relationships in that part of the world you’re trying to automate, you should.
Then along came machines that would run more than one program at once, and the protection problem of preventing one program from interfering with another.
And many reliability problems stem from applications misunderstanding each other, or fighting with each other.
Access control- Its function is to control which principals (persons, processes, machines, . . .) have access to which resources in the system – which files they can read, which programs they can execute, how they share data with other principals, and so on.
Access control works at a number of different levels, including at least:
Access controls at the application level may express a very rich, domain-specific security policy.
The call center staff in a bank are typically not allowed to see your account details until you have answered a couple of security questions; this not only stops outsiders from impersonating you, but also stops the bank staff looking up the accounts of celebrities, or their neighbors.
The applications may be written on top of middleware, such as a web browser, a bank’s bookkeeping system or a social network’s database management system
These enforce a number of protection properties. For example, bookkeeping systems ensure that a transaction that debits one account must credit another, with the debits and credits balancing so that money cannot be created or destroyed; they must also allow the system’s state to be reconstructed later
As the operating system constructs resources such as files and communications ports from lower level components, it has to provide ways to control access to them
Your Android phone treats apps written by different companies as different users and protects their data from each other. The same happens when a shared server separates the VMs, containers or other resources belonging to different users
Finally, the operating system relies on hardware protection provided by the processor and its associated memory-management hardware, which control which memory addresses a given process or thread can access.
As we work up from the hardware through the operating system and middleware to the application layer, the controls become progressively more complex and less reliable. And we find the same access-control functions being implemented at multiple layers.
operating-system protection mechanisms that support the isolation of multiple processes:
discretionary access control (DAC) mechanisms, which leave protection to the machine operator
mandatory access control (MAC) mechanisms which are typically under the control of the vendor and protect the operating system itself from being modified by malware.
The access controls provided with an operating system typically authenticate principals using a mechanism such as passwords or fingerprints in the case of phones, or passwords or security protocols in the case of servers, then authorise access to files, communications ports and other system resources.
Access controls can often be modeled as a matrix of access permissions, with columns for files and rows for users.
access triples of (user, program, file)
a protection domain- which is a set of processes or threads that share access to the same resources.
Access control matrices (whether in two or three dimensions) can be used to implement protection mechanisms as well as just model them. But they don’t scale well- We will need a better way of storing and managing this information, and the two main options are to compress the users and to compress the rights. With the first, we can use groups or roles to manage large sets of users simultaneously, while with the second we may store the access control matrix either by columns (access control lists) or rows
a group is a list of principals, while a role is a fixed set of access permissions that one or more principals may assume for a period of time.
The traditional way to simplify the management of access rights is to store the access control matrix a column at a time, along with the resource to which the column refers. This is called an access control list or ACL (pronounced ‘ackle’).
ACLs are suited to environments where protection is data-oriented; they are less suited where the user population is large and constantly changing, or where users want to be able to delegate their authority to run a particular program to another user for some set period of time.
ACLs are simple to implement, but are not efficient for security checking at runtime, as the typical operating system knows which user is running a particular program, rather than what files it has been authorized to access since it was invoked. The operating system must either check the ACL at each file access, or keep track of the active access rights in some other way.
Finally, distributing the access rules into ACLs makes it tedious to find all the files to which a user has access. Verifying that no files have been left worldreadable or even world-writable could involve checking ACLs on millions of user files; this is a real issue for large complex firms.
In traditional Unix systems, files are not allowed to have arbitrary access control lists, but simply rwx attributes that allow the file to be read, written and executed. The access control list as normally displayed has a flag to show whether the file is a directory, then flags r, w and x for owner, group and world respectively; it then has the owner’s name and the group name.
Ex: -rw-r----- Alice Accounts
This records that the file is simply a file rather than a directory; that the file owner can read and write it; that group members (including Bob) can read it but not write it; that non-group members have no access at all; that the file owner is Alice; and that the group is Accounts.
The program that gets control when the machine is booted (the operating system kernel) runs as the supervisor, and has unrestricted access to the whole machine. All other programs run as users and have their access mediated by the supervisor.
Access decisions are made on the basis of the userid associated with the program. However if this is zero (root), then the access control decision is ‘yes’. So root can do what it likes – access any file, become any user, or whatever. What’s more, there are certain things that only root can do, such as starting certain communication processes. The root userid is typically made available to the system administrator in systems with discretionary access control.-- ROOT IS BASICALLY GOD
This means that the system administrator can do anything, so we have difficulty implementing an audit trail as a file that they cannot modify
Second, ACLs only contain the names of users, not of programs; so there is no straightforward way to implement access triples of (user, program, file). Instead, Unix provides an indirect method: the set-user-id (suid) file attribute.
The owner of a program can mark the file representing that program as suid, which enables it to run with the privilege of its owner rather than the privilege of the user who has invoked it. So in order to achieve the functionality needed by our second example above, we could create a user ‘account-package’ to own file 2 (the accounts package), make the file suid and place it in a directory to which Alice has access. This special user can then be given the access that the accounts program needs.
Third, ACLs are not very good at expressing mutable state
Fourth, the Unix ACL only names one user.
The next way to manage the access control matrix is to store it by rows. These are called capabilities,
The strengths and weaknesses of capabilities are roughly the opposite of ACLs. Runtime security checking is more efficient, and we can delegate a right without much difficulty
On the other hand, changing a file’s status becomes more tricky as it can be hard to find out which users have access. This can be tiresome when we have to investigate an incident or prepare evidence.
