Enhanced Access Control Methods for Network Security

1. CMSC 414Computer and Network SecurityLecture 13 Jonathan Katz

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

3. Access control 3

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

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

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 6

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 7

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 8

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

10. Objects Subjects Example 10

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

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

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 13

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 14

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 15

16. Access control lists, pictorially object referencemonitor request allow/deny subject object object 16

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

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 18

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 19

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 20

21. Capabilities, pictorially I have the rightto read O1 referencemonitor S1 O1 request allow/deny 21

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 22

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

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

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

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

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 27

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

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 29

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 30

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

32. Access control policies 32

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 33

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

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

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 36

37. Discretionary access control 37

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 38

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 39

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

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

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 42