Access Control

Access control addresses the problem of ensuring that only authorised subjects (such as users and processes) have access to certain objects (such as files, memory, printers or network connections).

What part of the system controls accesses?

Access control works at a number of levels, as shown in the figure. The user experience is the effect of these layers put together [1].


Application
Middleware
Operating system
Hardware

The access control mechanisms, which the user sees at the application level, may express a very rich and complex security policy. A modern online business could assign staff to one of dozens of different roles, each of which could initiate some subset of several hundred possible transactions in the system.
The applications may be written on top of middleware, such as a database management system or bookkeeping package, which enforces a number of protection properties. For example, bookkeeping software may ensure that a transaction that debits one ledger for a certain amount must credit another ledger for the same amount.
The middleware will use facilities provided by the underlying operating system. As this constructs resources such as files and communications ports from lower-level components, it acquires the responsibility for providing ways to control access to them.
Finally, the operating system access controls will usually rely on hardware features provided by the processor or by associated memory management hardware. These control which memory addresses a given process can access.

Usually, the access conrol at lower layers is much coarser than the access control available at higher layers.

Access control models

The classic model is an access control matrix. For each subject and each object, it describes the accesses allowed by the subject on the object.

Example

	Operating system	Accounts program	Accounting data	Audit trail
Sam (sys op)	rwx	rwx	rw	r
Alice (manager)	x	x	rw	-
Bob (auditor)	rx	r	r	r

Example (improved)

The access control system is too coarse grained; for example, it doesn't ensure that transactions are well-formed, e.g. that credits can be matched up with debits. Alice should not have unrestricted access to the accounting data, but only the sort of access that ensures these integrity constraints. Access to the accounting data should be via the accounts program.

	Operating system	Accounts program	Accounting data	Audit trail
Sam (sys op)	rwx	rwx	r	r
Alice (manager)	x	x	-	-
Bob (auditor)	rx	r	r	r
Accounts program	rx	r	rw	w

Sam can still do bad things, e.g. overwrite the accounts program with an unauthorised one of his own devising.

Access control lists

Store each column of the matrix with the resource it refers to. Thus, we store

( Accounting data, [ (Sam, r), (Bob, r), (Accounts program, rw) ] )

Note that Alice has no access, so it is not necessary to have an entry for her.

Access control lists
Advantages	Disadvantages
Simple to implement	Not suitable if user population large and/or changes a lot
Suitable for "Discretionary access control" (in which resources have owners that set permissions)	Doesn't easily support delegation
	Hard to figure out which files a user has access to: revoking usually done by deleting user rather than deleting ACL entries

ACLs are not very good at expressing changing state, in which permissions depend on the current state of the system. Managing stateful access rules, such as dual control, has to be done at the application level.

Capability lists

Store each row of the matrix with the subject it refers to. Thus, we store

( Alice, [ (Operating system, x), (Accounts program, x) ] )

Capability lists
Advantages	Disadvantages
Supports delegation (capability transfer)	Not suitable if set of resources is large and/or changes a lot
	Hard to figure out which users can access a file: changing a file's status difficult

Capabilities can be implemented as:

Unforgeable tokens, e.g., cookies in a web browser. These capabilities are like a bus ticket: mere possession indicates rights that subject has over object. The object is identified by the capability (as part of the token). The owner must be prevented from altering the capabilities. These capabilities are easily transferable.
Certificates. E.g., consider implementing the policy: "a nurse will have access to all the patients who are on his ward, or who have been there in the last 90 days". One would like to avoid implementing this in a way which requires access to the database that contains the records of which patients and which nurses are on which ward, in order to avoid close coupling of systems and problems if the database fails or becomes temporarily unavailable. Giving to nurses the certificates entitling them to access the files associated with their current ward would seem a good way to go. These capabilities name the subject, so are not transferable.

The second example above is harder to implement using ACLs.

Delegation

If Alice has a certain permission, she may want to give (or lend) it to Bob so that he can act on her behalf.

Some systems support such delegations
But they do not allow users to delegate arbitrarily. There may be restrictions on what permissions are delegatable, and also on whether the receiver of a delegated right can delegate it again.

"Unforgeable tokens" described above are universally delegatable.

"Certificates" described above may be delegatable with restrictions. E.g., the system may allow Alice to convert her certificate to access a resource into a similar certificate for Bob. She can then give that new certificate to Bob. Alternatively, she could create a new certificate saying "Bob can access r" and give both her certificate and the new one to Bob [this is a certificate chain]. Those certificates could be time-limited or have other conditions, to facilitate revocation.

Unix file systems

In Unix, the rights to a file are stored associated with the file itself, so it's a bit like ACLs. But the original Unix (and current Linux) doesn't implement full access control lists; instead, there are 9 bits associated with the file expressing read, write, execute permissions for the file's owner, members of the file's group, and others. Each file has an owner (which can set the permissions) and a group.

Example

-rw-r----- alice acctsstaff accounts

expresses the fact that the file accounts is owned by alice and is in the group acctsstaff. Moreover, the owner can read and write the file, the group members can read it, and others cannot do anything to it. (The first bit indicates whether the file is a direcctory. The x bit is interpreted as traversal for directories.)

Rule

User s has rights p to access file f if:

s is the owner of f, and the p bit is set for owner, or
s is not the owner of f, and s is in the group of f, and the p bit is set for group, or
s is not the owner of f, and s is not in the group of f, and the p bit is set for other.

If the file is accessed by a path, then s needs to have "x" access (traversal) for each directory along the path.

