Containment and Integrity for Mobile Code
Fred SchneiderAndrew Myers
Computer Science DepartmentCornell University
3 August 1999 Containment 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 1999 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?
basesystem
extension
3 August 1999 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
3 August 1999 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?
kernel
application
extension
?
3 August 1999 Containment and Integrity for Mobile Code—Andrew Myers
6
Enforcement Mechanisms
Extension
EMBase system
Reference monitor
EMExtension
Base system
Wrapper
Extension
Base system
EM
Program instrumentation
Extension
Base system
EM
Program Analysis Reference monitor: OS trapsWrapper: interpreter (e.g. Java)Program instrumentation: SFI, SASIProgram analysis:
Java, PCC, TAL, JFlow
Annotations
3 August 1999 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
3 August 1999 Containment 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 1999 Containment and Integrity for Mobile Code—Andrew Myers
9
Pervasive intermediation
Reference monitor: won’t capture all eventsWrapper/interpreter: performance overheadInstrumentation: merge automaton sim into program
– different security policies different merged-in code– simulation does not affect program– pay only for what you use
Extension
EMBase system
Reference monitor
EMExtension
Base system
Interpreter
Extension
Base system
EM
Program instrumentation
3 August 1999 Containment and Integrity for Mobile Code—Andrew Myers
10
…ldc 1 // new automaton state onto stackputstatic SASI/stateClass/state // cause automaton state changeinvokevirtual java/io/FileInputStream/read()I // read integer from file…getstatic SASI/stateClass/state // automaton state onto stackifeq SUCCEED // if stacktop=0 goto succeed invokestatic SASI/stateClasss/FAIL()V // else security violationSUCCEED: invokevirtual java/net/SocketOutputStream/write(I)V // send message...
read
not read not send
0 1
Example: JVM code in SASI
3 August 1999 Containment 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 1999 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
3 August 1999 Containment 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 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?
Extension
Base system
EM
Annotations
3 August 1999 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!
3 August 1999 Containment and Integrity for Mobile Code—Andrew Myers
15
Example: designing an airplane
Boeing Air Force
marketing plans, aircraft designsother customers’ info
military secrets,other suppliers’ info
Hosts
Data
ProgramsWar simulationsCost projections
CADaircraft simulations
3 August 1999 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
3 August 1999 Containment 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 member user
role1 role2 owner
machine
3 August 1999 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
)(trusts. , App, k p
3 August 1999 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 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 1999 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
3 August 1999 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
3 August 1999 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
Host 1 Host 2
Initiating host
rear guard primary
3 August 1999 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: rear
guard near primary, reuseprevious primaries as rear guards
– good reliability: rear guard farfrom primary, don’t reuseprevious primaries asrear guards,to avoid cycles
Host 1 Host 2
Initiating host
rear guard primary
Host 3 Host 4rear guard’ primary’
3 August 1999 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
3 August 1999 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!
3 August 1999 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