1 / 39

463.9 Access Control Mechanisms

463.9 Access Control Mechanisms. UIUC CS463 Computer Security. Based on slides provided by Matt Bishop for use with Computer Security: Art and Science. Overview. Access control lists Capabilities Object capabilities. Required. Reading: Sections 15.1 and 15.2

Download Presentation

463.9 Access Control Mechanisms

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.


Presentation Transcript

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

More Related