Access Control

1
Access Control

• Jason Crampton
• 14 October 2002

2
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

3
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

4
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
5
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

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

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

8
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

9
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

10
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

11
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

12
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

13
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

14
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

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

16
UNIX ls command
17
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

18
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

19
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
20
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

21
The access control matrix

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

Objects
Subjects
22
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)

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

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

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

28
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

29
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

30
Aggregation techniques

• User groups
• Roles
• Procedures
• Data types

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

32
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

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

34
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
35
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

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

37
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

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

39
.NET security

• Evidence-based access control
• Location
• Code identity
• Code author
• Proof carrying code
• Role-based security
• Authentication
• Authorisation (access control)

40
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

41
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/capabilit
  ies.html
• http//www.vsta.org/documentation/papers/microkern
  el.html
• http//www.microsoft.com/net/technical/security.as
  p
• http//java.sun.com/j2se/1.4/docs/guide/security/s
  pec/security-specTOC.fm.html