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

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

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

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

JVML Prototype