1 / 42

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. Access control. Some terminology. Protected entities: “objects” O Active objects: “subjects” S (i.e., users/processes)

jdianne
Télécharger la présentation

CMSC 414 Computer and Network Security Lecture 13

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related