1. Containment and Integrity for Mobile Code Status Report to DARPA ISO: Feb. 2000 Fred B. Schneider Andrew Myers Department of Computer Science Cornell University Ithaca, New York 14853

2. 1 Trustworthy Networked Information Systems: New Challenges l Extensible components –flexible, efficient fine-grained access control –application-specific security policies l Mistrustful (cooperating) hosts –source and contents of information for authorization –decentralized trust management l Interactions of fault-tolerance and security –replication increases opportunities for compromise –code mobility adds new dimensions to fault-tolerance

3. 2 Trustworthy Networked Information Systems: New Solutions Under investigation: l In-lined reference monitors l Secrecy via annotated-program rewriting l Asynchronous proactive secret sharing l Gossip protocols l Mobile code integrity: –NAP protocols (primary-backup revisited) –Cryptographic-based privilege management

4. 3 Reference Monitor Monitors execution to prevent bad behavior. Implementation requires... –Capturing policy-relevant events –Protecting reference monitor from subversion Program RM Kernel RM Program Kernel Program Kernel RM Kernel supportedInterpreterModified application

5. 4 In-lined Reference Monitors When mechanism inserted into the application... –Allows policies in terms of application abstractions. –Pay only for what you need. –Enforcement without context switches into kernel. –Isolates state of enforcement mechanism. Program Kernel RM

6. 5 Building In-lined Reference Monitors l Implemented by object-code modification. l Fundamental issues: –Does the application behave the same? –Can the application subvert the reference monitor? l Pragmatic issues: –What polices can be enforced? –What is the overhead of enforcement? App P Policy Rewriter Secure App

7. 6 What Policies can be Enforced? Class EM enforcement mechanisms: Monitor a target system and terminate any execution that is about to violate the security policy. EM includes reference monitors and other operating systems and hardware-supported mechanisms. EM allows … Principle of Least Privilege: Allow only those accesses needed to get the job done.

8. 7 Security automata Thm: Every EM enforceable security policy can be characterized by some security automaton. Thm: EM enforceable security policies = safety properties. read not read not send

9. 8 Policy Specification Example /* Macros */ push() ::= op == “push”; ret() ::= op == “ret”; /* ** Security Automaton */ start ::= !(push() || ret()) -> start push() -> hasPushed ; hasPushed ::= !push() -> hasPushed ; 0 1 “ Push exactly once before returning ”

10. 9 Enforcement Overhead? l Insert check before each machine instruction. l Eliminate unnecessary checks by partial evaluation (using local knowledge about insertion point).

11. 10 Initial Prototype: SASI Handles: –gcc output for x86 –Java VM Object code satisfying policy rewriter program Security policy

12. 11 Evaluation of SASI prototypes l Reproduce MiSFIT [Small ‘96] functionality for x86 with SASI. –SASI clearer: 2 page automaton specification. –SASI sometimes more expensive: SASI doesn’t change code... just inserts instructions. l Delete Java security manager and run only SASI’d applets and SASI’d library. –SASI clearer: 5 page automaton specification. –SASI can be slightly cheaper: deletes calls and checks. –SASI more expressive: checks can be anywhere. –Java SM: No added code or c-time overhead.

13. 12 Lessons Learned from SASI l Checking machine instructions problematic: –Applications use abstractions (e.g., methods) –Must add code for some events (e.g., interrupts) –Must synthesize policy-level events  Specifying policies requires general computation and structured state l Can build on language-based guarantees –Also works for x86: Typed Assembly Language, ECC,...

14. 13 Second Prototype: PoET/PSLang JVML class files satisfying policy rewriter program Security policy Policy Enforcement Toolkit Policy Specification Language … handles JVML class files

15. 14 ADD STATE { boolean did_read = false; } ON EVENT methodCall FileInputStream.read { did_read = true; } ON EVENT methodCall Network.send CONDITION did_read { FAIL; } l Subset of Java. (TCB is thus small) l Event-driven programming model binds program actions (events) to security state updates. l Policy expressible using application abstractions. PSLang: Policy Specification Language

16. 15 PoET: Policy Enforcement Toolkit l Routines for accessing state and events. l Rewrites JVM class files and eliminates redundant checks. (17.5K loc = TCB) l Program must obey certain constraints so code inserted works properly: –JVM verifier already provides necessary guarantees! l Allows policy composition (conjunction): –Used in Prism Digital Library project for “loaning” digital objects. Manages security and preservation policies.

17. 16 Trustworthy Networked Information Systems: New Solutions Under investigation: l In-lined reference monitors l Secrecy via annotated-program rewriting l Asynchronous proactive secret sharing l Gossip protocols l Mobile code integrity: –NAP protocols (primary-backup revisited) –Cryptographic-based privilege management

18. 17 Secure and Fault-tolerant Replication server failure replication server compromise secret sharing mobile attack proactive secret sharing (PSS) WAN setting asynchronous PSS Servers Client

19. 18 Application of asynchronous PSS: Secure and Fault-tolerant Repository l Data integrity protected. yclient provides access control rules l Data secrecy protected. yclient provides blinding function l Prototype deployment (in progress): –instances running on different platforms –instances running under different admin control y“trusted admins” assumed not to collude!

20. 19 And still more to come… l Gossip: Allows weaker assumptions about communications. (Provides weaker guarantees.) yControlling the U.S. power distribution grid. yNetwork-wide clock synchronization. l Mobile code integrity: yreplication management -plus- ydecentralized access control. l “Trust management” logics: View network- wide authorization policies as formulas. yWhat should certificates say/mean? yEnforcement as theorem proving (and proof as audit)!