Access Control and the Bell- LaPadula Model

1. Access Control and the Bell-LaPadula Model CS 4235

2. Historical Background • Physical Access Control • No mixing of data (sensitive vs not) • Hardwired terminal access • No multiplexing of users and data • What happens when all the data is stored in the same place and users with different trust levels are allowed to access? • Multi-level security problem

3. Documents vs People • Documents have classifications • Top Secret • Secret • Confidential • Unclassified • Sensitive • Non sensitive • People have Clearances • Top Secret • Secret • Q

4. There are also code words that are not classifications • ULTRA identified information encrypted with Enigma machines • Categories – now material is handled • Sensitive compartmented information (SCI) - Intelligence • Operations and methods • Nuclear secrets • Stealth • Special Access Programs (SAP) -- Defense • Acknowledged • Unacknowledged • Waived • Solves two logistical problems • Collateral clearances for everyone would be expensive • Need to limit information to those with need to know • SIGMA (Department of Energy) • SAP/SCI requires Secure Compartmented Information Facility (SCIF)

5. Caveats and Other Codes • NOFORN • RESTRICTED • NO CONTRACTOR • REL TO <Country Code> • ORCON • FOUO • PROPIN • SECRET//<compartment name>//NOFORN//ORCON//25X1

6. People are cleared to • Classification levels • Categories • Other Labels

7. Discretionary Access Control • E.g., Unix permissions • Set access conditions on a file so that only a group of your choosing can read it • Anyone with access can propagate the information by resetting permissions

8. Mandatory Access Control • Security authority sets permissions • Only security authority can propagate information • Violations are very serious

