Access Control Models: A Brief Introduction
Download
Report
Transcript Access Control Models: A Brief Introduction
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
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
Objects
Subjects
jason
mick
trash
a.out
allfiles.txt
{r,w}
{r,w,x}
{r,w}
{r,x}
{r}
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
jason
mick
trash
a.out
allfiles.txt
{r,w}
{r,w,x}
{r,w}
{r,x}
{r}
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
jason
mick
trash
a.out
allfiles.txt
{r,w}
{r,w,x}
{r,w}
{r,x}
{r}
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
jason
mick
trash
a.out
allfiles.txt
{r,w}
{r,w,x}
{r,w}
{r,x}
{r}
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