Figure 6.2: Access control matrix for bookkeeping
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 staff 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. 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 (capabilities, also known as ‘tickets’ to protocol engineers and ‘permissions’ on mobile phones) [1642, 2024].
6.2.1 Groups and roles
When we look at large organisations, we usually find that most staff fit into one of a small number of categories. A bank might have 40 or 50: teller, call centre operator, loan officer and so on. Only a few dozen people (security manager, chief foreign exchange dealer, …) will need personally customised access rights.
So we need to design a set of groups, or functional roles, to which staff can be assigned. 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. The classic example of a role is the officer of the watch on a ship. There is exactly one watchkeeper at any one time, and there is a formal procedure whereby one officer relieves another when the watch changes. In most government and business applications, it's the role that matters rather than the individual.
Groups and roles can be combined. The officers 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 off sick.
Whether we need to be careful about this distinction is a matter for the application. In a warship, even an ordinary seaman may stand watch if everyone more senior has been killed. In a bank, we might have a policy that “transfers over $10m must be approved by two staff, one with rank at least manager and one with rank at least assistant accountant”. If the branch manager is sick, then the assistant accountant acting as manager might have to get the regional head office to provide the second signature on a large transfer.
6.2.2 Access control lists
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’). In the first of our above examples, the ACL for file 3 (the account file) might look as shown here in Figure 6.3.
| User | Accounting |
| Data | |
| Sam | rw |
| Alice | rw |
| Bob | r |
Figure 6.3: Access control list (ACL)
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. Where access control policy is set centrally, 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 world-readable or even world-writable could involve checking ACLs on millions of user files; this is a real issue for large complex firms. Although you can write a script to check whether any file on a server has ACLs that breach a security policy, you can be tripped up by technology changes; the move to containers has led to many corporate data exposures as admins forgot to check the containers' ACLs too. (The containers themselves are often dreadful as it's a new technology being sold by dozens of clueless startups.) And revoking the access of an employee who has just been fired will usually have to be done by cancelling their password or authentication token.
Let's look at an important example of ACLs – their implementation in Unix (plus its derivatives Android, MacOS and iOS).
6.2.3 Unix operating system security
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. A directory with all flags set would have the ACL:
drwxrwxrwx Alice Accounts
In our first example in Figure 6.1, the ACL of file 3 would be:
-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)