Containment and Integrity for Mobile Code

1. Containment and Integrity for Mobile Code Fred Schneider Andrew Myers Computer Science Department Cornell University

2. Motivation • Information assurance issues for distributed systems with mobile code: • Extensibility vs. security • Management of trust • Fault tolerance • Mobile code encompasses most systems • techniques will be generally applicable Containment and Integrity for Mobile Code—Andrew Myers

3. Extensibility vs. Security • Need for secure, extensible software systems: • operating systems • extensible applications (e.g. web browsers) • mobile/downloaded code • Memory/type safety necessary; not sufficient • Questions: • What richer set of security policies do we want? • What set of policies is enforceable? • What are the right enforcement mechanisms? base system extension Containment and Integrity for Mobile Code—Andrew Myers

4. Application Security Policies • Conventional security: protecting operating system objects and abstractions • New security needs: downloaded/mobile extensions and application abstractions • mobile code: no network send after file read • E-commerce: no goods until payment • intellectual property rights management • Need extensible, reusable mechanism for enforcing security policies Containment and Integrity for Mobile Code—Andrew Myers

5. Enforcement location • Where to enforce? In application! • security policies are expressed in terms of application abstractions • enforcement without context switch overhead • avoids coupling application and kernel • Problem: application-specific or reusable? extension application ? kernel Containment and Integrity for Mobile Code—Andrew Myers

6. Reference monitor Wrapper Program instrumentation Extension EM Extension Extension EM Base system Base system EM Base system Enforcement Mechanisms Program Analysis Reference monitor: OS traps Wrapper: interpreter (e.g. Java)Program instrumentation: SFI, SASI Program analysis: Java, PCC, TAL, JFlow Annotations Extension EM Base system Containment and Integrity for Mobile Code—Andrew Myers

7. EM-enforceable policies • Most security mechanisms basically the same • Execution Monitoring (EM) • halting execution if some security policy is violated • without examination of or alterations to program • Examples: hardware memory protection, access control, capabilities, ... • Can abstract all these mechanisms as security automata; all security policies specified by security automata are EM enforceable Containment and Integrity for Mobile Code—Andrew Myers

8. not read not send read Security automata • Every EM enforceable security policy can be characterized by some security automaton. • System execution produces sequence of events … … automaton reads and accepts/rejects sequence • Need pervasive intermediation to allow application-specific policies independent of extension code Containment and Integrity for Mobile Code—Andrew Myers

9. Reference monitor Interpreter Program instrumentation Extension EM Extension Extension EM Base system Base system EM Base system Pervasive intermediation Reference monitor: won’t capture all events Wrapper/interpreter: performance overhead Instrumentation: merge automaton sim into program • different security policies  different merged-in code • simulation does not affect program • pay only for what you use Containment and Integrity for Mobile Code—Andrew Myers

10. … ldc 1 // new automaton state onto stack putstatic SASI/stateClass/state // cause automaton state change invokevirtual java/io/FileInputStream/read()I // read integer from file … getstatic SASI/stateClass/state // automaton state onto stack ifeq SUCCEED // if stacktop=0 goto succeed invokestatic SASI/stateClasss/FAIL()V // else security violation SUCCEED: invokevirtual java/net/SocketOutputStream/write(I)V // send message ... not read not send 0 1 read Example: JVM code in SASI Containment and Integrity for Mobile Code—Andrew Myers

11. PSLang: specifying policies • State diagrams (SASI) are inconvenient • Current work: develop Policy Specification Language (PSLang) • same expressive power, more convenient • event-driven programming model maps program actions (events) to automaton state updates • specification expressible in terms of application abstractions STATE { boolean did_read = false; } EVENT methodCall FileInputStream.read { did_read = true; } EVENT methodCall Network.send CONDITION did_read { FAIL; } Containment and Integrity for Mobile Code—Andrew Myers

12. POeT: enforcing policies • Policy Enforcement Toolkit supports instrumentation of extension code to enforce a PSLang policy specification • Program must obey certain constraints so that instrumentation works properly • First cut: JVM, because it already provides necessary guarantees • We will explore other language-level methods for assembly code (SFI, TAL, ECC) • Allows rapid experimentation with a variety of mobile-code security policies Containment and Integrity for Mobile Code—Andrew Myers

13. Annotations Extension EM Base system Static analysis of programs • EM enforceable policies require only local inspection of program,for instrumentation • Some policies require staticanalysis (e.g., information flow, availability): halting is not an option! • Run-time checks can strengthen compile-time checking: theorem proving type checking • Run-time checks (sometimes) can be converted into compile-time checks • What policies become feasible using both static analysis and instrumentation? Containment and Integrity for Mobile Code—Andrew Myers

