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

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

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


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


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

?


6

Enforcement Mechanisms

Extension

EMBase system

Reference monitorEM

Extension

Base system

WrapperExtension

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


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


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


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 monitorEM

Extension

Base system

InterpreterExtension

Base system

EM

Program instrumentation


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


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


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


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


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!


15

Example: designing an airplane

Boeing Air Force

marketing plans, aircraft designsother customers’ info

military secrets,other suppliers’ info

Hosts

Data

Programs War simulationsCost projections

CADaircraft simulations


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


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


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


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


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


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


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


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’


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


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!


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

Documents

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