Access Control: ACLs vs. Capabilities, Security Models, and Policy

1. CMSC 414Computer and Network SecurityLecture 19 Jonathan Katz

2. ACLs vs. capabilities • With capabilities, subjects are explicitly aware of the permissions they hold • Generally a good thing • But difficult to make a file world-readable • Capabilities allow fine-grained treatment of processes as subjects • I.e., caller can invoke a process with arbitrary subset of its rights • With ACLs, processes by default run with the same permissions as the caller

3. ACLs vs. capabilities • Capabilities allow for easier delegation • Even of subsets of rights • Revocation is easier with ACLs • Though still possible with capabilities • Trade-off: finding all subjects who have access to some object, vs. finding all objects that some subject can access

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

5. Revoking capabilities • Revocation of access to a file 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 just one user • Capabilities can also expire with time • If OS stores capabilities, can delete upon request • Requires object to recall to whom capabilities given

6. Access control policies

7. Access control policies • Discretionary access control (DAC) • Owners of objects can set permissions arbitrarily (subject to what is supported by the system) • Mandatory access control (MAC) • System determines access control • Role-based access control (RBAC) • Access determined by users’ roles • Not necessarily mutually exclusive • May use different mechanisms for different resources • Or, apply two policies; allow access only if both allow

8. Mandatory access control

9. Security models • Multilevel security (military applications) • Bell-LaPadula model • Identifies allowable communication flows • Concerned primarily with ensuring secrecy • Biba model • Concerned primarily with “trustworthiness”/ integrity • Multilateral security (corporate application) • Chinese wall • Concerned with preventing conflicts of interest

10. Security levels • A multilevel security model assumes that every subject and object is assigned a security level • These security levels are arranged in a lattice • I.e., a DAG that defines a partial ordering on the security levels (note that some levels may be incomparable)

11. “Military security policy” • A particular example of a lattice • Objects given “classification” (rank; compartments) • Subjects given “clearance” (rank; compartments) • “Need to know” basis • Subject with clearance (r, C) dominates object with classification (r’, C’) only if r’ ≤ r and C’  C • Defines a partial order … classifications/clearance not necessarily hierarchical

12. Bell-La Padula model • Simple security condition: S can read O if and only if lO lS • *-property: S can write O’ if and only if lS lO • “Read down; write up” • Information flows upward • Why? • Information flow • Could be due to a malicious insider, or a benign mistake

13. Basic security theorem • If the Bell–La Padula rules are enforced, then no information in an object at level lO can leak into an object at level lO’ < lO

14. Communicating down… • How to communicate from a higher security level to a lower one? • (Not necessarily declassification; instead, moving unclassified data from a classified machine to an unclassified machine) • Max. security level vs. current security level • Maximum security level must always dominate the current security level • Reduce security level to write down… • Security theorem no longer holds • Must rely on users to be security-conscious

15. Commercial vs. military systems • The Bell-LaPadula model does not work well for commercial systems • Users should be given access to data as needed • Discretionary access control vs. mandatory access control • Would require using a large number of categories and classifications • Requires centralized handling of “security clearances” • Poor usability

16. Biba model • Concerned with integrity • “Dual” of Bell-LaPadula model • The higher the level, the more confidence • More confidence that a program will act correctly • More confidence that a subject will act appropriately • More confidence that data is trustworthy • Integrity levels may be independent of security levels • Confidentiality vs. trustworthiness • Information flow vs. information modification

17. Biba model • IS, IO denote integrity levels • (Integrity) *-property: S can write O iff IO IS • The information obtained from a subject cannot be more trustworthy than the subject itself • Simple integrity condition: S can read O iff IS  IO • S should depend on higher-quality sources only • “Read up; write down” • Information flows downward

18. Security theorem • An information transfer path is a sequence of objects o1, …, on and subjects s1, …, sn-1, such that, for all i, si can read oi and write to oi+1 • Information can be transferred from o1 to on via a sequence of read-write operations • Theorem: If there is an information transfer path from o1 to on, then I(on)  I(o1) • Informally: information transfer does not increase the trustworthiness of the data • Note: says nothing about secrecy…

19. Chinese wall • Intended to prevent conflicts of interest • E.g., consulting firms • Rights are dynamically updated based on actions of the subjects

20. Chinese wall • Objects are grouped into datasets (e.g., all files associated with some client) • Datasets are groups into conflict-of-interest (CoI) classes (e.g., all datasets related to banks)

21. Chinese wall -- basic setup Company datasets Bank A Bank B School 1 School 2 School 3 Conflict of interest (CoI) class files

22. Chinese wall rules • Subject S is allowed to read from at most one company dataset in any CoI class • This rule is dynamically updated as accesses occur • See next slide… • Formally: S can read from dataset X iff it has not previously read from any other dataset in the same CoI class as X

23. Example Bank A Bank B School 1 School 2 School 3 read read

24. Chinese wall rules II • S can write to dataset X only if • S can only read from dataset X • Note: either S cannot write at all, or can only write to one dataset • This is intended to prevent an indirect flow of information that would cause a conflict of interest • E.g., S reads from Bank A and writes to School 1; S’ can read from School 1 and Bank B • S’ may find out information about Banks A and B!