Mandatory Security Policies

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