Access Control

CS461/ECE422Spring 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

Computer Security I 89/29/2010

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

Computer Security I 99/29/2010

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

Access Matrix: File ExampleFile 1 File 2 File3 File4

User A OwnReadWrite

OwnReadWrite

User B Read OwnReadWrite

Write Read

User C ReadWrite

Read OwnReadWrite

Access Matrix: Broader ExampleSubjects Files Processes Disks

S1 S2 S3 F1 F2 P1 P2 D1 D2

S1 control owner ownercontrol

Read* Readowner

wakeup wakeup seek owner

S2 control Write* execute owner Seek*

S3 control write stop

Mediation Implementation

Rules Governing Access Matrix ChangeRule 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

Computer Security I 169/29/2010

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

Computer Security I 179/29/2010

Windows ACL

Computer Security I 189/29/2010

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

Computer Security I 199/29/2010

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?

Computer Security I 209/29/2010

ACL Scaling• Groups of users• Role Base Access Control

– Users can take on role at a time• Directory inheritance• Negative rights

Computer Security I 219/29/2010

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?

22

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

23

Implementation

• Tags / descriptors• Cryptographic tickets• Type system

24

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

25

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

26

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

27

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

28

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)

29

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

30

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

31

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

32

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

33

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

34

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

35

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

36

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

37

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

38

Revocationclass 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();

39

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

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