Presentation is loading. Please wait.

Presentation is loading. Please wait.

CMSC 414 Computer and Network Security Lecture 11 Jonathan Katz.

Similar presentations

Presentation on theme: "CMSC 414 Computer and Network Security Lecture 11 Jonathan Katz."— Presentation transcript:

1 CMSC 414 Computer and Network Security Lecture 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 l o  l s  *-property: S can write O if and only if l s  l o –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 I s  I o –I s, I o denote the integrity levels  (Integrity) *-property: S can write O if and only if I o  I s –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 o 1, …, o n and subjects s 1, …, s n-1, such that, for all i, s i can read o i and write to o i+1 –Information can be transferred from o 1 to o n via a sequence of read-write operations  Theorem: If there is an information transfer path from o 1 to o n, then I(o n )  I(o 1 ) –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(I o, I s ) –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 Bank ABank BSchool 1School 2 School 3 Company datasets files Conflict of interest (CI) class

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 ABank BSchool 1School 2 School 3 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…

Download ppt "CMSC 414 Computer and Network Security Lecture 11 Jonathan Katz."

Similar presentations

Ads by Google