1. CMSC 414 Computer and Network Security Lecture 18 Jonathan Katz

2. Access control matrix  Matrix indexed by all subjects and objects –Characterizes rights of each subject with respect to each object  Formally: set of objects O and subjects S, set of possible rights  Matrix with subjects labeling the rows and objects labeling the columns –The entry (s, o) contains the rights for s on o –Examples: read/write/execute/etc.

3. Example File 1File 2File 3…File n User 1{r,w}{w}{r,w} User 2{w} {r,w} User 3{r}{w} … User k{r} {r,w}{r}{w} Subjects Objects

4. Granularity/complexity  In theory, arbitrary level of granularity, e.g., –Subjects: functions within processes –Objects: characters within files –Rights: write, append, increment-only, delegation, …  In practice, a decision must be made as to the level of granularity that will be supported

5. Granularity/complexity  Trade-off is obvious: –Fine-grained access control gives “better security” Least privilege –Coarse-grained access control more efficient

6. Example: Unix granularity  Subjects: users –Users can be in groups –Users can change their current group (to any group of which they are a member)  Objects: files –Specify access rights for the owner, the group to which the owner belongs, and other  Rights: read, write, execute

7. Mediation  More fine-grained control can sometimes be achieved via mediation/indirection

8. Mediation Accounting data Alicerw Accounting program Accounting data Alicex Accounting program rrw Compare: to:

9. Mediation/indirection  Alice can read and write the accounting data –But she shouldn’t be allowed to arbitrarily modify the accounting data!  Solution: mediate access via the accounting program –Note that now the accounting program may potentially have to implement access control for different users –Vulnerabilities in the accounting program can potentially be exploited…

10. Example: Unix mediation  By default, programs run with the rights of the user calling the program –What if users need to be able to access a restricted file (e.g., /etc/passwd)?  Executables have a ‘setuid flag’ that can be set by the owner of the executable –If set, the program runs with the rights of the file owner  Running programs have a uid and an effective uid –If setuid off, uid=euid=caller –If setuid on, uid=caller, euid=owner

11. Access control matrix  The access control matrix provides a conceptual way to think about the rights in the system  It can also be a way to implement access control subject request reference monitor allow/deny object

12. Drawbacks of access control matrix  An access control matrix is useful conceptually, but would be inefficient if used to actually implement access control –Number of subjects/objects is very large (|S| x |O| x |R|) –Most entries blank/default –One central matrix modified every time subjects/objects are created/deleted or rights are modified Central point of failure in the system, heavy load –“Small’ change can result in “many” changes to the access control matrix E.g., making a file publicly readable

13. Solutions  Compress the access control matrix –E.g., use groups/roles (will discuss later with regard to role-based access control) –Coarse-grained access rights to get better efficiency  Store the matrix by its columns or rows –Access control lists (ACLs) and capabilities –This also ends up reducing the storage

14. Access control lists (ACLs)  Can be viewed as storing the columns of the access control matrix with the appropriate object  Ideally, one list per object showing all subjects with access and their rights –Missing subjects given “default” access  OS will have to check ACL (using the subject associated with the program) each time a program tries to access an object  Used in, e.g., Unix

15. Access control lists, pictorially subject request reference monitor allow/deny object S 1 : {r, w} S 2 : {w} S 3 : {r, w} S 4 : {}

16. Advantages and disadvantages  Advantages –Well suited for users managing rights on their own files –Fits well with how OS’s manage files  Disadvantages –Not well suited when subjects constantly being added/deleted, or where delegation of rights is desired –Can be difficult to revoke all access of a subject, or to find all files that a subject is able to access –Difficult to manage in distributed systems (e.g., multiple copies of a file that should always have the same access rights)

17. Capabilities  Can be viewed as storing the rows of the access control matrix with the appropriate subject  View subject as having a “ticket” which grants access to an object –A capability is an unforgeable token giving user access to an object and describing the allowed access –In principle, can be very expressive (capability could represent a predicate that is evaluated)

18. Capabilities: two approaches  Ticket is held by the OS, which returns to the subject a pointer to the ticket  Ticket is held by the user, but protected from forgery by cryptographic mechanisms –How…? –Ticket can then be verified by the OS, or by the object itself (e.g., if the object is a server) Well suited for distributed systems

19. Capabilities, pictorially S1S1 request with capability reference monitor allow/deny O1O1 I have the right to read O 1 Note that request is allowed/denied based on the capability presented, not based on capabilities held

20. Advantages of capabilities  Better at enforcing “principle of least privilege” –Provide access to minimal resources, to the minimal set of subjects  See next example

21. Example use of capabilities  From “The Confused Deputy,” by Hardy  Compiler in directory SYS –User can provide file for debugging output –Compiler writes statistics to SYS/stat Compiler allowed to write to SYS  User set debugging file to SYS/billing –Allowed… –The effect was to overwrite the billing file!

22. Pseudocode // Say argv[1] = “SYS/billing” stat = fopen(“SYS/stat”, “rw”); // allowed! debug = fopen(argv[1], “rw”); // allowed! write(statistics, stat); write(debugging_info, debug);

23. Example continued…  Underlying problem: authority from two sources: static + authority of caller –The problem was not the compiler having the wrong authority, but exercising its authority for the wrong purpose  How to solve this problem? –Check filenames explicitly? They can change… Legitimate access to SYS files… –Add specific list of conditions? Complexity grows –Straightforward use of ACLs does not work… (why?)

24. Suggested solution  Use capabilities: –Give compiler capability to write to SYS/stat Compiler does not even need to be aware of the filename it is writing to; the capability takes care of this –Caller can provide additional capabilities, as needed –Compiler must explicitly designate capabilities to use in a particular situation In this case, will designate the capabilities presented by the caller!

25. Pseudocode // Say argv[1] = “SYS/billing” stat=fopen(“SYS/stat”, “rw”, compiler_cap); // allowed! debug = fopen(argv[1], “rw”, user_capability); // not allowed! Compiler has access, // but not using that capability write(statistics, stat, compiler_capability); write(debugging_info, debug, user_capability);