1 / 26

Capability-Based Access Control

Capability-Based Access Control. CSCI283-172 Fall 2008 GW Sources: Memon’s notes, Brooklyn Poly Bishop’s Text, Chapter 15 Bishop’s slides, Chapter 15 Text by Pfleeger and Pfleeger, Chapter 4. Access Control Mechanisms. Access Control Matrix Access Control List

szeno
Télécharger la présentation

Capability-Based Access Control

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. Capability-Based Access Control CSCI283-172 Fall 2008 GW Sources: Memon’s notes, Brooklyn Poly Bishop’s Text, Chapter 15 Bishop’s slides, Chapter 15 Text by Pfleeger and Pfleeger, Chapter 4

  2. Access Control Mechanisms • Access Control Matrix • Access Control List • Capability based access control • Lock and Key based access control. • Rings-based access control CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  3. Capability based access control. • Conceptually, capability is a row of ACM i.e. list of rights for a subject. • Definition: Let O be set of objects, and R the set of rights of a system. A capability list c is a set of pairs C = {(o, r): oO, r  R} Let cap be function that determines capability list c associated with subject s. Then cap(s) = {(oi, ri):1 i n} is that subject s may access oi using any right in ri. CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  4. Capabilities Capability-based control: turn ACL on its head: indexed by subject and not object A capability is a “license” of sorts, stored as a token Stored by OS, secure, cryptographic protection, transferable Eg: digital rights associated with a media asset CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  5. Capability Lists • Rows of access control matrix file1file2file3 Andy rx r rwo Betty rwxo r Charlie rx rwo w C-Lists: • Andy: { (file1, rx) (file2, r) (file3, rwo) } • Betty: { (file1, rwxo) (file2, r) } • Charlie: { (file1, rx) (file2, rwo) (file3, w) } CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  6. Semantics • Like a bus ticket • Mere possession indicates rights that subject has over object • Object identified by capability (as part of the token) • Name may be a reference, location, or something else • Subject without capability cannot name object satisfactorily • Must prevent process from altering capabilities • Otherwise subject could change rights encoded in capability or object to which they refer • Major difference from ACL, which is controlled by OS CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  7. Implementation • Tagged architecture • Bits protect individual hardware words from being modified • E.g. B5700 (Burroughs processor): tag was 3 bits and indicated how word was to be treated (pointer, type, descriptor, etc.) • Paging/segmentation protections • Like tags, but put capabilities in a read-only segment or page • Programs must refer to capabilities by pointers • Otherwise, program could use a copy of the capability—which it could modify CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  8. Implementation (con’t) • Cryptography • Associate with each capability a cryptographic checksum (digital signature) enciphered using a key known to OS • When process presents capability, OS validates checksum • Example: Amoeba, a distributed capability-based system • Capability is (name, creating_server, rights, check_field) and is given to owner of object • check_field is 48-bit random number; also stored in table corresponding to creating_server • To validate, system compares check_field of capability with that stored in creating_server table • Vulnerable if capability disclosed to another process CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  9. Example: Amoeba Amoeba: a distributed system highly optimized for performance and not hamstrung by backwards-compabilityfrom: http://www-db.stanford.edu/~manku/quals/summaries/wagner-amoeba.htm • On creation of an object, capability corresponding to object is returned to owner. • To later use object, owner presents capability. • Capability encoded name of object (24 bits), the server that created it (48 bits), rights (8 bits, initially all set), and 48 bit random “check” field. • Random number stored in table of server that created object. When capability presented, number checked. • Attacker who does not know random number cannot forge capability. • If capability disclosed, system becomes vulnerable. CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  10. Copying Capability • Copying capability means giving rights. How do you allow copying? • Amoeba: X wants Y to read object O which X owns. X asks server for copy of capability to access O, but restricted to reading. • Server sets only read bit in rights field, XOR’s with random check and result is hashed. Output of hash is used as random check for this new capability. • On receiving capability with at least one bit set to zero, server takes rights field and XOR’s with original random check and hashes. If hash matches that presented in the capability, access is allowed. • Different capability cannot be forged. CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  11. Amplifying • Allows temporary increase of privileges • Example*: • Java applet allowed to draw text on the screen, • but not to read files • It may need to read fonts from files, it is temporarily allowed to do so *From Xavier Leroy, “Computer security from a programming language and static analysis perspective”. CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  12. Revocation • Scan all C-lists, remove relevant capabilities • Far too expensive! • Use indirection • Each object has entry in a global object table • Names in capabilities name the entry, not the object • To revoke, zap the entry in the table • Can have multiple entries for a single object to allow control of different sets of rights and/or groups of users for each object • Example: Amoeba: owner requests server change random number in server table • All capabilities for that object now invalid CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  13. Limits • Problems if you don’t control copying of capabilities The capability to write file lough is Low, and Heidi is High so she reads (copies) the capability; now she can write to a Low file! CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  14. Remedies • Label capability itself • Rights in capability depends on relation between its compartment and that of object to which it refers • In example, as capability copied to High, and High dominates object compartment (Low), write right removed • Check to see if passing capability violates security properties • In example, it does, so copying refused • Distinguish between “read” and “copy capability” • Take-Grant Protection Model does this (“read”, “take”) CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  15. Comparison of ACL and capability • Two questions arise in access control systems: • Given a subject, what objects can access it and how? • Given an object, what subjects can access it and how? • Former easier with capabilities and latter with ACL. • Latter more often asked, hence ACL’s used more often. • With more distributed processing and agent based systems, perhaps the former question will be asked more in the future. CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  16. Example: NT Access Tokens and Security Identifiers (SID) • Created by the Local Security Authority after SAM (security account manager) validation, as part of a successful logon process. • Stays with that particular user's session for as long as they stay logged on. • Whenever a user initiates a process during the course of the session, a copy of the token is attached to that process. • Once the user logs off, the token is destroyed and will never be used again. CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  17. NT Tokens • Each token contains the following information: • User’s Security Identifier (SID) • Group Security Identifiers • User privileges • Owner (SID assigned to any objects created during the session) • Primary Group SID • Default ACL (assigned to any object created by the user) CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  18. NT User Rights • 27 specific 'user rights' that can be assigned (or restricted) to users or groups in NT. These include • the ability to access a computer from the network, • to change the system time, • to log onto the system locally, • the ability to take ownership of objects, and even • to shut down the system. • password restrictions, • logon times, • remote access capabilities, • group memberships etc. CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  19. NT Built-in Groups • Built-in users and groups have pre-defined rights and permissions • Global built-in groups – Domain Admins, Domain Users, Domain Guests • Local built-in groups – Administrators, Backup Operators, Users, Guests, Etc. • Special built-in groups exist that can be used to define appropriate access permissions • Everyone • Interactive • Network • Creator Owner • System • Etc. CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  20. NT Mandatory Profiles • User profile defines the user’s environment and the programs he is able to invoke. • Mandatory profiles cannot be changed by a user • For example editlevel can be used to limit how users can modify their program manager • 0 – All changes permitted • 1 – Prevents users from creating, deleting or renaming groups • 2 – All of above plus no creating or deleting program items • 3 –All of above plus prevents users from changing command lines for program items • 4 – All of above plus prevents users from changing any program item information. CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  21. NT Discretionary Access Controls (DAC) • Provide object and resource owners the means to control who can access resources as well as how much access they may have. • Access to system resources, such as files, directories and folders, printers, network shares, and system services, can be controlled either through GUI-based system tools or through the command line. • The NT Explorer, • Print Manager, • User Manager for Domains, and • Server Manager CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  22. NT Access Control Lists (ACL) • Each object contains a security descriptor, which has • Security Identifier of the person who owns the object, • The regular ACL for access permissions, • The system ACL (SACL) which is used for auditing • specifies which actions (performed by specific users or groups) cause NT to write audit events to the NT Security Log. • A group security identifier. • ACL may be composed of Access Control Entries (ACE) which are composed of • Basic permissions (six individual permissions), • Standard permissions which are combinations derived from the basic permissions. CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  23. Basic Permissions • Read (R) • Write (W) • Execute (X) • Delete (D) • Change Access Permissions (P) • Take Ownership (O) CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  24. NTFS ACL Standard Permissions CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  25. NTFS ACL Standard Permissions CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

  26. NT Domains • A domain is a set of computers with a central security authority, the primary domain controller (PDC), that grants access to a domain. • PDC and the BDC (Backup) must be Windows NT. • A domain can be set up to • Ease viewing and access to resources, • Share a common user account database and security policy, • Enforce a common security stance across physical, divisional, or corporate boundaries. • Elimination of the need for every machine to provide its own authentication service. • Users authenticated to the domain, can gain access to resources, such as printing, file sharing or applications, across all of the servers. CS283-172/Fall08/GW/Vora Many slides from Matt Bishop's slide set

More Related