CMSC 414 Computer and Network Security Lecture 11

1. CMSC 414Computer and Network SecurityLecture 11 Jonathan Katz

2. Announcements • Midterm • Closed book, closed notes • Covers material through today’s lecture • Everything linked from the course syllabus • HW2 out

3. “Capability myths…” • Equivalence myth: ACLs and capabilities are “just” two views of the AC matrix • Confinement myth: Capability systems cannot enforce confinement • That is, cannot restrict delegation • Irrevocability myth: Capabilities cannot be revoked

4. Equivalence myth • ACLs have “arrows” from objects to subjects; capabilities have “arrows” from subjects to objects • Capabilities do not require subjects to “know” object names a priori • Capabilities do not require subjects to “know” whether they have authority • They have authority by virtue of the fact that they have a capability! • In contrast, with ACLs how do I obtain a list of all files I am allowed to read?

5. Equivalence myth • Capabilities allow for finer-grained treatment of subjects • Processes rather than user accounts • ACLs potentially require objects to be aware of all subjects • Capabilities allow greater flexibility to delegate permissions • In ACLs, usually all-or-nothing • In capability-based systems, can delegate a subset of the rights you have

6. Confinement myth • Myth: Capabilities can be delegated “at will” and therefore cannot be confined • But…can be set up so that A can delegate a capability to B only if A is authorized to pass capabilities to B • If B is untrusted, then the latter capability will not exist

7. Origin of confinement myth • Mistaken assumption that the ability to write/read files translates into the ability to read/write capabilities • Capabilities should not be viewed as “just” files; they can be typed by the OS

8. Revocation • One solution: indirection • Capabilities name an entry in a table, rather than the object itself • To revoke access to object, invalidate or change 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

9. Advantages of capabilities • Better at enforcing “principle of least privilege” • Provide access to minimal resources, to the minimal set of subjects • We have seen already that capabilities allow much finer-grained control over subjects (process-level instead of user-level)

10. Advantages… • Avoiding “confused deputy” problem • “Deputy” = program managing authorities from multiple sources • In the example we have seen, the problem was not the compiler having the wrong authority, but of exercising its authority for the wrong purpose

11. Confused deputy… • Capabilities give the ability to identify the authority a subject is using • Can designate use of the authority for a specific purpose • Capabilities also tie together designation and authority • Don’t “know” about a resource if you don’t have the capability to access it! • Any request to access a resource must include the necessary authority to do so --- “deputy” can now examine the context of the request

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

13. Mandatory access control

14. “Military security policy” • Primarily concerned with secrecy • 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 lattice … classifications/clearance not necessarily hierarchical

15. Security models • Bell-LaPadula model • Identifies allowable communication flows • Concerned primarily with ensuring secrecy • Biba model • Concerned primarily with “trustworthiness”/integrity of data • Chinese wall • Developed for commercial applications

16. Bell-LaPadula 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 • Why? • “Read down; write up” • Information flows upward

17. Dynamic rights • Could consider dynamic rights • Once a process reads a file at one security level, cannot write to any file at a lower security level

18. Basic security theorem • If a system begins in a secure state, and always preserves the simple security condition and the *-property, then the system will always remain in a secure state • I.e., information never flows down…

19. Communicating down… • How to communicate from a higher security level to a lower one? • 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

20. Commercial vs. military systems • The Bell-LaPadula model does not work well for commercial systems • Users given access to data as needed • Discretionary access control vs. mandatory access control • Would require large number of categories and classifications • Centralized handling of “security clearances”

21. 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 classifications • Confidentiality vs. trustworthiness • Information flow vs. information modification

22. Biba model • Simple integrity condition: S can read O if and only if Is Io • Is, Io denote the integrity levels • (Integrity) *-property: S can write O if and only if Io Is • Why? • The information obtained from a subject cannot be more trustworthy than the subject itself • “Read up; write down” • Information flows downward

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

24. “Low-water-mark” policy • Variation of “pure” Biba model • If s reads o, then the integrity level of s is changed to min(Io, Is) • The subject may be relying on data less trustworthy than itself • So, its integrity level is lowered • Drawback: the integrity level of a subject is non-increasing!

25. Chinese wall • Intended to prevent conflicts of interest • Rights are dynamically updated based on actions of the subjects

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

27. Chinese wall rules • Subject S is allowed to read from at most one company dataset in any CI class • This rule is dynamically updated as accesses occur • See next slide…

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

29. Chinese wall rules II • S can write to O only if • S can read O and • All objects that S can read are in the same dataset as O • 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! • Note that S can write to at most one dataset…