14. Decentralized Trust Management • Conventional security problem: protecting against distrusted users/software • General problem: multi-party cooperative computation with varying levels of mutual distrust • All parties have security policies to be satisfied • Different parties have different opinions about the trustworthiness of various hosts, software • Parties may mutually extend other’s software • Mobile code can make this problem easier! Containment and Integrity for Mobile Code—Andrew Myers

15. Example: designing an airplane Boeing Air Force Hosts marketing plans, aircraft designs other customers’ info military secrets, other suppliers’ info Data CAD aircraft simulations War simulations Cost projections Programs Containment and Integrity for Mobile Code—Andrew Myers

16. Reusable cooperative software • How can we build software for some environment with mutual distrust without specializing it to one trust configuration? • Needed: transparency • Generic specification techniques for trust assumptions • Ways to map software onto available platforms such that all security requirements are satisfied • Mobile code provides extra mapping flexibility: data and code can move dynamically to satisfy policies Containment and Integrity for Mobile Code—Andrew Myers

17. Trust as decentralized hierarchy • Approach: use hierarchy of principals to represent components of system: • users, groups of users, organizations, roles • hosts, networks, programs • Hierarchy constructed from trust relationships • Group principal trusts group members to view group info • Users trust administrator not to corrupt software • The owner of a machine trusts hardware is uncompromised member member user machine group role1 role2 owner Containment and Integrity for Mobile Code—Andrew Myers

18. Partial information • Principal p represented as public key kp used to sign statements of form “p trusts p´ to perform action A correctly”— • Total trust is action A = “sign statements for me”; weaker trust relationships: “read all my information”, “release all my information” • Distributed system: only part of hierarchy is available • some trust statements may be unavailable • some statements may not be believed by current program • Security decisions must be (soundly) based on partial knowledge of trust hierarchy Containment and Integrity for Mobile Code—Andrew Myers

19. Decentralized information flow • Important for cooperative distributed computation: privacy/secrecy • Strong enforcement of privacy requires analysis of information flow • Decentralized label modelis based on principal hierarchy • allows static analysis of information flow • works w/ partial (compile-time) information • Implemented, in JFlow prog. language Containment and Integrity for Mobile Code—Andrew Myers

20. Opaque information flow • Can we allow secret information be manipulated by cooperating programs on distrusted hosts? • Can’t send as plaintext: host may steal it by not statically checking programs properly • Can encrypt information, but then program can’t compute using it (also: expensive) • Idea: • replace data w/ opaque identifier data • recipient transparently performs remote calls • If necessary, third parties automatically mediate Containment and Integrity for Mobile Code—Andrew Myers

21. Fault Tolerance • Distributed fault tolerance solved through replicated computation • Static set of hosts: techniques exist • Mobile code: hosts change dynamically • How to replicate? • Replicas must migrate in coordinated fashion • Must be robust in face of transient communication failures : gossip protocols • Our approach: detection/recovery for partition-tolerant mobile computation Containment and Integrity for Mobile Code—Andrew Myers

22. Rear guards • Mobile code is backed up not by replica, but by rear guard that detects its failure, performs general recovery action • retrying action (possibly diff. code or diff. host) • or notifying invoker of failure Initiating host Host 1 Host 2 rear guard primary Containment and Integrity for Mobile Code—Andrew Myers

23. Rear guard protocols • As computation moves through multiple hosts, suitable rear guard machines must be arranged at each step: need decentralized protocol for this • good performance: rearguard near primary, reuseprevious primaries as rear guards • good reliability: rear guard farfrom primary, don’t reuseprevious primaries asrear guards,to avoid cycles Initiating host Host 1 Host 2 rear guard primary Host 3 Host 4 rear guard’ primary’ Containment and Integrity for Mobile Code—Andrew Myers

24. Partition-tolerant computation • Mobile code naturally supports disconnected operation • But: protocols for high availability usually require communication! • Questions: • Can we provide some amount of transparency through system support for partition-tolerant applications • What levels of reliability, performance can be achieved Containment and Integrity for Mobile Code—Andrew Myers

25. Gossip protocols • One approach to partition-tolerant computation: gossip protocols • Weak message delivery guarantees are strength: partitions are less likely to disrupt protocol • How to make it scalable? • Need to automatically discover, exploit network connectivity to improve information dissemination • Need techniques for deleting redundant and useless gossip information: a kind of distributed garbage collection • Must consider interactions with security issues; fault tolerance protocols may leak information! Containment and Integrity for Mobile Code—Andrew Myers

26. Conclusion • Extensibility vs. security • security automata • program instrumentation • mixed run-time and static enforcement • Decentralized management of trust • signed trust relationships • reasoning with partial information • transparent redirection of data, computation • Fault tolerance • gossip protocols, error detection/recovery Containment and Integrity for Mobile Code—Andrew Myers