9. Orderings • TS > S > C • How about • (S//NUC//NOFORN) vs TS? • (TS//EUR/25x1) vs (TS//CRYPTO//PROPIN)?

10. Access Control Models (S,O,R)  YES/NO • Read (observe) • Write (observe, alter) • Execute (no observe, no alter) • Append (alter, no observe)

11. Accesses take system from state to state All accesses must be allowed by MAC rules σ2 (T,b, append) σ3 (S,a, read) σ1 If you start in a secure state do you end up in a secure state?

12. Granting Access Should Not Violate MAC High Level Object ? READ Flow of information Subject WRITE Object LowLevel

13. Simple Security Property • The current level of a subject dominates the level of every object that it observes • Like paper systems • “No read up”

14. *-Property • If S can observe a and alter b, then a ≤ b • “No write down”

15. Partial Orders • S = {a1,a2,…,an} • P = (S, ≤) is a PO iff • If a ≤ b and b ≤ a, then a = b (anti-symmetric) • If a ≤ b and b ≤ c, then a ≤ c (transitive) • a ≤ a (reflexive) • Examples • Natural numbers under ≤ • Subsets under  • How about • Choices on a ballot under “is preferred to”? • People under “trusts”?

16. Lattices • A POSET S • Every subset of S has a greatest lower bound • Every subset of S has a least upper bound x3 x4 x5 x1 x2 These are all upper bounds x LUB S Subset of S

17. Security Levels • A security level is a pair (c,s) where • c is a classification from a POSET of classifications (e.g., U,S,TS but the exact classfications don’t matter) • s is a set of categories (e.g., NUC,CRYPTO,… but the exact categories don’t matter) • (c1,s1) ≥ (c2,s2) iff c1 ≥ c2 and s2s1 • Levels form a lattice

18. Assigning Security Levels to Subjects and Objects • level(S), level(O) = security level of S,O • current-level(S) = levels at which S can operate • current-level(S) ≤ level(S) • level(S) = max(current-level(S)) is called S’s clearance

19. Security Properties • SS-property: For any (S,O,A) if A includes observation then level(S) ≥ level(O) • *-property For any (S,O,A) r A implies current-level(S) ≥ level(O) a A implies current-level(S)≤level(O) w A implies current-level(S) = level(O) No read up No write down If a subject can observe O1 and modify O2 the level(O2)≥level(O1)

20. Lattice Model Information only flows up the lattice System enforces SS and * properties

21. A MAC Implementation • Unix file system • Label all files and directory with levels • Assign level(u) to each user u • u is initially assigned the lowest current-level • Allow current-level(u) to float as higher level files are observed • If level(u) < current-level(u) issue kill(u) • If level(f) < level(u) and u writes to f issue kill(u) • Is this secure?

22. Covert Channels • Low bandwidth • Outside the models • Channel not designed for communication • Shared resource • Allows information to be transmitted from High to Low (*-property violation) • Semantics Scotland Yard Detective Gregory : "Is there any other point to which you would wish to draw my attention?“ Holmes: "To the curious incident of the dog in the night-time.“ Gregory: "The dog did nothing in the night-time.“ Holmes: "That was the curious incident

23. Example • High Process: If bit i of protected file is 1 then position disk head at time t = i outside the current volume • Low Process: detect position of head at time t=i

24. Types of Channels • Storage channel • Timing channel • Sequential process ids • Shared file locks • File access times • Application channels • IRC Signalling

25. Other Access Control Models • Biba Integrity Model • Lampson-Graham-Denning • Harrison-Ruzzo-Ullman • Take-Grant

26. Trusted Systems • Orange Book • Trusted Network Interpretation • Common Criteria • European and Candadian Criteria

27. Trust Levels • D – no requirements • C1/C2/B1 – commercial strength security features • B2 – rigorous demonstration of security by mathematical analysis (“proof”) • B3/A1 – formal designs and mathematical proof

28. Commercial Protection • C1 • Discretionary security protection • Cooperating users • All data at same senistivity level • Tamper-resistant • C2 • Controlled access protection • Finer grained than C1 • Audit trails • B1 • Labeled security protection • Each subject and object assigned its own level • Bell-Lapadula • DAC to provide further controls

29. Structured Protection and Security Domains • B2 = B1 + Design Requirement • Verifiable Top Level Design • Testing to verify that implementation satisfies design • Design consisting of well-defined independent modules • Principle of Least Privilege enforced • B3 = B2 + Testing Requirements • Small, tamperproof security functions • Audit functions required • High level design that is complete and conceptually simple • Convincing argument that system implements design • Exhibits good design practice • Layering • Abstraction • Information hiding

30. A1 = Formally Verified = B3 + the following • Formal model of the protection systems and a mathematical proof of its consistency and adequacy • Formal top-level specification of the protection system • Demonstration that the specification conforms to the model • Implementation informally shown to be consistent with the specifications • Formal analysis of covert channels

31. Modern Trust Models • Capability-based • MAC and DAC Implemented using same mechanisms • Heavy reliance on application trust features • Hardware enforced separation • Virtualization and Hypervisors

32. An Early Hypervisor TCPA

33. Itanium® Processor (IA-64) Architecture • High performance on encryption protocols • Fine-grained memory protection • Two additional levels of privilege protection

34. IA-64 Privilege Level 0 • Access to • Privileged system registers • Privileged instructions • Page creation • Direct access to physical memory • Invoking PL-0 from PL-1 to PL-3 • Interrupts • Explicit PL-0 request “epc”

35. Secure platform architecture • Root of trust in protected memory of trusted platform • Secure Platform Kernel (SPK) loaded by secure boot • Operating systems are ported to the SPA

36. Structure of Secure Platform • Abstracts ABI, physical resources and interrupts • PL-0 reserved for SPK: minimal certified code (known to CRTM) • PL-1 hosts global services for • I/O notification • Multiple OS images • Protection domains • Non-OS applications • PL-2 hosts OS images • Applications reside in PL-3

37. SP Characteristics • Secure paging • Operating systems and device drivers run as unprivileged tasks • Privileged operations are authenticated and performed by secure platform kernel • Self-healing data structures • “Baileys” separate SPK, SPGS and OS

38. “How does it work?” • multiple containment rings inherently limit intrusion • operating systems and device drivers run as unprivileged tasks • privileged operations are authenticated and performed by secure platform kernel • code and data are protected from inadvertent and malicious execution or modification • multiple OS images run securely on the same system

39. SP Virtual Addressing • Region ID’s provide • Memory isolation • Protection keys • Fine-grain permission control • Upper half of Region 7 reserved for SPK/SPGS • Operating Systems run virtual in lower half of Region 7 • Regions 0-6 available for OS assignment • SPK • manages region ID assignments • Allocates pages for mapping virtual addresses

40. Privileged Operations • OS executes as unprivileged task at PL-2 • Privileged functions invoked by epc call • Lightweight paths are implemented for simple operations

41. Unprivileged Callbacks • Similar to Unix signals • Interrupts handled by SPK • UPC mechanism enables asynchronous notification to a less privileged level • Exceptions and faults that cannot be handled by SPK are passed to the SPGS

42. Secure paging • Protection for data on paging device • Device theft • Raw device access • Requires pre-allocated shadow page pool • Penaly: 1 cycle per bit using 128 bit key • Keys are hidden in SPK, accessed through handles

43. Denial of Service Attacks • SPK signals PL-2 which never returns • Attacker repeats instruction path • Context stack grows until SPK fault • Asynchronous UPC thwarts attack • SPK executes single thread • Eventually fails to allocate space for UPC list entry • PL-2 process fails • SPK never has to unwind context stack

44. Services • Data protection • Client integrity • Authorized network connection • Remote attestation • Web administration • Connected laptop • Mobile services • Virus definition reporting • Remote management • Smart card function (eg two factor authorization) • Public hot desking • Trusted kiosk • First responder Services