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
Biba Integrity
sshd
Dominance 1 gt 2
L1
Biba Operations
L2
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 processs 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
grep
ps
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
grep
ps
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 gt 2
L1
L1
Requests write Would lower sshd to L3
L2
Remote user
14
Integrity Level Dependency

• What does a programs 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)
Type (Object)
Subject Type Can Access Object Type To Perform
Operations On Objects
Object
User
User
Object
17
SSH and DTE
Subject Types sshd remote_user
sshd
L1
Requests write Assume that sshd handles it
L2
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 (cont)

• 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
L1
Requests write UDIs must be converted to CDIs or
rejected
L2
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 wont work
sshd
L1
Requests write Can we define legitimate calls
L2
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 services function
• Have to transfer state from sshd-unprivileged to
  users 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
L1
sshd
Requests write Filtered requests only
L2
Unprivileged/User ssh
Requests write To unprivileged first
L3
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)