Access Models and Integrity

1. Access Models and Integrity Trent Jaeger January 14, 2004

2. Commercial v Government Goals • Control of confidentiality is paramount in government/military • Control of integrity is paramount in commercial environment • Can they use the same policy models? • Are any new mechanisms required for integrity enforcement?

3. Integrity Issue • Bell-LaPadula and Biba dual • But, Bell-LaPadula has some practical analogues • Biba is impractical because • Higher integrity processes may legitimately use lower integrity data • There are so many instances that upgraders are impractical (because they are domain-specific) • We examine integrity in more detail and discuss alternatives

4. Integrity Example: SSH Network Connection openSSH Listen *:22 fork openSSH (forked for request) Monitor Key Exchange Time Authentication User Network Data

5. SSH Integrity • Privileged operations • Key exchange and rekeying • Authentication • Create and cleanup pseudo-terminals • Depends on integrity of • Users’ public key files • Low integrity data • Read remote user inputs • Execute user programs (done as user identity in UNIX)

6. Integrity Management Options • System Integrity Enforcement • Biba integrity • Low water mark (LOMAC) • Domain and type enforcement (DTE) • Clark-Wilson • Managed integrity • Language-based integrity • Privilege separation

7. Read/write Write Read Requests write Biba Integrity sshd Dominance 1 > 2 L:1 Biba Operations L:2 Remote user

8. Low Water Mark • Dynamic model over subject integrity labels • the lowest integrity label of the objects read by a subject • References • K. Biba. Integrity considerations for secure computer systems. Technical Report ESD-TR-76-372, US Air Force. April 1977. • M. Cheheyl, M. Gasser, G. Huff, J. Millen. Verifying Security. ACM Computing Surveys, 13(3) pp. 279-240, September 1981. (opposite view – dynamic object labels for secrecy). • Timothy Fraser. LOMAC: Low water-mark integrity protection for COTS environments. In Proceedings of the 2000 IEEE Symposium on Security and Privacy.

9. Self-Revocation Problem in LOMAC • Self-Revocation Problem • Process starts with high integrity • Open high integrity object o1 • Read from low integrity object o2 • LOMAC semantics reduce process’s integrity to low • No longer can write to o1 • Inconsistent with UNIX semantics for open files

10. Self-Revocation Example Step 1: initial state ps grep pipe Step 2: ps reads low file ps grep pipe Step 3: demotion ps grep pipe Step 4: pipe write denied ps grep pipe

11. Unnamed Pipe Possession Rule Step 1: initial state – unnamed pipes simply connect subjects of same level ps grep pipe Step 2: ps reads low file ps grep pipe Step 3: demotion of all processes in process group and pipe ps grep pipe Step 4: pipe write succeeds ps grep pipe

12. Unnamed Pipe Usage Rule • Previous does not work when • Processes in different groups have access to same unnamed pipe • Occurs when a shell creates a new process group via setpgrp • Shell forks source and sink processes and gives them the unnamed pipe • Solution: • Unnamed pipe is owned by first process group to use it • Works because the shell does not actually use the pipe • Slightly different approach used for shared memory

13. SSH and LOMAC sshd Dominance 1 > 2 L:1 L:1 Requests write: Would lower sshd to L3 L:2 Remote user

14. Integrity Level Dependency • What does a program’s integrity impact depend on? • User (Biba) • Job(s) (RBAC) • Objects read (LOMAC) • Objects modified • Objects executed • Differences between Objects Read and Objects Executed • Objects Read is superset of Objects Executed • Objects Executed may control integrity of Objects Read • Thus, Objects Read may be too aggressive

15. Domain and Type Enforcement • Type Enforcement with • Subject transitions based on the program being run (objects executed) • Since Type Enforcement is as access matrix model • Mapping from objects to integrity level is implicit • Mapping assumes any low integrity object reads can be sanitized • Mapping could be wrong • Lee Badger, Daniel F. Sterne, David L. Sherman, and Kenneth M. Walker. A domain and type enforcement UNIX prototype. USENIX Computing Systems, 9(1):47--83, Winter 1996.

16. Type Enforcement [BoebertKain84] Permission Assignment Object User Type (Subject) Subject Type Can Access Object Type To Perform Operations On Objects Type (Object) Object User User Object

17. SSH and DTE Subject Types sshd remote_user sshd L:1 Requests write: Assume that sshd handles it L:2 Remote user

18. SAFKASI – Language-based integrity • Run untrusted code in same address space as trusted code • Assumes type safety of language • Use special operation (e.g., BeginPrivilege()) to define privileged operation • Prevent the “Confused Deputy Problem” • Code is invoked in an environment controlled by the attacker • SELinux problem – specify faulty input library and log location to overwrite password file • Dan S. Wallach, Edward W. Felten, and Andrew W. Appel, The Security Architecture Formerly Known as Stack Inspection: A Security Mechanism for Language-based Systems, ACM Transactions on Software Engineering and Methodology, volume 9, number 4, October 2000.

19. Clark-Wilson Integrity • Goal • “No user, even if authorized, may be permitted to modify data items in such a way that assets … are lost or corrupted.” • Pre-computer commercial policy goals • Separation of duty • Well-formed transactions • Model Intuition • Base secure computing on well-formed transactions • Provide independent testing (e.g., balancing the books) • Enable enforcement of separation of duty

20. Well-formed Transaction • Definition • Prescribed means of modifying data • With means to preserve data integrity • Example: Double Entry Bookkeeping • Any modification must consist of two parts • Action and a balance • E.g., When writing a check there must a corresponding entry in accounts payable

