Access Control

Jason Crampton 14 October 2002

Overview
Introduction to access control and access control structures Partial orders, lattices and their use in access control Administration and aggregation of access control structures New directions

What is access control?

A generic term for the process by which a computer system controls the interaction between users and system resources To implement a security policy, which may be determined by
organisational requirements statutory requirements (medical records, for example)

Policy requirements may include

confidentiality (restrictions on read access) integrity (restrictions on write access) availability

A schematic view
A user requests access (read, write, print, etc.) to a resource in the computer system The reference monitor
establishes the validity of the request and returns a decision either granting or denying access to the user
Access Request Reference Monitor System Decision

Simple analogies
Consider a paper-based office in which certain documents should only be read by certain individuals We could implement security by
storing documents in filing cabinets issuing keys to the relevant individuals for the appropriate cabinets

Simple analogies
The reference monitor is the set of (locked) filing cabinets An access request (an attempt to open a filing cabinet) is granted if the key fits the lock (and denied otherwise)

Simple analogies
Consider now a night club where only certain individuals are allowed into the club We can implement security by
employing a bouncer providing the bouncer with a guest list (that is, a list of people permitted to enter the club)

Simple analogies
The reference monitor is the security guard + the guest list An access request is granted only if
a club-goer can prove their identity (authentication) she is on the guest list

Subjects and objects

Subject
Active entity in a computer system
User, process, thread

We will assume that a subject is synonymous with a user

Object
Passive entity or resource in a computer system
Files, directories, printers

Principals
Principal and subject are both used to refer to the active entity in an access operation A principal is generally assumed to be an attribute or property associated with a subject
User ID Public key Process Thread

A subject may be represented by more than one principal

Access operations
An interaction between an object and a subject A subject may observe (read) an object
Information flows from object to subject

A subject may alter (write to) an object

Information flows from subject to object

Back to the analogies

In our club example
a subject is a club-goer the only objects are the club and the guest list access operations could include enter club and delete guest (that is, change the guest list)

In the filing cabinet example

a subject is a user of the files in the cabinets an object is a filing cabinet or a file in one of the cabinets access operations could include read and write (for files) and also remove key from user

Read and write access

In a multi-user OS users open files to get access
Files are opened for read or for write access so that the OS can avoid conflicts like two users simultaneously writing to the same file

Write access mode is usually implemented as read/write mode

A user editing a file should not be asked to open it twice

The append (or blind write or write-only) access mode allows users to alter an object without observing its contents
Rarely useful (audit log files being the main exception) Implemented in Multics

The execute access operation

Sometimes an object can be used without opening it in read or write mode
Directories Binary executable files Cryptographic keys

We include the execute access operation

This may mean different things in different contexts and in different systems

UNIX access operations

File access
Read (r) Write (w) Execute (x)

Directory access
Read (list directory contents) Write (create or rename files in directory) Execute (search directory)

UNIX ls command
Operations drwxr-xr-x -rw-------rwxr-xr-x -rw-r----Owner Group jason jason jason jason Research research research research Size 512 127092 7632 0 Updated Jul 3 15:51 Aug 28 15:01 Name Research Trash

May 20 18:16 a.out Nov 25 1998 allfiles.txt

The UNIX reference monitor

Users have an ID and a group ID
12.6 represents a user with group ID 12 and user ID 6 (within that group)

Objects have an ID (determined by the creator of the object) and a group ID (determined by the group ID of the creator)
12.6 is the object ID of an object created by user 12.6

Objects also have an access mask

A pattern of 9 bits in 3 groups of 3

The UNIX reference monitor

The access mask of the Research directory is 101 101 111 representing x-r x-r xwr
The ls output reverses the order of the bits

Assume the ID of the Research directory is 12.6 Any user has the default access given by the first 3 bits (read and execute in this case) Any user with ID 12.x has group access because the user ID and object ID match in the first place The user with ID 12.6 has owner access because the user ID and object ID match in both places

The access control matrix

Introduced by Lampson (1972) and extended by Harrison, Ruzzo and Ullman (1976-8)
Columns indexed by objects Rows indexed by subjects Matrix entries are (sets of) access operations Foundation of many theoretical security models
Objects
Subjects

trash
{r,w}

a.out
{r,w,x} {r,x}

allfiles.txt
{r,w} {r}

jason mick

The access control matrix

A request can be regarded as a triple (s,o,a)
s is a subject o is an object a is an access operation

A request is granted (by the reference monitor) if

a belongs to the access matrix entry corresponding to subject s and object o

The access control matrix

The request (jason, allfiles.txt, w) is granted The request (mick, allfiles.txt, w) is denied

Objects Subjects

trash {r,w}

a.out {r,w,x} {r,x}

allfiles.txt {r,w} {r}

jason mick

Disadvantages
Abstract formulation of access control Not suitable for direct implementation
The matrix is likely to be extremely sparse and therefore implementation is inefficient Management of the matrix is likely to be extremely difficult if there are 0000s of files and 00s of users (resulting in 000000s of matrix entries)

Access control lists

An ACL corresponds to a column in the access control matrix [a.out: (jason, {r,w,x}), (mick, {r,x})] How would a reference monitor that uses ACLs check the validity of the request (jason, a.out, r)?

