1. Secure System Design and Access Control
Nick Feamster CS 6262 Spring 2009

2. What is Access Control?
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

3. 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
Returns a decision either granting or denying access to the user
Access Request
Reference Monitor
System Decision

4. Reference Monitor
Stallings Figure20.4 illustrates the reference monitor as a controlling element in the h/w & O/S of a computer. It regulates access of subjects to objects on the basis of their security parameters. It has access to the security kernel database, which lists the access privileges (security clearance) of each subject & the protection attributes (classification level) of each object. The reference monitor enforces the security rules (no read up,no write down). It must have properties of:
• Complete mediation: security rules are enforced on every access
• Isolation: reference monitor & database are protected from unauthorized modification
• Verifiability: reference monitor’s correctness must be provable
These are stiff requirements, usually met only by a trusted system.

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 Analogy: Files
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 Analogy: Guest List
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

8. Subjects and Objects Subject Object 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

9. 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
Refer students to Li Gong, 1999; Gasser, 1989; and SDSI, 1996.

10. 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
Sometimes called access modes or access rights
Access operations may range from basic memory access through to method calls in an object-oriented system

11. Access Control given system has identified a user
determine what resources they can access
general model is that of access matrix with
subject - active entity (user, process)
object - passive entity (file or resource)
access right – way object can be accessed
can decompose by
columns as access control lists
rows as capability tickets
Following successful logon, a user has been granted access to one or a set of hosts and applications. Associated with each user there can be a profile that specifies permissible operations and file accesses, which the operating system can then enforce.
A general model of access control is that of an access matrix, the basic elements of which are:
• Subject: An entity (typically a process) capable of accessing objects
• Object: Anything to which access is controlled, eg files, portions of files, programs, memory segments
• Access right: The way in which an object is accessed by a subject, eg. read,write,and execute
One axis of an access matrix consists of identified subjects that may attempt data access, the other lists objects that may be accessed, & each entry in the matrix indicates the access rights of that subject for that object. In practice, an access matrix is usually sparse and is implemented by decomposition in one of two ways. If decomposed by columns, you have access control lists, which list users & their permitted access rights for each object. If decomposed by rows it yields capability tickets, which specify authorized objects & operations for a user.

12. Acces 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}
mick
{r,x}
{r}
Objects
Subjects

13. 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

14. 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}
mick
{r,x}
{r}
Objects
Subjects

15. 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 s of matrix entries)

16. 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}
mick
{r,x}
{r}
Objects
Subjects

17. 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”)?

18. 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}
mick
{r,x}
{r}
Objects
Subjects

19. Capability lists Capability lists focus on the subjects Disdavantage
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”)?
Subjects present a list of capabilities to a service in a distributed system
See the use of roles in OASIS

20. Analogies Again 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)

21. Trusted Computer Systems
information security is increasingly important
have varying degrees of sensitivity of information
cf military info classifications: confidential, secret etc
subjects (people or programs) have varying rights of access to objects (information)
known as multilevel security
subjects have maximum & current security level
objects have a fixed security level classification
want to consider ways of increasing confidence in systems to enforce these rights
Another widely applicable requirement is to protect data or resources on the basis of levels of security, as is commonly found in the military where information is categorized as unclassified (U), confidential (C), secret (S), top secret (TS), or higher. Here subjects (people or programs) have varying rights of access to objects (information) based on their classifications. This is known as multilevel security. A system that can be proved to enforce this is referred to as a trusted system.

22. Control of Information in Computer Systems: Overview
Focus of paper on multiple user computer system
User authority
Who can do something to something
Who can see something
“Privacy” social
Concern here is controlling access to data (security)

23. Security Violations Unauthorized release of information
Unauthorized modification of information
Unauthorized denial of use of information

24. Definitions Protection – control access to information
Authentication – verify identity of user

25. Categories of Protection Schemes
Unprotected
Typical batch system
Physical isolation (computer room)
All or Nothing
User totally isolated in the system
No sharing of resources
Typical of early TS systems (Dartmouth BASIC)

26. Categories of Protection Schemes
Controlled Sharing
OS puts limits on access
TOPS-10 file system w/ WRX control
User-programmed Sharing Controls
Like OO files w/ access methods
User control access as he likes

27. Categories of Protection Schemes
Putting strings on information
Trace or control information after released
File retains access even when others have it
Overriding question: How controls can change over time
How is privilege changed?
Can access privilege be modified or revoked on the fly?

28. Design Principles
Since we can’t build software without flaws, we need ways to reduce number and severity of security flaws
What follows are 10 Design Principles to apply when designing and creating protection mechanisms
They were true in 1975 and remain relevant today

29. Design Principles 1. Economy of Mechanism KISS Principle
Easier to implement
Allows total inspection of security mechanism

30. Design Principles 2. Fail-safe Defaults
Default case should be to exclude access
Explicitly give right to access
The reverse is risky
i.e. find reasons to exclude
You may not think of all reasons to exclude

31. Design Principles 2. Fail-safe Defaults (cont.)
Easier to find and fix error that excludes legitimate user
He will complain
Won’t normally see error that includes illegitimate user
He probably won’t complain

32. Design Principles 3. Complete Mediation
Check every access to objects for rights
All parts of the system must check
Don’t just open the door once and allow all access after that
Authority may change
Access levels in security mechanism may change over time

33. Design Principles 4. Open Design
Don’t try security by obfuscation or ignorance
Not realistic that mechanism won’t be discovered
Mechanism should be public
Use more easily protected keys or passwords
Can be reviewed and evaluated without compromising the system

34. Design Principles 5. Separation of Privilege
2 keys are better than one
No one error or attack can cause security violation
Similar to nuclear weapons authority process
Not always convenient for user

35. Design Principles 6. Least Privilege
Programs and users should run with least feasible privilege
Limits damage from error or attack
Minimize potential interaction among privileged programs
Minimize unexpected use of privilege

36. Design Principles 6. Least Privilege (cont.)
Designing this way helps identify where privilege transitions are
Identifies where firewalls should go
Analogous to the “Need to Know” principle

37. Design Principles 7. Least Common Mechanism
Minimize mechanisms shared by all users (e.g. shared variables)
Shared data can be compromised by one user
If always shared, all users need to be satisfied
Example – shared function should be run in users space rather than as system procedure

38. Design Principles 8. Psychological Acceptability
Design for ease of use
Then it will be used and not avoided or compromised for user’s convenience
Model the mechanism so the user can easily understand
Then will use as intended

39. Design Principles 9. Work Factor
Make it cost more to compromise security than it is worth
Automation can make this principle difficult to follow
Work factor may be difficult to calculate
Perhaps Public Key Encryption falls into this category

40. Design Principles 10. Compromise Recording
Note all security breaches (and then change plan?)
E.g. note each file access time
Not very practical, since can’t tell what data has been taken or modified

41. Summary
No security system is perfect – at best we minimize the vulnerabilities
Technology may advance but engineering design principles which were good in 1975 remain relevant today