CMSC 414 Computer and Network Security Lecture 13

CMSC 414 Computer and Network Security Lecture 13 Jonathan Katz

Announcement ¨ Midterm exam Oct. 28, covering material through Oct. 21 2

Access control 3

Some terminology ¨ Protected entities: “objects” O ¨ Active objects: “subjects” S (i. e. , users/processes) – Note that subjects can also be objects – Typically, each subject associated with some principal/owner • In identity-based access control, security policies ultimately refer to the human users who are the principals ¨ Subjects/objects can be: – Files – Processes – Functions/variables (within a program) – System resources (servers, printers, etc. ) 4

Access control ¨ Determining who has access to specific files, or other system resources subject request reference allow/deny object monitor 5

Secure mediation ¨ Security kernel, Trusted Computing Base (TCB) – Responsible for implementing the reference monitor ¨ Must be tamper-resistant ¨ Must be ‘impossible’ to circumvent – I. e. , all access to objects must be mediated by the TCB ¨ Ideally, small and simple enough that it can be tested analyzed so as to ensure correctness 6

Authentication vs. authorization ¨ Authentication – Determining the identity of a user – May also involve verification of IP address, machine, time, etc… – Determine whether a user is allowed to access the system at all – Used for audit, not just authorization – We will return to this later; for now we assume it ¨ Authorization – Assuming identity of user is known, determine whether some specific action is allowed 7

General principles ¨ Fine-grained access control is better – E. g. , control access to files not just directories ¨ Least privilege – Grant minimum abilities necessary to complete task ¨ Closed vs. open policies – Closed = disallowed unless explicitly allowed – Open = allowed unless explicitly disallowed 8

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 A 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. 9

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

Access control matrix ¨ The access control matrix provides a useful 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 11

More complex access control ¨ In general, “rights” may be functions – “Actual” rights depend on the system state – Equivalently, may depend on system history ¨ Rights can form hierarchies – E. g. , right X implies right Y ¨ How fine-grained the access control is depends on how fine-grained the rights are – E. g. , “write” vs. “append-only” 12

Coarse-grained access control ¨ Access control can also be more coarse-grained than a full-blown access matrix would imply ¨ E. g. , in unix: – For a file, specify access rights for the owner, the group to which the owner belongs, and everyone else – Possible rights are: read, write, execute 13

Drawbacks of access control matrix ¨ Number of subjects/objects is very large ¨ Most entries blank/default ¨ One central matrix modified every time subjects/objects are created/deleted or rights are modified ¨ “Small’ change can result in “many” changes to the access control matrix – E. g. , making a file publicly readable 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 – Easy to make an object public 15

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

ACLs in practice ¨ Again, full granularity may not be supported ¨ E. g. , unix allows permissions set for the owner of the file, the group to which the owner belongs, and everyone else (all) 17

Conflicts? ¨ Need a mechanism for handling conflicts ¨ E. g. , what if group has fewer rights than all? ¨ Resolution (in unix) if user = owner then owner permission else if user in group then group permission else all permission ¨ In general, could have been done differently 18

Capabilities ¨ Can be viewed as storing the rows of the access control matrix with the appropriate subject – Analogy: user has a “ticket” which grants access to an object – A capability is an unforgeable token giving user access to an object and describing the level of allowable access – Capabilities can specify new types of rights 19

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 20

Capabilities, pictorially I have the right to read O 1 S 1 request reference allow/deny monitor O 1 21

ACLs vs. capabilities ¨ Access control list – ACL associated with each object – Upon request, check user/group against the ACL – Relies on authentication of the user ¨ Capabilities – Can be passed from one user/process to another – Upon request, check validity of capability • No need to know the identity of the user/process making the request 22

ACLs vs. capabilities ¨ How would delegation be handled using ACLs vs. using capabilities? – ACL: run process using the name of the caller, or OS can explicitly support delegation – Capabilities: allow delegation “for free” ¨ How can a user make a file public when capabilities are used? – Maybe it’s a good thing that this is hard to do! 23

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

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

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

More advantages of capabilities ¨ When a subject holds a capability for an object, it knows it has access to that object – In contrast, with ACLs it is impossible for a subject to obtain a list of all files it is allowed to read ¨ Capabilities allow finer-grained treatment of subjects – E. g. , at the process level rather than the user level – Why can’t this be done with ACLs? ¨ Capabilities allow easier delegation – In ACLs, usually all-or-nothing (if allowed at all) – With capabilities, can delegate a subset of the rights you have 27

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

Confinement myth ¨ Myth: Capabilities can be delegated “at will” and therefore cannot be confined ¨ Mistaken assumption that the ability to write/read files translates into the ability to read/write capabilities – Capabilities are not “just” files; they can be typed by the OS ¨ Can be set up so that A can delegate a capability to B only if A is authorized to pass capabilities to B 29

Revoking capabilities ¨ Revocation is more difficult with capabilities than with ACLs… ¨ One solution: indirection – Capabilities name an entry in a table, rather than the object itself – To revoke access to object, invalidate the entry in the table – Difficult to revoke access of a single user ¨ Capabilities can also expire with time ¨ If OS stores capabilities, can delete upon request – Requires object to recall to whom capabilities given 30

Disadvantages of capabilities ¨ Overhead ¨ Revocation more difficult ¨ Controlling delegation more difficult ¨ Making files world-readable more difficult (impossible? ) 31

Access control policies 32

Access control policies ¨ Discretionary access control (DAC) ¨ Mandatory access control (MAC) ¨ Role-based access control (RBAC) ¨ Not necessarily mutually exclusive – A system may use different mechanisms for different resources – Or, apply two policies; allow access only if both allow 33

DAC ¨ Controls based on the identity of the user and access rules ¨ Rights can be delegated at users’ discretion ¨ Most common 34

MAC ¨ Controls based on comparing security labels with security clearances ¨ Delegation not allowed ¨ Primarily used in military environments 35

RBAC ¨ Controls based on a user’s (or program’s) role, not their identity ¨ User’s rights can change depending on their current role ¨ More recent proposal 36

Discretionary access control 37

Discretionary access control ¨ Access control rights determined (to some extent) by users themselves, not by the system – I. e. , users ‘own’ certain resources, and can decide who has access to them and not ¨ E. g. , chmod in unix 38

Delegation (one approach) ¨ We augment the access control matrix to include subjects as objects – A[S, S] = “control” always – When S creates S’, a new column and row is created; A[S, S’] is set to “control” ¨ Rights on other objects can also come with or without a “copy flag” set – Allows delegation, either with or without delegation of copy flag – Denote by adding ‘*’ to the right 39

Delegation (by S) ¨ Delegate {r, r*} on X to S’ by S allowed if any of the following hold – A[S, X] = r* (i. e. , S has right r on X, and copy flag set) – A[S, X] = “owner” (i. e. , S owns X) – A[S, X] = r and A[S, S’] = “control” (i. e. , S has right r on X, and S created S’) ¨ Delete {r} on X from S’ by S allowed if any of the following hold – A[S, X] = “owner” – S[S, S’] = “control” 40

Creating a new subject ¨ When S creates S’, why not populate row S’ with the same access rights that are in row S? – Least privilege… 41

Note ¨ The OS can be treated as a subject with all rights ¨ Examples – When Alice logs in do: • Create shell process p with rights appropriate for Alice • Delegate ownership of p to Alice – When Alice creates a file • OS creates file f • OS delegates {own, read, write} to Alice on file f 42