SASI Enforcement of Security Policies : A Retrospective*

PSLab 오민경

Contents Introduction Security Automata Merging-in a Security Automaton Two Prototype SASI Implementations

X86 Prototype JVML Prototype

Abstract SASI

enforces security policies by modifying object code for a target system before that system is executed

Prototype Intel x86 Java JVML

(Security Automata SFI Implementation)

introduction Reference monitor

observe execution of a target system halts that system whenever it is about to

violate some security policy of concern

Typical security mechanisms directly implement reference monitors are intended to facilitate the

implementation of reference monitors

introduction Reference monitor must be protected from

subversion by the target systems it monitors. Memory protection hardware Placing the reference monitor and target systems in

separate address spaces Performance cost

Overhead due to context switches associated with transferring control to the reference monitor from within the target system.

Expressiveness cost Means by which target system events cause the

reference monitor to be invoked.

introduction To modify the target system code, effectively

merging the reference monitor in-line. This is the basis for software-fault isolation (SFI).

SFI : prevents reads, writes, or branches to memory locations outside of certain predefined memory regions.

Our Prototype merge security policy enforcement code into the

object code for a target system. Transforms x86 assembly language Transforms JVML (Java Virtual Machine Language)

With each, Security policies are specified using security automata.

Security Automata Security automaton

involves set of states input alphabet transition relation

define next state using current state and input symbol using fist-order predicates no transition -> reject

Security automata can be regarded as defining reference monitors. The input alphabet corresponds to the events that

the reference monitor would see. The transition relation encodes a security policy.

Security Automata

Merging-in a Security Automaton SASI generalizes SFI to any security policy that is

specified as a security automaton.

With SFI New code is added to the target system preceding

memory access instruction. New code ensure

all reads and writes to memory will access addresses within the target’s data region.

all branches, calls, and returns will transfer control to an instruction within the target program.

the functionality of these additions cannot e circumvented by the target system.

Merging-in a Security Automaton With SASI

New code is added to the target system preceding every instruction.

The added code simulates a security automaton. new variable

represent the current state of the security automata. new code

simulates an automata state transition causes the target system to halt whenever the

automaton rejects its input. Thus, the automaton simulation is equivalent to

inserting a reference monitor in-line into the target system.

Merging-in a Security Automaton Simplification of code (for simulating a security

automaton) Irrelevant tests and updates to the security automaton

state can be removed. By using partial evaluation on the transition

predicates. By using the automaton structure.

Merging of a security automaton specification Insert security automata Evaluate transitions Simplify automata Compile automata

Merging-in a Security Automaton

Merging-in a Security Automaton

Two Prototype SASI Implementations

Security policies for our SASI prototypes are represented in SAL.

SAL (Security Automaton Language) SAL specification consist of a list of states, with each

state having a list of transitions to other states. Macros are defined at the start of the SAL specification

and are expanded fully bottom-up before use. SAL supports only deterministic automata. SAL transition predicates are expression

constructed from constants, variables, C-style arithmetic and logical operators, and calls to platform-independent functions and to platform-specific functions

Two Prototype SASI Implementations

Two Prototype SASI Implementations

The integrity of a reference monitor depends on preventing the corruption Preventing the target system from modifying

variables Preventing the target system from circumventing the

code that implements transitions. Preventing the target system from modifying its own

code or causing other code to be executed.

The discharge of these obligations is platform dependent, but there are two general approaches Verification of the object code to establish that the

unwelcome behavior is impossible Modification of the object code to rule out the

unwelcome behavior

Two Prototype SASI Implementations

x86 Prototype

x86 Prototype

MiSFIT performs considerably better. But, x86 SASI have the flexibility.

JVML Prototype