Containment and Integrity for Mobile Code Security policies as types Andrew Myers Fred Schneider...

Containment and Integrity

for Mobile CodeSecurity policies as types

Andrew MyersFred Schneider

Department of Computer ScienceCornell University

13 Feb 01 Security policies as types — Andrew Myers2

Projects

• Security policies as types– support for low-level languages

– reacting to intrusion: untrusted hosts

• Composing fault-tolerance and security– Asynchronous, proactive secret sharing

– COCA online certification authority

• Inlined reference monitors


Protecting data against programs

• Goal: confidentiality, integrity of information

• How to enforce as system-wide property?– There are almost no trusted programs

• Information flow policies: end-to-end principle applied to security

“the system cannot allow information to flow from source A to destination B”


Security-typed languages

• Idea: encode security policies in type system– Programs not allowed to run unless type-correct

• Advantages:– Decidable enforcement– Low run-time overhead– Small TCB (?)– Compositional security

• Issues:– What security policies can be encoded as types?– Application to low-level code?– Distributed computation – who decides what to

run?


Non-interference• Information flow policies based on some

form of non-interference

• “High” inputs cannot affect “low” observables

• Can be enforced by security type systemH1 L1

L2H2

H3 L1

L2H4

L


Issues

• Low-level code– Want to verify security in executable code– Useful for mobile code– Security type systems too restrictive

• TCB: host– Untrusted hosts– Intrusion– Dynamic coalitions

• Downgrading– Non-interference is too restrictive– What can be enforced if it is violated?


Security types

• A simple security type system:– Security type = H or L where an ordinary

type

– intH : a secret integer

– intL: a public integer

– More expressive labeling schemes exist

• Examples of use:intL x = e; // OK if e has type intL

intH x = e; // OK if e has type intH or intL

intH b; intL x = 0;if (b) { x = 1; } // not OK


Implicit flow in high-level lang.intH b;intL x = 0;if (b) { x = 1; /* not OK */ }• Implicit flow: information carried

through control structure• Solution: introduce static

approximation to implicit flow (pc)– Type of expression always acquires pcintH b; intL x = 0L; if (b) { x = 1H; }

• pc updated by rules for type-checking control structures


Implicit flow in low-level lang.• High-level control structures (if, while,

switch, function calls, returns) indirect, direct jumps

• Less ability to reason about implicit flow

• Simple rule: pc at target of jump always more secret than at jump instruction– captures possible implicit flow– too restrictive– doesn’t handle indirect jumps


Loss of precision

intH b; /* pc = L */

intL x = 0L; /* pc = L */

if (b) { x = 1H; /* pc = H */}/* pc = L */

MOV x, 0 ; pc = L CMP b, 0 ; pc = L JZ skip ; pc = H MOV x, 1 ; pc = Hskip: ; pc = H

High-level: safe

Low-level: apparently unsafe


A security-typed calculus• First low-level typed language with support for

dynamic control transfers, static information flow control [ESOP’01]

• Continuations in A-normal form: close to assembly code

• Linear continuations preserve precision ofhigh-level source analysis

• First proof of language-basedenforcement of non-interference(for any higher-order imperative language)

e ::= let x = prim in e| let x = refl

v in e| letlin y = lv in e| set v1 := v2 in e| if v then e1 else e2

| goto v1 (v2, lv)| lgoto lv1 (v, lv2)| halt v


TCB: host

• Model so far: host/execution platform type-checks incoming code to enforce security properties

• On a system of many hosts? – no perimeter!

Response to intrusion?Dynamic trust relationships?


Secure program partitioning• Programs contain no explicit code locations or

communication• Automatically transformed (“split”)

to run securely on current hosts• Intrusion: re-split!• Change in trust relationships: re-split!• Implemented in Jif compiler [TR]

source

compiler

intermediate code

Host 1

splitter

Host 2 Host 3

code partition code partition code partition

authenticatedtrust declarations


Downgrading/Declassification• Information-flow security properties are too

strong—real systems need to leak information

• Example: password-checking procedure leaks information about passwords even on failure

• Non-interference is all-or-nothing• Robust vs. non-robust declassification:

– Robust: declassification releases only the intended information

– Non-robust: attackers can exploit declassification to release additional information

• A non-robust system: password checker if attacker can change passwords


Robust declassification• Assumption 1: attacker can observe

some aspects of system state • Assumption 2: attacker can cause

changes to some aspects of system state

• Observation: projection function : O

• System is robust with respect to attacker if attacker learns no more from attacked system than from simple observation

Non-interfering

=?

=?

Robust

A


Results

• Theorem: non-interfering systems are robust

• Theorem: all systems are robust against attackers whose power to modify (A) is appropriately bounded– Integrity property derived automatically

from confidentiality property

• First formal characterization of confidentiality+downgrading+active attacker; applicable to language-based enforcement


Policies

• Strong, information flow policies

• Simple access control policies

• Mutually distrusting but collaborating principals

• Dynamically changing trust relationships


Attacks

• Considered:– buggy or malicious downloaded code– storage channels, implicit flows– intrusion/integrity violation in multiple-host

system– exploitation of downgrading channels

• Not considered:– denial of service– traffic analysis– timing, termination channels


Conclusions

• Information flow policies enforce system-wide security

• Progress:– Provably correct type-based enforcement

for low-level code– Support for untrusted hosts, dynamically

changing trust relationships—secure program partitioning

– New theory of robust declassification

Containment and Integrity for Mobile Code Security policies as types Andrew Myers Fred Schneider...

Documents

Transcript of Containment and Integrity for Mobile Code Security policies as types Andrew Myers Fred Schneider...