1 / 25

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

umay
Download Presentation

CMSC 414 Computer and Network Security Lecture 18

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 18 Jonathan Katz

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

  3. Objects Subjects Example

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

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

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

  7. Mediation • More fine-grained control can sometimes be achieved via mediation/indirection

  8. Mediation Compare: to:

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

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

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

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

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

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

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

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

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

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

  19. Capabilities, pictorially I have the rightto read O1 referencemonitor S1 O1 allow/deny requestwithcapability Note that request is allowed/denied based on the capabilitypresented, not based on capabilities held

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

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

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

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

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

  25. 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 capabilitywrite(statistics, stat, compiler_capability);write(debugging_info, debug, user_capability);

More Related