Access Control Jason Crampton 14 October 2002. Overview Introduction to access control and access control structures Partial orders, lattices and their.

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

System Decision

Reference Monitor

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 Owner Group Size Updated Name

drwxr-xr-x jason Research

512 Jul 3 15:51 Research

-rw------- jason research 127092 Aug 28 15:01

Trash

-rwxr-xr-x jason research 7632 May 20 18:16

a.out

-rw-r----- jason research 0 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

trash a.out allfiles.txt

jason {r,w} {r,w,x} {r,w}

mick {r,x} {r}

ObjectsSubjects

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

trash a.out allfiles.txt

jason {r,w} {r,w,x} {r,w}

mick {r,x} {r}

ObjectsSubjects

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)?

trash a.out allfiles.txt

jason {r,w} {r,w,x} {r,w}

mick {r,x} {r}

ObjectsSubjects

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)?

trash a.out allfiles.txt

jason {r,w} {r,w,x} {r,w}

mick {r,x} {r}

ObjectsSubjects

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

• We assign all users who are tellers to the Teller role, etc.

• The Administrator role can run all the procedures

Admin

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)

– IBM’s 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 can’t 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