330 likes | 472 Views
Access Models and Integrity. Trent Jaeger January 14, 2004. 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?
E N D
Access Models and Integrity Trent Jaeger January 14, 2004
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?
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
Integrity Example: SSH Network Connection openSSH Listen *:22 fork openSSH (forked for request) Monitor Key Exchange Time Authentication User Network Data
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)
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
Read/write Write Read Requests write Biba Integrity sshd Dominance 1 > 2 L:1 Biba Operations L:2 Remote user
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.
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
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
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
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
SSH and LOMAC sshd Dominance 1 > 2 L:1 L:1 Requests write: Would lower sshd to L3 L:2 Remote user
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
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.
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
SSH and DTE Subject Types sshd remote_user sshd L:1 Requests write: Assume that sshd handles it L:2 Remote user
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.
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
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
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
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
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
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
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
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
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?
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.
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
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.
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
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
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)