Privtrans: Automatically Partitioning Programs for Privilege Separation

References:

Privtrans @ 2004SP1;

Privilege separation in OpenSSH2;

Partition a single program into two parts:

  • a monitor, relegated all trust an privileges; a small TCB;
  • a slave.

Q & A

  • What kind of static analysis techniques are used?

    • LLM: user annotation for privileged variables and functions; then inter-procedural static analysis to propagate attributes; “meet-over-all-path” data-flow analysis to find proper place to insert calls to the monitor.

  • What kind of dynamic analysis techniques are used?

    • LLM:

  • How to determine bounds of domain?

  • How to define the interfaces between domains?

Solution:

  • Programmer annotations. Indicates privileged operations using attributes.

    • privileged variables/functions.

  • Inter-procedural static analysis.

    • Propagates attributes
    • locate privileged functions and data

  • C-to-C translation. Partition the input source code into two programs: the monitor and the slave.

    • Data flow techniques to find proper place to insert calls to the monitor. Static + Dynamic analysis to reduce the number of expensive calls made by the slave to the monitor.
    • inserts dynamic checks: to reduce overhead by limiting the number of expensive calls from the slave to monitor ?.

  • Monitor-slave interface

    • two processes, isolated by OS.
    • commumicate via inter-process or inter-network sockets. A base RPC library is provided, as wrappers for common privileged calls

  • Allow finer-grained policies than access control.

    • policies defined by programmer;
    • policies implemented in and enforced by monitor.

overall procedure

User Annotations and Policies

Annotations: Two C type qualifier3:

  • “priv”: mark a) variable initialized from privileged resource, will be in the monitor; b) privileged functions, will be in the monitor.
  • “unpriv”: only used when downgrading a privileged variable.

annotation

Policies: A monitor policy. Specifies what operations the slave can ask the monitor to perform.

  • written in monitor as C code;
  • enforced since all privileged operations go through the monitor.
  • some can be automatically generated: CFG -> Finite State Machine (FSM) model of possible privileged calls; Pushdown Automata (PDA)

FSM call policy: - remove edges that do not lead to privileged call; got a a collapsed FSM, a directed graph of valid privileged call sequences; - FSM saved to file; read by monitor during initialization. - Requests from slave are checked against the FSM: a call is allowed only if there is an edge from the proceeding call to the current call in the FSM.

PDA to limit FSM:

  • limit the number of allowable call sequences.

PDA related work to limit the call sequences: MOPS 4, malicious call stream detection5, CIL6, Enforceable security policies7, 1999SP 8, and Automatic extraction of OO interfaces9.

???Easier to write more precise policy than system-call interposition: “In system call interposition, a model is needed for both privileged and unprivileged system calls. The policy in system call interposition is usually more complex as the number of system call increases. Privilege separation limites the number of privileged operations to only the interface exported by the monitor, which may reduce the complexity of the resulting policy.” ???

Downgrading data: allow privileged data to flow from the monitor to the slave.

Example: reading a file contain public/private key pair; file is privileged, private key is privileged, but public key can flow out.

Privtrans Analysis & Transformation

Overview:

figure 4 overview of monitor-slave arch

Attribute propagation

Call to the monitor: The slave calls privwrap: the interface provided for slave to call the monitor; 1) marshaling the arguments; 2)sending arguments, along with a vector describing the run-time privileged status of each variable, to the monitor; 3) waiting for the monitor to respond; 4) demarshaling any results; 5) return proper results to the slave;

Execution and return to monitor: The monitor calls privunwrap : 1) demarshals the arguments received; 2) checks the policy to see if the call is allowed; 3) looks up any privileged actuals in its state store; 4) performs the function; 5) if result are marked as privileged, hashes the results to its state store and set the return value of the function to be the hash index; 6) marshals the return values and sends them back to the slave.

Starting the monitor: priv_init as the first instruction in main. It can optionally

  • fork off the monitor process and drop the privileges of the slave; or

  • it contacts an running monitor. ???

  • the slave waits for notification from the monitor about successful initialization.

Locating privileged data

-> Use CIL6 to read in and transform the source code.

-> Use interprocedural static analysis to locate all potentially privileged call sites.

  • A standard meet-over-all-paths data-flow analysis: the priv attribute is added to a variable if it can be assigned to by another privileged variable over any path in the program.
  • Inter-procedural analysis by iteratively adding the privileged attribute across defined functions.
  • ??? since we do not have the function body for procedures declared but not defined, we assume that the privileged attribute could be added to any pointer argument, i.e., a pointer value could be a return value. (??? is this talking about the compatibility with library functions?)

  • ??? If an atrribute is missing, the slave will attempt a call without appropriate privileges, and the call will fail. (??? what if the attribute is not propagated to privileged function, and that function got called by slave directly?)

  • After propagation of attributes, we got a set of calls that potentially should be executed by the monitor.

-> Rewrites a call to f that may be privileged to the wrapper function privwrap_f. Then privwrap_f use RPC to ask the monitor to execution the f.

-> Insert run-time checks to limit the number of calls from the slave to the monitor.

  • static analysis is conservative, any call site that may be privileged is considered privileged;
  • combined with run-time information, the number of privileged calls could be reduced.

-> privilege polymorphic functions: can somewhere/sometime be privileged, and somewhere/sometime not privileged.

figure5 example

  1. Privtrans: Automatically Partitioning Programs for Privilege Separation. SP, 2004. ↩
  2. Preventing Privilege Escalation. SP, 2003. ↩
  3. Rationale for International Standard – Programming Languages – C. American National Standard Institutue(ANSI), Oct 1999. ↩
  4. MOPS: an infrastructure for examining security properties of software. CCS, 2002. ↩
  5. Detecting manipulated remote call streams. SP, 2002. ↩
  6. CIL: Intermediate language and tools for analysis and transformation of C programs. CCC, 2002. ↩
  7. Fred Schneider. Enforceable security policies. Information and System Security, 2000. ↩
  8. R. Sekar P Uppuluri. Synthesizing fast intrusion prevention/detection systems from high-level specifications. SP, 1999. ↩
  9. John Whaley, Michael Martin, and Monica Lam. Automatic extraction of object-oriented component interfaces. In the Proceedings of the International Symposium on Software Testing and Analysis, 2002. ↩
Created Jul 31, 2019 // Last Updated Dec 19, 2020

If you could revise
the fundmental principles of
computer system design
to improve security...

... what would you change?