Example

Alice wants to have a file cinema publically readable, and writable only by Jane and herself. If she had a system supporting ACLs, she could simply add Jane with the write permission to the file that she wants to share. To achieve this in unix, she would have to ask the sysadm to create a group alicefriends and put her and jane in that group. Then she would change the group of the file to alicefriends, and set the permissions

-rw-rw-r-- alice alicefriends cinema

Question

How could Alice proceed if she wants cinema to be writable by herself and Jane (and no-one else), and readable by herself, Jane and Bob (and no-one else)?

Solution

Put the cinema file in a directory alicedir and arrange for only Alice, Jane and Bob to be able to traverse it (x permission). Then cinema permissions are set to be writable by Alice and Jane, and readable by all (but that is restricted by the requirement to be able to traverse alicedir), and writable by Alice and Jane. Here are the details:
Groups:
alicefriendsr: alice,bob,jane
alicefriendsw: alice,jane

Files:
drwxr-xr-- alice alicefriendsr mydir
-rw-rw-r-- alice alicefriendsw mydir/cinema

This is not a very good solution:

Quite complicated to figure out
Alice cannot set up those groups herself (the system administrator needs to do it)

Locking yourself out

Alice cannot read or write this file, but everyone else can!

----rw-rw- alice alicefriends cinema

She can change the permissions to give herself access, however.

Permissions for programs

Unlike Windows, Unix doesn't support programs or processes as subjects that can have permissions. Instead it provides an indirect method: the suid and sgid file attributes.

The owner of a program can mark it as suid. This enables it to run with the privilege of its owner rather than the privilege of the user who has invoked it; sgid does the same for groups. To achieve functionality whereby Alice cannot directly modify the accounts data but can do so only by using the official accounts package, we could create a user "accounts-program" to own file "accounts-program" (the accounts package), make the file suid, and place it in a directory to which Alice has access. This special user could then be given the access control attributes (rwx) we want for the accounts program.

This mechnaism delegates the access control problem from the OS level to the application level. Although quite elegant, it has some issues. One way of looking at this is that an access control problem that is naturally modelled in three dimensions--the triples (user, program, data)--is being implemented using two-dimensional mechanisms. These mechanisms are much less intuitive than triples, and people make many mistakes implementing them. Programmers are often lazy or facing tight deadlines; so they just make the application suid root, and it can do anything. This practice leads to some rather shocking security holes. The responsibility for making access control decisions is moved from the operating system environment to the program, and most programmers are insufficiently experienced and careful to check everything that they should. In particular, the person invoking a suid root program controls its environment and can often manipulate this to cause protection failures.

In theory, the ACL and suid/sgid mechanisms can often be used to achieve the desired effect. In practice, programmers are often too lazy to figure out how to do this, and so design their code to require much more privilege than it really ought to. [1]

ACLs in unix

Sun Microsystem's Solaris unix operating system has full ACLs layered on top of the traditional unix controls. SELinux also supports ACLs in unix.

drwxr-----+ mdr staff ug12abc

gromit% getfacl ug12abc
# file: ug21abc
# owner: mdr
# group: staff
user::rwx
user:ajb:rwx
user:ug21abc:r--
user:mdr:rwx
group::---
mask::rwx
other::---

The user::, group::, other:: entries are just the ones from the basic access control system described above. user:ajb:rwx
means that ajb has rwx permissions, etc. mask:: restricts the permissions for users and groups to the given permissions. A user has a permission if he has it according to the standard permissions OR the permissions given by the ACL.

Questions

Arrange for Alice to be able to delegate accounts-program execution permission to users of her choice.
Is it possible to arrange for Alice OR Bob to be able to perform the delegation? (This means that either Alice's permission or Bob's permission is required before another user can execute the accounts program.)
Is it possible to arrange for Alice AND Bob to be able to perform the delegation? (This means that both Alice's permission and Bob's permission is required before another user can execute the accounts program.)

Role-based access control

The idea of RBAC is to separate the relation describing the access rights a subject has on an object:

	Accounts program	Accounting data	Personnel file
Sam (sys op)	rwx	r	-
Alice (manager)	-	r	rw
Bob (accts person)	x	r	-
Charlie (accts person)	x	r	-
Dave (accts person)	x	r	-

into two relations, one describing the subject's membership of roles, and the other describing the role's rights on objects:

	sysop	manager	accounts
Sam	Y	N	N
Alice	N	Y	N
Bob	N	N	Y
Charlie	N	N	Y
Dave	N	N	Y

	Accounts program	Accounting data	Personnel file
sysop	rwx	r	-
manager	-	r	rw
accounts	x	r	-

The main point of RBAC is to simplify the management of permissions. E.g., the sysadm has to set and manage the permissions for roles instead of individual users.

RBAC is attractive, but on its own it fails to provide enough granularity. How can one express that a bank customer can see his or her own balance, but not anyone else's?

Many variants of RBAC exist, expressing inheritance of permissions between subjects, mechanisms for delegation, and much else.

Roles vs groups.

Limitations of OS access control

The kinds of permissions that managers want are often not expressible at the level of "files" and "users", and therefore not expressible at the OS level.

Database access control: customer X can decrement X's balance only if the balance is >0.

It seems that application-level access control is quite ad-hoc.

References

[1] Ross Anderson, Chapter 4 of Security Engineering. Wiley, 2001.
[2] Matt Bishop, Computer Security: Art and Science. Addison-Wesley, 2002.