21. Separation of Duty • Definition • Divide a process into subparts • Each subpart is performed by a different person • Example • A person who certifies a well-formed transaction may not execute it • Susceptible to collusion • Static vs Dynamic Separation of Duty • Static: Each user has a specific subpart • Dynamic: Can perform a subpart, but is then excluded from another • Typically, execution subtasks are required to be separated from certification subtasks

22. Mandatory Commercial Control • Authenticate users (same as for military) • Associate permissions with programs that implement well-formed transactions • Each user is associated with a valid set of programs to be run • Audit relevant events (similar to accountability in military, but different events) • Both require a reference monitor to enforce policies

23. Clark-Wilson Model • Object labels: Constrained and unconstrained data items • Apply integrity enforcement to constrained data items • Processes: Transformation Procedures • Well-formed transaction • Auditing: Integrity Verification Procedures • Verify that CDIs conform to integrity specification • Semantics • IVPs prove system is in a valid state • Only TPs can modify CDIs • CDIs modified by other processes are effectively downgraded • Repeat

24. Certification and Enforcement • Summary – Data-TP assignment • Certification (C1): IVPs ensure CDIs are valid • Certification (C2): TPs are valid • Take CDIs from one valid state to another • TP-CDI relation: sets of CDIs for a TP • Enforcement (E1): Only manipulation of a CDI is by a TP as specified in C2 • Separation of Duty • Enforcement (E2): TP-user-CDI – not solely TP-user • Certification (C3): E2 relations must be certified for SoD

25. Certification and Enforcement (con’t) • Authentication • Enforcement (E3): Must authenticate users who execute TPs • Why no certification of this mechanism? • Audit • Certification (C4): All TPs are certified to write append-only logs of security decisions • Handling of low-integrity data • Certification (C5): TPs that depend on UDIs must be certified to perform valid UDI transforms (to CDI) or reject • Enforcement (E4): Only authorized agents can certify • E4 makes policy mandatory

26. SSH and Clark-Wilson Clark-Wilson Requires C1: IVP to verify inputs C2: CDIs for sshd E1: CDIs mod by TPs E2: Admin is user C3: Certify sshd users E3: sshd authenticates C4: sshd logging C5: sshd handles UDIs E4: valid certification sshd L:1 Requests write: UDIs must be converted to CDIs or rejected L:2 Remote user

27. Clark-Wilson Summary • Integrity impact is based on TP (Objects executed) • Impact of Objects Read is controlled by certified IVPs and TPs • Certification requirements are significant • IVP, TP, Access assignments, Audit log generation, UDI handling • Practical considerations • Explicit IVPs are rare (C1) • UDI handling is notoriously bad in systems (buffer overflows) (C5) • Certification is very expensive (C1-C5) • Administration overhead is high (E4) • Ensuring that only TPs modify CDIs is never done (E1) • What approaches may enable some facets of CW? • What constraints need to be relaxed/revised in practice?

28. Managed Integrity • For an integrity target (e.g., DTE integrity) • Find integrity conflicts • Policy statements that violate conflict • Resolve conflicts • Change system: Remove subjects or objects • Clark-Wilson: Specify means for handling low integrity data • LOMAC: Artifacts that enable resolution • Language: Programming language primitives to enable management • Policy: Modify constraints or permissions • Trent Jaeger, Reiner Sailer, Xiaolan Zhang. Analyzing integrity protection in the SELinux example policy. In Proceedings of the 12th USENIX Security Symposium, August 2003.

29. SSH and Managed Integrity Change System: Must have sshd Clark-Wilson: Filter or reject requests LOMAC: Sshd still high integrity Programming Lang: Not supported in C Policy change: Sshd won’t work sshd L:1 Requests write: Can we define legitimate calls L:2 Remote user

30. Application Decomposition • Separate application into privileged and unprivileged components • Remote input to unprivileged instead • Do as much processing in unprivileged as possible • For few remaining requests, unprivileged sends formatted input to privileged • Complete service’s function • Have to transfer state from sshd-unprivileged to user’s sshd via privileged • Niels Provos et al. Preventing privilege escalation. In Proceedings of the 12th USENIX Security Symposium, August 2003.

31. SSH and Privilege Separation L:1 sshd Requests write: Filtered requests only L:2 Unprivileged/User ssh Requests write: To unprivileged first L:3 Remote user

32. Access Control Models • Aggregated Models • Useful when aggregations are fixed and have a practical analogue • Inheritance and constraints are not well understood • Constraints are needed for safety (do we meet security goals) • Lattice Access Control Models • Derived from military secrecy (have a practical analogue) • Safety is implicit, but downgraders are ad hoc • Can verify lattice properties statically when labels are static • Domain Transitions and Integrity • Dynamic subject relabel triggered by execution or read • Low integrity data must be handled by high(er) integrity processes • Solutions: lower subjects, implicit integrity, certification, explicitly manage, privilege separation • Other Models • Predicate Models: dynamic rule-based approach • Safety Models: Limited models to enable verifiable safety

33. Clark-Wilson Mechanisms Needed • Clark-Wilson Requirements • Ensure a data item are manipulated only by well-formed transactions • Verify integrity of well-formed transaction code • Protect integrity of well-formed transaction code • Limit user to subset of programs based on separation of duty • A very different mechanism is needed • Justified by Multics having distinct mechanisms for MLS and DAC • However, SELinux uses the same mechanism for MLS and DTE (slightly different policy generation)