Access Control

1. Access Control CS461/ECE422 Spring 2012

2. Reading Material • Chapter 4 through section 4.5 • Chapters 25 and 26 • For the access control aspects of Unix and Windows

3. Outline • Access Control Matrix • Access Control List • Capabilities

4. Access Control in Context

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

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

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

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

9. 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 Computer Security I

10. Access Matrix: File Example

11. Access Matrix: Broader Example

12. Mediation Implementation

13. Rules Governing Access Matrix Change

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

15. Slice and Dice File example

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

17. Windows ACL Computer Security I

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

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

20. ACL Scaling • Groups of users • Role Base Access Control • Users can take on role at a time • Directory inheritance • Negative rights Computer Security I

21. 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? Computer Security I

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

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

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