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

3 August 1999Containment and Integrity for Mobile Code—Andrew Myers 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

3 August 1999Containment 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

3 August 1999Containment 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

3 August 1999Containment 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? kernel application extension ?

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

3 August 1999Containment 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

3 August 1999Containment and Integrity for Mobile Code—Andrew Myers 8 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 read not read not send

3 August 1999Containment and Integrity for Mobile Code—Andrew Myers 9 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 Extension EM Base system Reference monitor EM Extension Base system Interpreter Extension Base system EM Program instrumentation

3 August 1999Containment 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... read not readnot send 01 Example: JVM code in SASI

3 August 1999Containment and Integrity for Mobile Code—Andrew Myers 11 STATE { boolean did_read = false; } EVENT methodCall FileInputStream.read { did_read = true; } EVENT methodCall Network.send CONDITION did_read { FAIL; } 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 PSLang: specifying policies

3 August 1999Containment 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

3 August 1999Containment and Integrity for Mobile Code—Andrew Myers 13 Static analysis of programs EM enforceable policies require only local inspection of program, for instrumentation Some policies require static analysis (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? Extension Base system EM Annotations

3 August 1999Containment 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!

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

3 August 1999Containment 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

3 August 1999Containment and Integrity for Mobile Code—Andrew Myers 17 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 Trust as decentralized hierarchy group member user role1role2owner machine

3 August 1999Containment and Integrity for Mobile Code—Andrew Myers 18 Partial information Principal p represented as public key k p 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

3 August 1999Containment 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 model is based on principal hierarchy –allows static analysis of information flow –works w/ partial (compile-time) information Implemented, in JFlow prog. language

3 August 1999Containment 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

3 August 1999Containment 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

3 August 1999Containment 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 Host 1Host 2 Initiating host rear guardprimary

3 August 1999Containment 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: rear guard near primary, reuse previous primaries as rear guards –good reliability: rear guard far from primary, don’t reuse previous primaries as rear guards, to avoid cycles Host 1Host 2 Initiating host rear guardprimary Host 3Host 4 rear guard’primary’

3 August 1999Containment 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

3 August 1999Containment 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!

3 August 1999Containment 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