1 / 24

CMSC 414 Computer and Network Security Lecture 19

CMSC 414 Computer and Network Security Lecture 19. Jonathan Katz. 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

zulmat
Download Presentation

CMSC 414 Computer and Network Security Lecture 19

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

More Related