1 / 56

Mandatory Security Policies

Mandatory Security Policies. CS461/ECE422 Spring 2012. Reading Materials. 13.1–13.4 in the text. Overview. Remainder of MAC Bell- LaPadula Confidentiality Model Biba Integrity Model Lipner’s Integrity Model Clark-Wilson Integrity Model. MAC vs DAC.

deliz
Download Presentation

Mandatory Security Policies

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. Mandatory Security Policies CS461/ECE422 Spring 2012

  2. Reading Materials • 13.1–13.4 in the text

  3. Overview • Remainder of MAC • Bell-LaPadulaConfidentiality Model • Biba Integrity Model • Lipner’s Integrity Model • Clark-Wilson Integrity Model

  4. MAC vs DAC • Discretionary Access Control (DAC) • Normal users can change access control state directly assuming they have appropriate permissions • Access control implemented in standard OS’s, e.g., Unix, Linux, Windows • Access control is at the discretion of the user • Mandatory Access Control (MAC) • Access decisions cannot be changed by normal rules • Generally enforced by system wide set of rules • Normal user cannot change access control schema • “Strong” system security requires MAC • Normal users cannot be trusted

  5. Confidentiality Policy • Goal: prevent the unauthorized disclosure of information • Deals with information flow • Integrity incidental • Multi-level security models are best-known examples • Bell-LaPadula Model basis for many, or most, of these

  6. Security Levels • Most basic example of security class • Each subject and object has a security level • The levels are completely ordered • For example • Top secret > secret > confidential > restricted > unclassified • The subject’s level is security clearance • The object’s level is security classification

  7. Security Level Example

  8. Simple Security Property • No Read Up • Subject can only read an object of less or equal security level. • Level(0) <= Level(S)

  9. No write down • *-Property • A subject can only write into an object of greater or equal security level. • Level(S) <= Level(O)

  10. DAC in MAC • ds-property • A MAC system may also include a traditional discretionary access control check • If *-property and simple security property checks pass, then also check the discretionary access rules

  11. More Advanced Security Class • Simple linear ordering not adequate for larger system • Add set of categories to the security level to create a security label, • E.g., top secret:{project1, project2}. As clearance, subject is cleared to top secret only for project 1 and project 2 not project 3. • Set of security labels forms a partial ordering or a lattice

  12. Comparing Security Labels • Replace < operator with dominates operator • (A1, C1) dominates (A2, C2) iff A2 <= A1 and C2 subset of C1 • Replace <= with dominate and simple security condition and *-property holds

  13. Example Lattice of Categories CS461, CS411, CS463 CS461, CS411 CS461, CS463 CS411, CS463 CS461 CS411 CS463

  14. Security Label Comparisons • Susan Label = Secret:{461, 498} • Igor Label = Secret:{461} • Student label = Confidential:{461} • Susan writes exam for CS461 • What label should it have, so Igor can help write? • What label should it have for student to read exam?

  15. Adding Security Clearance Flexibility • Define maximum and current level for subjects • maxlevel(S) domcurlevel(S) • In some systems, the min level is also defined • *-property: allow write iff Level(O) domcurlevel(S) • simple security property: • Allow read iffmaxlevel(S) dom Level(O) • Raisecurlevel(S) to join(Level(O),curlevel(S)) • How does this ease the previous example?

  16. Principle of Tranquility • Raising object’s security level • Information once available so some subjects is no longer available • Usually assume information has already been accessed, so this does nothing • Lowering object’s security level • The declassification problem • Essentially, a write down, violates *-property

  17. Types of Tranquility • Strong tranquility • The clearances of subjects, and the classification of objects, do not change during the lifetime of the system • Weak tranquility • The clearances of subjects and the classifications of the objects change in accordance with a specified policy.

  18. Biba Integrity Model Basis for all 3 models: • Set of subjects S, objects O, integrity levels I, relation ≤ II holding when second dominates first • min: III returns lesser of integrity levels • i: SOI gives integrity level of entity • rSO means sS can read oO • w, x defined similarly Biba 77

  19. Intuition for Integrity Levels • The higher the level, the more confidence • That a program will execute correctly • That data is accurate and/or reliable • Note relationship between integrity and trustworthiness • Important point: integrity levels are not security levels

  20. O1 S2 O2 S3 O3 Information Transfer Path • An information transfer path is a sequence of objects o1, ..., on+1 and corresponding sequence of subjects s1, ..., sn such that siroi and siwoi+1 for all i, 1 ≤ i ≤ n. • Idea: information can flow from o1 to on+1 along this path by successive reads and writes

  21. Strict Integrity Policy • Dual of Bell-LaPadula model • sS can read oO iff i(s) ≤ i(o) • sS can write to oO iff i(o) ≤ i(s) • s1S can execute s2 O iff i(s2) ≤ i(s1) • Add compartments and discretionary controls to get full dual of Bell-LaPadula model • Information can flow only down • no reads down, no writes up • Term “Biba Model” refers to this

  22. Time Notion of time • Strict policy may be too strict High Integrity O2 write S1 read Low Integrity O1

  23. Low-Water-Mark Policy • Idea: a subject’s integrity level changes with time • Tracks the lowest integrity level object it has read • Rules • sS can write to oO if and only if i(o) ≤ i(s). • If sS reads oO, then i(s) = min(i(s), i(o)), wherei(s) is the subject’s integrity level after the read. • s1S can execute s2S if and only if i(s2) ≤ i(s1).

  24. O1 S2 S2 O2 S3 S3 O3 Information Flow and Model • If there is information transfer path from o1O to on+1O, enforcement of low-water-mark policy requires i(on+1) ≤ i(o1) for all n

  25. Problems • Subjects’ integrity levels decrease as system runs • Soon no subject will be able to access objects at high integrity levels • Alternative: change object levels rather than subject levels • Soon all objects will be at the lowest integrity level • Crux of problem is model prevents indirect modification • Because subject levels lowered when subject reads from low-integrity object

  26. Ring Policy • Idea: subject integrity levels static • Rules • sS can write to oO if and only if i(o) ≤ i(s). • Any subject can read any object. • s1S can execute s2S if and only if i(s2) ≤ i(s1). • Eliminates indirect modification problem • Does the information flow constraint hold?

  27. Integrity Matrix Model • Lipner proposed this as first realistic commercial model • Combines Bell-LaPadula, Biba models to obtain model conforming to requirements • Do it in two steps • Bell-LaPadula component first • Add in Biba component Lipner 82

  28. Requirements of Integrity Policies • Users will not write their own programs, but will use existing production programs and databases. • Programmers will develop and test programs on a non-production system; if they need access to actual data, they will be given production data via a special process, but will use it on their development system. • A special process must be followed to install a program from the development system onto the production system. • The special process in requirement 3 must be controlled and audited. • The managers and auditors must have access to both the system state and the system logs that are generated. Lipner 82

  29. Bell-LaPadula Clearances • 2 security clearances/classifications • AM (Audit Manager): system audit, management functions • SL (System Low): any process can read at this level

  30. Bell-LaPadula Categories • 5 categories • D (Development): production programs in development but not yet in use • PC (Production Code): production processes, programs • PD (Production Data): data covered by integrity policy • SD (System Development): system programs in development but not yet in use • T (Software Tools): programs on production system not related to protected data

  31. Subjects Security Level Ordinary users (SL, { PC, PD }) Application developers (SL, { D, T }) System programmers (SL, { SD, T }) System managers and auditors (AM, { D, PC, PD, SD, T }) System controllers (SL, {D, PC, PD, SD, T}) and downgrade privilege Users and Security Levels

  32. Objects Security Level Development code/test data (SL, { D, T }) Production code (SL, { PC }) Production data (SL, { PC, PD }) Software tools (SL, { T }) System programs (SL,  ) System programs in modification (SL, { SD, T }) System and application logs (AM, { appropriate }) Objects and Classifications

  33. Lipner Lattice AM, {...} S: System Managers O: System Logs SL, {PC,PD,D,T,SD} S: System Controllers SL, {SD,T} S: System programmers O: Tools inmodification SL, {PC, PD} S: Ordinary users O: Production data SL, {D, T} S: Developers O: Development code SL, {T} O: Software Tools SL, {PC} O: Production Code SL, {} O: System programs

  34. Ideas • Ordinary users can execute (read) production code but cannot alter it • Ordinary users can alter and read production data • System managers need access to all logs but cannot change levels of objects • System controllers need to install code (hence downgrade capability) • Logs are append only, so must dominate subjects writing them

  35. Check Requirements • Users have no access to T, so cannot write their own programs • Applications programmers have no access to PD, so cannot access production data; if needed, it must be put into D, requiring the system controller to intervene • Installing a program requires downgrade procedure (from D to PC), so only system controllers can do it

  36. More Requirements 4. Control: only system controllers can downgrade; audit: any such downgrading must be audited 5. System management and audit users are in AM and so have access to system state and logs

  37. Problem • Too inflexible • An application developer cannot run a program for repairing inconsistent or erroneous production database • Application programmers are not given access to production data • So add more …

  38. Adding Biba • 3 integrity classifications • ISP (System Program): for system programs • IO (Operational): production programs, development software • ISL (System Low): users get this on log in • 2 integrity categories • ID (Development): development entities • IP (Production): production entities

  39. Simplify Bell-LaPadula • Reduce security categories to 3: • SP (Production): production code, data • SD (Development): same as D • SSD (System Development): same as old SD

  40. Subjects Security Level Integrity Level Ordinary users (SL, { SP }) (ISL, { IP }) Application developers (SL, { SD }) (ISL, { ID }) System programmers (SL, { SSD }) (ISL, { ID }) System managers and auditors (AM, { SP, SD, SSD }) (ISL, ) System controllers (SL, { SP, SD, SSD }) and downgrade privilege (ISP, { IP, ID}) Repair (SL, { SP }) (ISL, { IP }) Users and Levels

  41. Objects Security Level Integrity Level Development code/test data (SL, { SD }) (ISL, { ID } ) Production code (SL, { SP }) (IO, { IP }) Production data (SL, { SP }) (ISL, { IP }) Software tools (SL,  ) (IO, { ID }) System programs (SL,  ) (ISP, { IP, ID }) System programs in modification (SL, { SSD }) (ISL, { ID }) System and application logs (AM, { appropriate }) (ISL,  ) Repair (SL, {SP}) (ISL, { IP }) Objects and Classifications

  42. Ideas • Security clearances of subjects same as without integrity levels • Ordinary users need to modify production data, so ordinary users must have write access to integrity category IP • Ordinary users must be able to write production data but not production code; integrity classes allow this • Note writing constraints removed from security classes

  43. Clark-Wilson Integrity Model • Integrity defined by a set of constraints • Data in a consistent or valid state when it satisfies these • Example: Bank • D today’s deposits, W withdrawals, YB yesterday’s balance, TB today’s balance • Integrity constraint: TB = D + YB –W • Well-formed transaction move system from one consistent state to another • Issue: who examines, certifies transactions done correctly? Clark, Wilson 87

  44. Entities • CDIs: constrained data items • Data subject to integrity controls • UDIs: unconstrained data items • Data not subject to integrity controls • IVPs: integrity verification procedures • Procedures that test the CDIs conform to the integrity constraints • TPs: transaction procedures • Procedures that take the system from one valid state to another

  45. Any IVP AllCDI Certification Rule 1 CR1 When any IVP is run, it must ensure all CDIs are in a valid state CR1

  46. TP CDIset CR2 CR2 For some associated set of CDIs, a TP must transform those CDIs in a valid state into a (possibly different) valid state • Defines relation certified that associates a set of CDIs with a particular TP • Example: TP balance, CDIs accounts, in bank example CR2

  47. TP CDIset CR1 and ER1 ER1 The system must maintain the certified relations and must ensure that only TPs certified to run on a CDI manipulate that CDI. ER1

  48. User CDISet TP Log(CDI) Other Rules ER2 The system must associate a user with each TP and set of CDIs. The TP may access those CDIs on behalf of the associated user. The TP cannot access that CDI on behalf of a user not associated with that TP and CDI. • System must maintain, enforce certified relation • System must also restrict access based on user ID (allowed relation) ER3 ER2/CR3 CR4

  49. User CDISet TP Log(CDI) Other Rules CR3 The allowed relations must meet the requirements imposed by the principle of separation of duty. ER3 ER2/CR3 CR4

  50. User CDISet TP Log(CDI) Other Rules ER3 The system must authenticate each user attempting to execute a TP • Type of authentication undefined, and depends on the instantiation • Authentication not required before use of the system, but is required before manipulation of CDIs (requires using TPs) ER3 ER2/CR3 CR4

More Related