463.9 Access Control Mechanisms

1. 463.9 Access Control Mechanisms UIUC CS463 Computer Security Based on slides provided by Matt Bishop for use with Computer Security: Art and Science

2. Overview • Access control lists • Capabilities • Object capabilities

3. Required • Reading: Sections 15.1 and 15.2 • Exercises: Section 15.9 exercises 2 to 6

4. Access Control Mechanisms • Most of security concerns controlling access • Three levels of access control • High-level policy (e.g. Chinese Wall, Biba, …) • Low-level policy (access control matrix) • Mechanism

5. Access Control Lists • Columns of access control matrix file1file2file3 Andy rx r rwo Betty rwxo r Charlie rx rwo w ACLs: • file1: { (Andy, rx) (Betty, rwxo) (Charlie, rx) } • file2: { (Andy, r) (Betty, r) (Charlie, rwo) } • file3: { (Andy, rwo) (Charlie, w) }

6. Default Permissions • Normal: if not named, no rights over file • Principle of Fail-Safe Defaults • If many subjects, may use groups or wildcards in ACL • UNICOS: entries are (user, group, rights) • If user is in group, has rights over file • ‘*’ is wildcard for user, group • (holly, *, r): holly can read file regardless of her group • (*, gleep, w): anyone in group gleep can write file

7. Abbreviations • ACLs can be long … so combine users • UNIX: 3 classes of users: owner, group, rest • rwxrwxrwx rest group owner • Ownership assigned based on creating process • Group set to current group of process • Can change it to any other group the user belongs to • Some systems: if directory has setgid permission, file group owned by group of directory (SunOS, Solaris)

8. ACLs + Abbreviations • Augment abbreviations with explicit ACLs • ACLs override abbreviations • Example: IBM AIX • Base permissions are abbreviations, extended permissions are ACLs with user, group • ACL entries can add rights, but on deny, access is denied

9. Permissions in IBM AIX attributes: base permissions owner(bishop): rw- group(sys): r-- others: --- extended permissions enabled specify rw- u:holly permit -w- u:heidi, g=sys permit rw- u:matt deny -w- u:holly, g=faculty

10. ACL Modification • Who can do this? • Creator is given own right that allows this • System R provides a grant modifier (like a copy flag) allowing a right to be transferred, so ownership not needed • Transferring right to another modifies ACL • Before: File1: (Alice, rg), (Bob, rwo) • Alice grants her read right to Carol • After: File1: (Alice, rg), (Bob, rwo), (Carol, r) • Root can (usually) alter ACLs as well

11. Privileged Users • Do ACLs apply to privileged users (root)? • Solaris: abbreviated lists do not, but full-blown ACL entries do • Other vendors: varies • Used to restrict power of administrative user

12. Conflicts • Deny access if any entry would deny access • AIX: if any entry denies access, regardless of rights given so far, access is denied • Apply first entry matching subject • Cisco routers: run packet through access control rules (ACL entries) in order; on a match, stop, and forward the packet; if no matches, deny • Note default is deny so honors principle of fail-safe defaults

13. Handling Default Permissions • Apply ACL entry, and, if none, use defaults • Cisco router: apply matching access control rule, if any, otherwise, use default rule (deny) • Augment defaults with those in the appropriate ACL entry • AIX: extended permissions augment base permissions

14. Revocation Question • How do you remove subject’s rights to a file? • Owner deletes subject’s entries from ACL, or rights from subject’s entry in ACL • What if ownership not involved? • Depends on system • System R: restore protection state to what it was before right was given • May mean deleting descendent rights too …

15. Windows NT ACLs • Different sets of rights • Basic: read, write, execute, delete, change permission, take ownership • Generic: no access, read (read/execute), change (read/write/execute/delete), full control (all), special access (assign any of the basics) • Directory: no access, read (read/execute files in directory), list, add, add and read, change (create, add, read, execute, write files; delete subdirectories), full control, special access

16. Accessing Files • User not in file’s ACL nor in any group named in file’s ACL: deny access • ACL entry denies user access: deny access • Take union of rights of all ACL entries giving user access: user has this set of rights over file

17. Capability Lists • Rows of access control matrix C-Lists: • Andy: { (file1, rx) (file2, r) (file3, rwo) } • Betty: { (file1, rwxo) (file2, r) } • Charlie: { (file1, rx) (file2, rwo) (file3, w) }

18. Semantics* • 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 • Capabilities act as “tickets” • Possession of capability implies access rights • Tickets must be unforgeable • Otherwise access control fails

19. Implementation • Tags / descriptors • Cryptographic tickets • Type system

20. Tags / Descriptors • Each process has a list of tickets (e.g. CAP system) • Tickets stored in a protected segment • Programs refer to tickets by pointers / indices • Operating system can add / remove tickets • Use file descriptors (e.g. UNIX) • UNIX access control a hybrid system: use ACLs to open a file and get a file descriptor, then use descriptor as a capability • More efficient since only need to check permissions on open

21. Cryptographic Tickets • 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

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

23. *-Property • Problem with cryptographic tickets C-List Heidi (high) read lough write lough lough (Low) Lou (low) C-List write lough write lough The capability to write file lough is Low, and Heidi is High so she reads (copies) the capability; now she can write to a Low file, violating the *-property!

24. Remedies • Label capability itself • Rights in capability depends on relation between its compartment and that of object to which it refers • In example, as as capability copied to High, and High dominates object compartment (Low), write right removed • Check to see if passing capability violates security properties • In example, it does, so copying refused • Distinguish between “read” and “copy capability” • Take-Grant model can do this (“read” vs. “take”)

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

26. ACLs, Capabilities, and Least Privilege • 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

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

28. Confused Deputy • The confused deputy problem is an attack in which a principal requests an action by a deputy and exploits the authorizations of the deputy to perform actions not allowed for the principal or anticipated for the legitimate mission of the deputy.

29. Confused Deputy Example • 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

30. Analysis* • 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

31. 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 do not • POSIX capabilities an exception

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

33. Object Capability Systems • Objects are used as “capabilities” • In effect, the type system and memory model use abstraction to limit the privileges of objects • Examples: KeyKOS and EROS

34. Example 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 • 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() } } • 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: Answers “Who can access this file?” • Useful when formulating policies • C-List: Answers “What files can this process access” • Useful in investigation • Object capabilities: Answers: “Which methods/objects are accessible in this code?”

39. Key Points • Access control mechanisms provide enforcement strategies for high-level policies and their low-level instances • Three key techniques described here • Access Control Lists (ACLs) • Capabilities • Type-based privileges