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

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

3. 3 Access control

4. 4 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.)

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

6. 6 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 and analyzed so as to ensure correctness

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

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

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

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

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

12. 12 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”

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

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

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

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

17. 17 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)

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

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

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

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

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

23. 23 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!

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

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

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

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

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

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

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

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

32. 32 Access control policies

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

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

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

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

37. 37 Discretionary access control

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

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

40. 40 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”

41. 41 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…

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