Access Control
CS461/ECE422
Spring 2012
Reading Material
• Chapter 4 through section 4.5
• Chapters 25 and 26
– For the access control aspects of Unix and
Windows
Outline
• Access Control Matrix
• Access Control List
• Capabilities
Access Control in Context
AAA
• Access control part of a broader context
• Authentication
– Discussed last time. Bind external entity to system
entity
• Authorization
– Grant a right or permission to the system entity to
access a system resource
• Audit
– Independent review of system actions
Types of Access Control Policies
• Discretionary Access Control (DAC)
– Decision made based on identity of requestor and
access rules
– Regular users can adjust the policy
• Mandatory Access Control (MAC)
– Decision made by testing labels associated with
processes and resources against system policy rules
– Regular user cannot adjust the policy
• Role Based Access Control (RBAC)
– Access decisions defined against roles rather than
individual requestors
Access Control Elements
• Subject – system entity capable of access objects.
Generally a process in an OS context
• Object – a resource in a system
– Often a file
– Could also be other named resources like mutex,
process, network interface, network port
• Access right – a way that a subject may access an
object in the system
– Read, Write, Execute, Delete, Create, Search, Change
Access, Own
Access Control Matrix
• Access Matrix or Access Control Matrix
(ACM) and related concepts provides very
basic abstraction
– Map different systems to a common form for
comparison
– Enables standard proof techniques
– Not directly used in implementation
9/29/2010
Computer Security I
8
Definitions
• Protection state of system
– Describes current settings, values of system
relevant to protection
• Access control matrix
– Describes protection state precisely
– Matrix describing rights of subjects
– State transitions change elements of matrix
9/29/2010
Computer Security I
9
Access Matrix: File Example
File 1
File 2
User A
Own
Read
Write
User B
Read
Own
Read
Write
User C
Read
Write
Read
File3
File4
Own
Read
Write
Write
Read
Own
Read
Write
Access Matrix: Broader Example
Subjects
S1
S2
S3
Files
Processes
Disks
S1
S2
S3
F1
F2
P1
P2
D1
D2
control
owner
owner
control
Read*
Read
owner
wakeup
wakeup
seek
owner
Write*
execute
owner
Seek*
control
control
write
stop
Mediation Implementation
Rules Governing Access Matrix Change
Rule
Command (by S0)
Authorization
Operation
R1
Transfer α or α* to S,X
‘α*’ in A[S0,X]
Store α or α* in A[S,X]
R2
Grant α or α* to S,X
‘owner’ in A[S0,X]
Store α or α* in A[S,X]
R3
Delete α from S,X
‘control’ in A[S0,S]
or
‘owner’ in A[S0,X]
Delete α from A[S,X]
R4
w <- read S,X
‘control’ in A[S0,S]
or
‘owner’ in A[S0,X]
Copy A[S,X] into w
R5
Create object X
None
Add column for X to A;
store ‘owner’ in A[S0,X]
R6
Destroy object X
‘owner’ in A[S0,X]
Delete column X from A
R7
Create subject S
None
Add row for S to A;
execute create object S;
store ‘control’ in A[S,S]
R8
Destroy subject S
‘owner’ in A[S0,S]
Delete row for S from A;
execute destroy object S
Actually Implementing Access Matrix
• Slice by column
– Access control list
– Used by Multics and most modern OS
• Slice by row
– Capability list
– Many implementations in the ‘80’s
– Often associated with object-oriented systems
Slice and Dice File example
Unix Access Control
• Three permission octets associated with each
file and directory
– Owner, group, and other
– Read, write, execute
• For each file/directory
– Can specify RWX permissions for one owner, one
group, and one other
9/29/2010
Computer Security I
16
Windows ACL
9/29/2010
Computer Security I
17
Windows ACL
• Actually two ACL's per file
– System ACL (SACL) – controls auditing and now
integrity controls
– Discretionary ACL (DACL) – controls object
access
• Windows ACLs apply to all named objects
– Files
– Pipes
– Events
9/29/2010
Computer Security I
18
ACL Distinctions
• What subjects can modify an object's ACL?
• If there is a privileged user, do the ACLs apply to
that user?
• Does the ACL support groups or wildcards?
• How are contradictory access control
permissions handled?
• If a default permission is allowed, do the ACL
permissions modify it, or is the default only
used when the subject is not mentioned in the
ACL?
9/29/2010
Computer Security I
19
ACL Scaling
• Groups of users
• Role Base Access Control
– Users can take on role at a time
• Directory inheritance
• Negative rights
9/29/2010
Computer Security I
20
Revoking rights with ACLs
• Revoking rights for subject s to a particular
object o straightforward
– Remove s from ACL(o)
– Make sure s has a negative entry in the ACL(o)
• Example: Alice removes all of Bob's rights to
file f
– What if Bob had given Carol read rights to f?
– Should Carol still have those rights?
9/29/2010
Computer Security I
21
Capabilities
• Where are access rights stored
– ACL: Each resource (file) has an access list
– Capabilities: Each process has a capability list (C-list)
• Note: In capabilities, subjects are processes
– In ACLs, subjects are users (why?)
• Capabilities act as a ticket
– Possession of capability implies access rights
• Tickets must be unforgeable
– Otherwise access control fails
22
Implementation
• Tags / descriptors
• Cryptographic tickets
• Type system
23
Tags / descriptors
• Each process has a list of tickets
– Tickets stored in a protected segment
– Programs refer to tickets by pointers / indices
– Operating system can add / remove tickets
• E.g. CAP system
• E.g. UNIX file descriptors
– UNIX access control a hybrid system: use ACLs to open a file and get a
file descriptor, then use fd as a capability
– More efficient since only have to check permissions on open
24
Cryptographic tickets
• Cryptography
– Associate with each capability a cryptographic checksum enciphered
using a key known to OS
– When process presents capability, OS validates checksum
– Example: Amoeba, a distributed capability-based system
• Capability is (name, creating_server, rights, check_field) and is given to
owner of object
• check_field is 48-bit random number; also stored in table corresponding
to creating_server
• To validate, system compares check_field of capability with that stored in
creating_server table
• Vulnerable if capability disclosed to another process
25
Differences
• Descriptors - managed by the operating
system
• Crypto tickets - managed by the process
• Copying
– Descriptors - possible (e.g. UNIX fd passing), but
regulated by the OS
– Tickets - arbitrary copying possible
26
Revocation
• Scan all C-lists, remove relevant capabilities
– Tags / descriptors - too expensive
– Crypto tickets - impossible
• Use indirection
– Each object has entry in a global object table
– Names in capabilities name the entry, not the object
• To revoke, zap the entry in the table
– Example: Amoeba: owner requests server change random number in
server table
• All capabilities for that object now invalid
– Can have multiple entries for a single object to allow control of
different sets of rights and/or groups of users for each object
27
ACLs, Capabilities, and POLP
• Principle of least privilege
– “subject should be given only those privileges that
it needs in order to complete the task”
– Granularity of subjects controls how small “least”
is
• Capabilities better enforce least privilege
– Subjects are processes, not users, can be more
restrictive
– ACLs with roles form a middle ground (next
lecture)
28
Least privilege example
• Carol wants to use gcc to compile her file
– gcc may (does) have bugs in it
• ACLs: gcc runs with Carol’s authority
– Can overwrite any of Carol’s files
• Roles: Carol can have separate roles
– Mail role, development role, browsing role
– gcc in development role cannot overwrite other files
• Capabilities
– Carol gives gcc capabilities to read (particular) source files, write
(particular) object files
– All other files are safe
29
cp example
• Consider unix command ‘cp’
– cp file1 file2
• What’s the least authority that cp needs to
run?
– Read and write any file the user owns
• What about `cat’?
– cat < file1 > file2
– file1 and file2 passed as file descriptors
30
Confused Deputy Problem
• Compilation costs money
– Compiler writes accounting information to a file
called “BILL”
– Compiler given permission to write to “BILL”
• Using roles, setuid, …
• Compiler takes an optional argument with a
file where to write debugging output
– “gcc -d debugfile foo.c”
• User runs: “gcc -d BILL foo.c”
– Destroys billing information
31
What went wrong?
• Compiler given authority to write to BILL
– Used it for the wrong purpose
• How to solve?
– In UNIX, access() system call checks permission of
caller
– Awkward, error-prone
• Real problem: ambient authority
32
Ambient Authority
• Permission checks not controlled by user /
program
– Authority exercised automatically
– Doors that magically recognize users, instead of
using keys
• ACLs have ambient authority
• Capability systems can have ambient
authority, most don’t
– POSIX Capabilities an exception
33
Non-ambient authority
• User / program chooses which authority to
use
• E.g. billing capability
– open(“BILL”, bill_cap)
– open(debug_file, debug_cap)
• Will fail if debug_file == “BILL”
• Better yet, combine designation and authority
34
Object Capability Systems
class Compiler {
static private File billFile;
public void compile(File debugFile) {
billFile.append(billing entry);
debugFile.write(debug info);
}
}
• Permissions enforced by type system
– No way to write to a file without a reference
35
Object Capability Systems
• Object references are capabilities
– Requires memory safety (why?)
– Both names the object and grants access
• Objects are accessed through methods
– Methods mediate access
• Execution model and access model unified
• Objects are subjects as well
– Low granularity subjects
– Dynamic subject creation
36
Object Proxies
• Most policies enforced by proxy object
• E.g. read-only file access
class ReadOnlyFile {
private File myFile;
public ReadOnlyFile(File f) {
myFile = f;
}
public read() {
return myFile.read()
}
public write () { return ERROR; }
}
• Compiler.compile(ReadOnlyFile(sourceFile))
37
Revocation
class Caretaker {
Object target;
public Caretaker(Object o) { this.target = o; }
class Revocable {
match(verb, args) { call(target, verb, args); }
}
revoke() { target = null; }
}
};
Caretaker caretaker(object);
Bob.pass(caretaker.Revocable());
…
caretaker.revoke();
38
ACLs and Capabilities
• ACLs: Answer to “who can access this file”
– Useful when formulating policies
• C-List: Answer to “what files can this process
access”
– Useful in investigation
• Object capabilities don’t answer either
question, but integrate authorization decisions
in the design
39
Key Points
• Access control part of broader system
• Access Control Matrix or Access Matrix
– Means to model access control systems
• Real implementations
– Access control lists
– Capability lists
– Object capabilities