Objects Subjects

trash {r,w}

a.out {r,w,x} {r,x}

allfiles.txt {r,w} {r}

jason mick

Access control lists

Access control lists focus on the objects
Typically implemented at operating system level Windows NT uses ACLs

Disadvantage
How can we check the access rights of a particular subject efficiently (before-the-act per-subject review)?

Capability lists
A capability list corresponds to a row in the access control matrix [jason: (trash, {r,w}), (a.out, {r,w,x}), (allfiles.txt, {r,w})] How would such a reference monitor check the validity of the request (jason, a.out, r)?

Objects Subjects

trash
{r,w}

a.out
{r,w,x} {r,x}

allfiles.txt
{r,w} {r}

jason mick

Capability lists
Capability lists focus on the subjects
Typically implemented in services and application software Database applications often use capability lists to implement fine-grained access to tables and queries Renewed interest in capability-based access control for distributed systems

Disdavantage
How can we check which subjects can access a given object (before-the-act per-object review)?

Back to the analogies

An ACL is analogous to a guest list
the club is the object the favoured clubbers appear on the list

A capability list is analogous to the set of keys issued to a user (the subject) for unlocking the filing cabinets (the objects)

Administration
Tasks include
Creation of new objects and subjects Deletion of objects and subjects Changing entries in access control matrix (changing entries in ACLs and capability lists)

The administration of access control structures is extremely time-consuming, complicated and error-prone

Aggregation
There are several important theoretical results (Harrison, Ruzzo and Ullman; Lipton and Snyder) that demonstrate that it is extremely difficult to anticipate the consequences of administrative actions Access control structures that aggregate subjects and objects are used to simplify the administrative burden

Aggregation techniques
User groups Roles Procedures Data types

Groups
Access rights are often defined for groups of users
In UNIX three groups are associated with each object
Owner Group (owner) Others

In VMS there are four groups

Owner Group World System

In VSTa complicated hierarchical group structures can be constructed based on the UNIX model (see handout)

Roles
A data type is a set of objects with the same structure (bank accounts, for example) We define access operations (procedures or permissions) on a data type Permissions are assigned to roles Users are assigned to roles Roles are (usually) arranged in a hierarchy

Example
Objects are bank accounts Subjects are bank employees The set of bank accounts forms a data type We define roles
Teller Clerk Administrator

We define procedures for

Crediting accounts (CA) Debiting accounts (DA) Transferring funds between accounts (TF) Creating new accounts (NA) Authorising overdrafts (AO)

Example
We assign procedure
CA and DA to the Teller role TF to the Clerk role NA and AO to the Administrator role
Admin

We assign all users who are tellers to the Teller role, etc. The Administrator role can run all the procedures

Clerk

Teller

Benefits of RBAC
We only need to assign users and permissions to roles We can use inheritance in the role hierarchy to reduce the number of assignments that are required Simplifies administration

RBAC models
NIST (Ferraiolo et al., 1992-2000) RBAC96 (Sandhu et al., 1996) ARBAC97 (Sandhu et al., 1997-99) OASIS (Hayton et al., 1996-2001) Role Graph model (Nyanchama and Osborn, 1995-2001) Unified RBAC96 NIST model (Ferraiolo, Sandhu et al., 2001)

RBAC implementations
Roles implemented in
Window NT (as global and local groups) IBMs OS/400 Oracle 8 onwards .NET framework

There is no generally accepted standard for RBAC

Role hierarchies Semantics of role hierarchies

New challenges
How do we do access control if we cant identify subjects? How do we control the access of untrusted code running on our machine?

.NET security
Evidence-based access control
Location Code identity Code author Proof carrying code

Role-based security
Authentication Authorisation (access control)

Java security
Protection domains
The scope of a protection domain is the set of objects accessible by a principal System domains Application domains (sandboxes)

Signed applets
Digitally signed code that can be trusted by the host

Further reading

D.E. Bell and L. LaPadula. Secure computer systems: Mathematical foundations. Technical Report MTR-2547, Volume 1, Mitre Corporation, 1973. J. Saltzer and M. Schroeder. The protection of information in computer systems. Proceedings of the IEEE, 36(9):1278-1308, 1975. M.A. Harrison et al. Protection in operating systems. Communications of the ACM. 19(8):461-471, 1976. R.S. Sandhu. Lattice-based access control models. IEEE Computer, 26(11):9-19, 1993. R.S. Sandhu et al. Role-based access control models. IEEE Computer, 29(2):38-47, 1996. J. Moffett and E.C. Lupu. The uses of role hierarchies in access control. Proceedings of Fourth ACM Workshop on Role-Based Access Control, 153-160, 1999. W. Yao et al. A role-based access control model for supporting active security in OASIS. Proceedings of Sixth ACM Symposium on Access Control Models and Technologies, 171-181, 2001. http://www.vsta.org/documentation/papers/capabilities.html http://www.vsta.org/documentation/papers/microkernel.html http://www.microsoft.com/net/technical/security.asp http://java.sun.com/j2se/1.4/docs/guide/security/spec/security-specTOC.fm.html