Understanding Access Control Matrix in Computer and Network Security

1. CMSC 414Computer and Network SecurityLecture 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. Objects Subjects Example

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 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 referencemonitor subject object request allow/deny

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 object referencemonitor request allow/deny subject object object

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 I have the rightto read O1 referencemonitor S1 O1 allow/deny requestwithcapability Note that request is allowed/denied based on the capabilitypresented, 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 capabilitywrite(statistics, stat, compiler_capability);write(debugging_info, debug, user_capability);