CMSC 414 Computer and Network Security Lecture 18

CMSC 414 Computer and Network Security Lecture 18 Jonathan Katz

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.

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

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

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

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

Mediation ¨ More fine-grained control can sometimes be achieved via mediation/indirection

Mediation Compare: Accounting data Alice rw to: Accounting program Alice x Accounting program r Accounting data rw

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…

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 an effective uid – If setuid off, uid=euid=caller – If setuid on, uid=caller, euid=owner

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 allow/deny object monitor

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

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

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

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

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)

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)

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

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

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

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!

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

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

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!

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