tiara upper software levels object system meta object protocol non-bypassable wrappers value...
TRANSCRIPT
Tiara Upper Software Levels
Object System
Meta Object Protocol
Non-Bypassable Wrappers
Value dependency tracking
Execution Monitoring
Access Control
Software Layers
Hardware:Security Tags Processing
Object Abstraction:Structured Memory,
Method Dispatch
Operating System:Hardware Management,Hardware Level Policy
Meta-Object Level:Wrapper Management
Access Control:Policy Enforcement S
ystem S
oftware
Plan Level:Self Monitoring and Recovery
Data Accountability:Provenance Tracking
Application Substrate:Application Data Management
Application
Middlew
are
We are here
Motivation
• Hardware and system software provide fine-grained protection– Instruction by instruction– Word by word
• The macroscopic level of method invocation is a necessary and complementary level– Access control– Data provenance tracking– Execution monitoring: assertions, data & control flow
• Hardware provides guarantees of the inviolability of the upper level software– Making key locations and procedures inaccessible to
user level code
Goals
• Flexible access control within a dynamic environment– Expressive, compact and simple language for rules– Prevent unintended information and control flows
• Maintenance of data provenance– Keep track of how application data was computed and
of the dependencies between data items– Trace back, propagation of trust levels
• Guarantee that execution corresponds to intended behavior and to diagnoses discrepancies– Architectural system model: abstract model of intended
flows– Execution monitor compares to actual execution and
diagnoses differences
Approach
• Use Common-Lisp object system as experimental vehicle– Preserve most of its features– Extend and embed richer system using meta-object
protocol
• Add security meta-data as part of the protocol– Principals– Compartments
• Embed a non-bypassable Accountable Information Flow (AIF) facility– Method level access control– Value flow tracing between and through methods– Execution monitoring of flows and assertions between
methods
Tiara Software Level
Object System
Meta Object Protocol
Non-Bypassable Wrappers
Class Lattice
• Classes form a lattice– Each class has multiple immediate superclass– Superclass is the transitive closure of immediate-
superclass relation
• Inheritance– Each class inherits from all of its superclasses
Multi-method Dispatch• All procedures are implemented by methods on object
classes• Multi-method dispatch enables selection of the
effective method based on the types of all of the arguments– Applicable methods are the set of most specific method whose
formal parameters are super-types of the types of the actual parameters
• Applicable methods are combined to form the effective method– Wrappers, before, after, primary method
• Multi-method dispatch subsumes all object-oriented models
Wrapper Methods• There are different categories of methods
– Primary– Before & after– Wrapper
• The effective method is combination of all applicable methods– All wrappers are called first– Control if and with what arguments primary is called– Then all before methods– Then the most specific primary– Then all after methods – Wrappers get control after internal methods return
• New method combinations and method roles can be defined using the Meta Object Protocol
Examples(defmethod t1 ((i integer)) (format t "~% Integer ~d" i))(defmethod t1 ((i number)) (format t "~% number ~d" i))
(defmethod t1 :around ((i integer)) (format t "~%Integer around") (call-next-method))(defmethod t1 :around ((i number)) (format t "~%Number around") (call-next-method))
(t1 1.0) -> Number around Number 1.0
(t1 1) -> Integer around Number around Integer 1
Meta Object Protocol (MOP)• Everything is an instance of some class• Classes, functions, and methods are instances
of meta-classes– Meta-class are part of class lattice
• Methods on meta-classes control how the basic operations of the object system work– Add method, delete method, method dispatch,
method combination
Object-1
Class-1
Standard Class
Function-1
Standard Generic Function
Method-1
Standard Method
Building an AIF System• We create new meta-classes, method dispatches,
and method combinations• AIF method dispatch:
– Dispatches on data-types of arguments as usual– Also dispatches on compartments of arguments– Also dispatches on additional Principal argument
• Principal encodes the role & privileges of the user-agent on whose behalf the thread runs
• AIF method combination and wrapper methods – Access control: prevent primary methods from running
by signaling a violation.– Signaling events to execution monitor– Special method compilation for data provenance
tracking
Tiara AIF Software Level
Access Control
Execution Monitoring
Value Provenance Tracking
AIF* Method Combination
• Multiple layers of wrappers– Access control– Execution monitoring– Information flow tracing– Application wrappers
ApplicationCode
Application Tracking
Integrity Checks
Event Stream
* AIF = Accountable Information Flow
Access Control
Execution MonitoringValue Flow Tracking
Tiara Software Level
Access Control
Execution Monitoring
Value Provenance Tracking
Access Control• Security policies are expressed using multi-method
wrappers– Principal: Who is acting and in what role– Operation: What is being done– Operands: To what objects
• Policies are expressed compactly using the class lattice– Reduces the number of policies required– Current implementation only dispatches on classes (not
compartments)
• Each wrapper corresponds to an entry in the access control matrix– If there are no relevant positive wrappers then a violation is signaled– Each relevant wrapper can also perform computations and
conditionally signal a violation.
Rules for :Permitter Methods
• Methods occur in most specific first order• Body of method can conduct an arbitrary computation and
then returns a value• Body should return :violation or NIL or T
– :violation means the operation isn’t permitted– NIL means the method doesn’t offer an opinion– T means the operation is definitely permitted
• If nobody permits an operation it’s a violation• Methods are selected based on types and compartments of
all arguments– Class inheritance is involved for all arguments– Class structure of principals is involved on the principal argument– Unqualified argument matches all types and compartments
• Implication: there need not be a “root” principal with unlimited rights to do anything
Example
The principal *me* can frob anything
But, nobody else can frob anything unless specifically permitted:
(defmethod frob :permitter ((principal (eql *me*)) a b) t)(defmethod frob :permitter ((principal t) a b) :violation)
Any principal can frob integers:(defmethod frob :permitter ((principal t) (a integer) (b integer)) t)
Example Trace
*principal* = *ME*
(frob 'a 'b ) ->Around Before Frobing A B Before Frobbing A B Frobbing A B After Frobbing A BAround After Frobing A B(A B)
(frob 1 2) ->Around Before Frobing 1 2 Before Frobbing 1 2 Frobbing 1 2 After Frobbing 1 2Around After Frobing 1 2(1 2)
*principal* = *YOU*
(frob 1 2) ->Around Before Frobing 1 2 Before Frobbing 1 2 Frobbing 1 2 After Frobbing 1 2Around After Frobing 1 2(1 2)
(frob 'a 'b) -> Error:ACCESS VIOLATIONPRINCIPAL *YOU* ATTEMPTED TO FROBA andB
Code and Principal Structure
(def-aif-method bob :permitter ((principal (eql *admin*)) (x t) (y t)) :violation)(def-aif-method bob :permitter ((principal good-principals)
(x number) (y number))
t)(def-aif-method bob :permitter ((principal bad-principals)
(x integer) (y integer))
:violation)
Principal
Inner-admin
*admin*
Application Principal
Bad Principal
Good Principal
Baddie Goodie-1 Goodie-2
Execution Traces=>(set-principal *admin*)=>(bob 3 4)Error: Access violation: Generic Function BOB Args: #<Principal Admin>, 3, 4
=> (set-principal Goodie-2)=>(bob 12 11)Noticing Bob before 12 11… In primary …#<Boxed-value 35> =>(set-principal* *BADDIE*)=>(bob 21 23)Error: Access violation: Generic Function BOB Args: #<Principal Baddie>, 21, 23
Principal
Inner-admin
*admin*
Application Principal
Bad Principal
Good Principal
Baddie Goodie-1 Goodie-2
Use of Class Structure
Principal
Admin Domain
GeneralAdmin
DomainAdmin
User
DomainUser
Anybody in the domain can perform this operation (but not general admins)
Domain users can do this operation but domain-specific admins can’t
Any admin can perform this operation
Use of multiple permitting and denying methods for a single operation can form more complex policies
Access Control on Code Changes
• We’re in a dynamic environment where code can be changed at runtime.
• How do we prevent an attacker from changing our application methods?
• Add-method & remove-method are MOP generic functions
• We impose :permitter methods that only allow specified principals to use these generic functions to add or remove methods from our application’s generic functions.
• This can be done for specific generic-functions or for whole classes of generic-functions
• This secures our application level code and access control methods
Example of Change Protection
(def-aif-method method-change :permitter ((principal aif-internal-admin-principal) (generic-function aif-internal-generic-function) (method standard-method) change-type) t)
(def-aif-method method-change :permitter ((principal t) (generic-function aif-standard-generic-function) (method standard-method) change-type) :violation)
(def-aif-generic carol (a b) :generic-function-class aif-internal-generic-function :permitter (good-principals t))
Example of Change protection
(set-principal *goodie-1*)
(def-aif-method carol :raw (a b) (+ a b))
Error: #<Principal Goodie-1> is attempting to add a method to generic function CAROL with qualifier :RAW and specializers #<BUILT-IN-CLASS T>, #<BUILT-IN-CLASS T>, #<BUILT-IN-CLASS T> [condition type: ILLEGAL-CHANGE-METHOD]
Non Bypassable Access Control• We’re in a dynamic language where methods can
be added and removed at run-time
• We just showed mechanisms that keep an attacker from changing the methods that implement our application
• We also need to prevent an attacker from removing, adding, or changing the :permitter methods that implement our access controls on using and changing methods
• Note than any such change would require the use of Add-method or Remove-method to remove change methods implementing the application’s generic-functions
Closing the Loop• What prevents somebody from removing
the :permitter wrappers on add-method or remove-method?– Thereby un-securing our application level controls
• We impose wrappers that prevent adding or removing methods to the Add-method and Remove-method generic functions.– This means our application level controls can’t be
removed
• What prevents an attacker from removing or changing these “meta-wrappers”?
FrobGF
AIFGF
Method-1
AIFMethod
StandardGF
Add Method
Gf
Add-method:Class: AIF-GF
Class: AIF-Method
StandardMethod
Add-method: Equals Add-Method GFClass: Standard-Method
This wrapper controls who can change these methods
This wrapper controls who can change these methods
Wrapper Controls Who can Frob
This wrapper controls who can change these methods
Status and Next Steps
• Accomplished– Created type lattice for compartments and
principals– Created new AIF method combination
with :permitter methods– Modified the MOP to provide hidden argument for
principal– Demonstrated this on existing application code
• Next steps– Extend method dispatch to consider both class
and compartment for each argument
• Apply this design of system software as well
Tiara Software Level
Access Control
Execution Monitoring
Value Provenance Tracking
Event Noticing Wrappers Make The Application System Accountable to an
Architectural Model• Application methods are executed as raw code
– How do we know what’s going on and whether it’s what we wanted to go on?
• Wrappers inserted in good places– Architectural model tells us what those are
• Wrappers intercept events– Entry and exit from methods
• Events are sent to an execution monitor• Monitor “squirrels away” backup information
RealOutput
SimulatedOutput
Real Environment (Implementation)
Simulated Environment (Model)
in
in'
out
out'
List ofConflicts
Translator
in out
SimulatedComponent
RealComponent
Reflection
Differencer
Architectural Differencing
Execution Monitoring
• The code is annotated by wrappers• These are synthesized by a wrapper generator• We run code in parallel with a model• Wrappers send event stream to architectural
differencing• Deviations between model predictions and
observations from the wrappers are “symptoms” of misbehavior
• Diagnosis infers possible compromises of the underlying resources and updates a trust model
• Recovery is effected by restoring corrupted data resources and picking new method in light of the updated trust model
The Execution Monitor Generator
System Model
Wrappers
Execution Monitor
Event Stream
Code
Conditions &JustificationsBackup Data
Alerts
Synthesize
Get event info
Get Next Cmd
Get Leg
Get Events
cmd
Get MovementGet Sortie
event
Add Event
Mission Plan
Add Additional Info
MissionPlan
Mission Plan
MissionPlan
Take Off?
Y N
Mission Plan
Mission Plan
Get Events
More Events?
Y N
Each component can be annotated with:
• Entry Events• Exit Events• Allowable Events
Control Flow
Data Flow
Generating Execution Monitor• For every event in the model
– Generate wrapping method(def-aif-method xxx :noticer (args) (notice-event xxx entry args) (call-next-method) (notice-event xxx exit returns))
• For every data flow generate a trigger to move the data (similar for control flow)
• For every component generate a forward chaining rule that triggers when all inputs are present and checks the prerequisite conditions
• For every component generate a forward chaining rule that triggers on completion and asserts the post-conditions.
The Execution Monitor• Hierarchical Task Network
– Data Flow, Control Flow, Splits and Joins– Pre, Post conditions– Entry, Exit, Allowable Events
• TIARA Generates– Plumbing to pick up the events and create event stream– State Machine corresponding to task network, receives
event stream, checks for validity
• Module States:– Inactive (data not available, preconditions not satisfied)– Ready (data available)– Running (initiating event seen)– Completed (terminating event seen)
• An unclaimed event initiates diagnosis
Get event info
Get Next Cmd
Get Leg
Get Events
cmd
Get MovementGet Sortie
event
Add Event
Mission Plan
Add Additional Info
MissionPlan
Mission Plan
MissionPlan
Take Off?
Y N
Mission Plan
Mission Plan
Get Events
More Events?
Y N
Each component can be annotated with:
• Entry Events• Exit Events• Allowable Events
Control Flow
Data Flow
Behavior Models• Each mode (good, bad, …) of each
component has a behavior model– Preconditions, Post-conditions
• Generally about data-structure integrity• At a very abstract level data-structures are
about: sets, sequences, mappings• Introduced simple data modeling language:
– Add-to-set, Add-to-mapping, Insert-in-sequence– Delete-from-set, Delete-from-mapping, Delete-
from-Sequence– Default implementation for each
• Predicate to force consistency check
Dependency Maintenance• Execution Monitor actively checks the prerequisite,
post-conditions and other constraints in the plan.• The Execution Montior builds a dependency graph
between checked and inferred conditions:– Post-conditions and events within a step are justified with a
link to the assumption that the step executed normally and to the prerequisites conditions.
– Preconditions are justified by the causal link in the plan that connects it to a set of post-conditions of prior steps
• If a condition is directly observed, that condition is justified as a premise
• If an check fails, diagnosis is initiated.
Step1
Normal
Mode
Post-Condition1
PreconditionsStep1
Post-Condition2
PreconditionsStep2
Step1
Abnormal
Mode1
PreconditionsStep3
Checked, Pinned at P = 1
Host1
Normal
Mode
Host1
HighJacked
P = .9
P = .8
“Logical or”probability table
“Logical and”probability table
“Logical and”probability table
Checked, Pinned at P = 1
Step1
Bayesian Dependency Diagram
Bad Image
File Attack
P = .7
Bogus Condition
What the Bayesian Network Tells You• After adding all conflict nodes to the Bayesian network:• The posterior probabilities of the underlying resource modes tell
you how likely each compromised (or healthy) mode is.– This is an aggregate estimate
– These probabilities are part of the trust-model and guide resource selection in recovery and future computations.
• The posterior probability of each post-condition assertion– This is an aggregate estimate
– This gives us an estimate of what conditions are actually true. This also guides recovery.
• The posterior probability of each possible attack– This implies possible compromises of other similar resources that
have not yet been observed and that will also guide recovery.
Summary of Diagnosis
• The result of Diagnosis is the construction of a Bayesian network coupling attacks, resource vulnerabilities, compromised states of the resources and finally the observed behavior of a computation.
• This network assigns posterior probabilities to:– Assertions modeling the state of the computation
– These assertions are the prerequisite and post-conditions of the various computational steps in the plan diagram
– Compromised modes of the resources used by the computation
• The recovery task is to find a new plan and a new set of resources that is most likely to achieve the main goal of the plan, given this updated probabilistic information about the world.
The Trust Model• The Trust Model Includes Probability for Each
Resource that it is in a compromised state.• Diagnosis Updates the Trust Model• Trust Model is Read in Upon System Startup• Trust Model Guides method selection
TrustModel
Application
ExecutableCode
AWDRAT
Monitors
AWDRAT
DiagnosticService
Application
ExecutableCode
AWDRAT
DecisionTheoreticChoice
AWDRAT
DecisionTheoreticChoice
TrustModel
Status and Next Steps
• Status:– Core framework implemented and integrated with
AIF framework.
• Next Steps– Improve the modeling language to cover more
patterns of communication and control– E.g. dispatch, functional arguments– Re-implement plumbing and execution monitor to
allow parallel threads to be monitored– Apply to a realistic but small application
Tiara Software Level
Access Control
Execution Monitoring
Value Provenance Tracking
Value Provenance Tracking
• “Provenance Wrappers” imposed around computations
• Values are boxed in “TMS Like Structures”– Value– Support– Certainty and other extensions
• Code rewritten to track flow through methods• Output boxed in TMS structure relating
outputs to inputs, computation performed, and people involved.
Basic Structures
Value Computation Inputs
3 +
2 xx
1 yy
A Premise
B Premise
3 was computed by: Adding 2 and 1 2 was the xx field of Object A 3 was the yy field of Object B
Opaque Methods
• Used when the internal details of a computation aren’t worth tracking
• Unpacks inputs, feed raw values to real method• Boxes up output and provides justification• Wrapper is generated
3 +
X foo
Baz
3
X
Y
Y Baz
Transparent Methods• Done by source to source transformation
– In effect, type inference on two meta-types “boxed” and “unboxed”
– Flow analysis propagates these labels– Code rewritten to ensure that computations that expect
boxed values are provided with boxed values
• Divide the computation tree into coherent regions:1. Regions dealing with special AIF methods that expect
and produce boxed data2. Primitives and other non-AIF procedures
• Unbox and repackage data around calls to type 2 regions
• Builds dependency chains within type 1 regions using the support fields in boxed-values
Example
BAR is a normal function
(DEFMETHOD TEST-AIF-METHOD ((X NUMBER) (Y NUMBER)) (LET ((#:G1000 (LIST Y X))
(Y (BOX-VALUE Y)) (X (BOX-VALUE X)))
(MAKE-BOXED-VALUE :VALUE (BAR (+ X Y)) :MNEMONIC 'TEST-AIF-METHOD
:SUPPORT (LIST* #:G1000))))
Save x & y for dependency tracking
Extract raw values so that they can be added and raw result is passed to BAR
Package and return result with dependency information
(DEF-AIF-METHOD TEST-AIF-METHOD :TRANSPARENT ((X NUMBER) (Y NUMBER))
(BAR (+ X Y)))
(DEFMETHOD TEST-AIF-METHOD ((X NUMBER) (Y NUMBER)) (FOO (LET ((#:G1001 (LIST Y X))
(Y (BOX-VALUE Y)) (X (BOX-VALUE X))) (MAKE-BOXED-VALUE :VALUE (+ X Y)
:MNEMONIC 'TEST-AIF-METHOD :SUPPORT (LIST* #:G1001))
)))
Example
(DEF-AIF-METHOD TEST-AIF-METHOD :TRANSPARENT ((X NUMBER) (Y NUMBER))
(FOO (+ X Y))) Foo is another AIF method
Save x & y for dependency tracking
Extract raw values so that they can be added
Package result with dependency information
Pass packaged information to FOO
Example
(add-as t1 t2)#<Boxed-value 3> (derivation *) The value 3 was computed in the procedure ADD-AS from: The value 1 was computed in the procedure A from: The value #<TEST1 0001> which was the input PREMISE The value 1 which was the input PREMISE The value 2 was computed in the procedure A from: The value #<TEST1 0002> which was the input PREMISE The value 2 which was the input PREMISE
(DEFMETHOD ADD-AS :TRANSPARENT ((THING1 TEST1) (THING2 TEST1)) (+ (A THING1) (+ 1 (A THING2))))
Object t1Class: test1Slot A: 1
Object t1Class: test1Slot A: 2
Boxed Value Dispatching
• The previous examples use type signatures involving the types of the actual values
• But the methods are actually passed instances of type “Boxed-value”
• Use the MOP to control the method for method dispatching.– We developed a new dispatching method that applies to
AIF data– Use this to dispatch as normal for unboxed values– For boxed values, dispatch on the type of the value slot– This is done only for AIF generic functions
Code
(defparameter *alice-global* (make-boxed-value 2))(defparameter *bob-global* (make-boxed-value 3))
(def-aif-method alice :opaque ((x number) (y number)) (setq *alice-global* (+ x y) *bob-global* (+ x y)) *alice-global*)
(def-aif-method alice :permitter (principal x y) t)
(def-aif-method bob :transparent ((x number) (y number)) (FORMAT t "~%In primary ~a ~a” x y) (+ (alice x y) x))
(def-aif-method bob :noticer ((x number) (y number)) (format t "~%Noticing Bob before ~a ~a" x y) (let ((stuff (multiple-value-list (call-next-method)))) (format t "~%Noticing Bob after ~{~a~^, ~}" stuff) (apply #'values stuff)))
Execution Traces=> *alice-global*#<Boxed-value 2>=> (derivation *) The value 2, which was an input provided by the user running as #<Principal Goodie-1>
=>*bob-global*#<Boxed-value 3>=> (derivation *) The value 3, which was an input provided by the user running as #<Principal Goodie-1>
=> (bob 5 6)Noticing Bob before 5 6In around number method 5 6In around method 5 6In primary #<Boxed-value 5> #<Boxed-value 6>Noticing Bob after #<Boxed-value 16>#<Boxed-value 16>
Execution Traces(Derivation *)
The value 16, which was computed by the principal Goodie-1 in the procedure BOB from: The value 11, which was computed by the principal Goodie-1 in the procedure ALICE from: The value 6, which was an input provided by the user running as Goodie-1 The value 5, which was an input provided by the user running as Goodie-1 The value 5, which was an input provided by the user running as Goodie-1
=>*alice-global*#<Boxed-value 11>=>(derivation *)The value 11, which was computed by the principal Goodie-1> in the procedure ALICE from: The value 6, which was an input provided by the user running as Goodie-1 The value 5, which was an input provided by the user running as Goodie-1
CCOAT Example
Trace from CCOAT
(image-threat-level #<DRAWN-IMAGE>)#<Boxed-value 5>
The value 5, which was computed by the principal Goodie-1 in the procedure IMAGE-THREAT-LEVEL from: The value #<DRAWN-IMAGE>, which was an input provided by the user running as Goodie-1 The value 5, which was computed by the principal Goodie-1 in the procedure ASSESS-THREAT from: The value #<DRAWN-IMAGE>, which was an input provided by the user running as Goodie-1 The value #<DRAWN-IMAGE, which was an input provided by the user running as Goodie-1 The value 103.947105, which was computed by the principal Goodie-1 in the procedure DISTANCE from: The value #<DRAWN-IMAGE, which was an input provided by the user running as Goodie-1 The value #<DRAWN-IMAGE, which was an input provided by the user running as Goodie-1
(define-ccoat-command (com-assesss-threat :name t :menu t) ((object-1 'drawn-image :prompt "Blue unit") (object-2 'drawn-image :prompt "Red unit")) (setf (image-threat-level object-1) (threat-level object-1 object-2)))
(def-aif-method threat-level :transparent ((p1 drawn-image) (p2 drawn-image)) (let ((distance (distance p1 p2))) (let ((threat-level (assess-threat p1 p2 distance))) threat-level)))
Status and Next Steps
• Status:– Full implementation except for dispatching on compartments
as well as data types– Applied to CCOAT application
• Small GUI for a DARPA seedling (~ 1000 lines of Lisp code)• Fairly typical code (not written for TIARA)• No rewriting of code needed (other than renaming defining
forms)
– Some more code analysis need for a few Lisp features
• Next steps:– Clean up the implementation– Extend to dispatch on compartments– Extend to include reliability & certainty estimates & Bayesian
propagation– Experiment with a larger prototype– Use to implement simulation of TIARA core functionality