Transcript An Overview Presentation can be found here

TIARA
Trust-management, Intrusion-tolerance,
Accountability and Reconstitution Architecture
Howie Shrobe, Andre de Hon, Tom Knight
TIARA Layers
Application Data Management
Data Accountability:
Provenance Tracking
Plan Level:
Application
Middleware
Application Substrate:
Self Monitoring and Recovery
Access Control:
Policy Enforcement
Wrapper Management
Operating System:
Hardware Management,
Hardware Level Policy
Object Abstraction:
Structured Memory,
Method Dispatch
Hardware:
Security Tags Processing
System Software
Meta-Object Level:
Tiara Hardware Level
Building The Object Abstraction
Bounds
Identity
Type
Maintaining Data Provenance
Fundamental Problem

Based on monolithic security kernel & undifferentiated
memory


All privileged operations in a single security domain
Consequences:



Single domain breach gives attacker everything
Many Interfaces and services
Huge, complex code base


Millions of lines of code
Many opportunities for bugs




Typically 1 bug per 100 LoC
Complexity scales closer to N2 than linear
Impossible to completely vet
Any single attack
can ‘sink the
boat’
Large surface of vulnerability for attack
Emergency
Raft
Origin of the Problem?

Good engineering tradeoffs based on 1970’s
and 1980’s technology




Separate domains  context switch


Gates and memory were expensive
Challenge to build fast, capable systems
Minimalist designs ruled the day  RISC
Known to be expensive (10K100K cycles)
System and software engineers know:


Must avoid crossing domains
Conclusion: Efficiency means minimum
compartmentalization
Idea

Add metadata at the word level


Tag on every word in memory
Role
Code
 User data
 Pointer
 System data
Context
Data
1010110001110001000011100101010


Context
Owner
 Pedigree

Type
Example: 32 bit word



24 bits data
4 bits type
4 bits data context


Security compartment
Pedigree
[Shown small for illustration purpose only.
All fields longer in practice.]
Tagged Data Path
Register
File
Operand 1
Data
Operand 2
A
L
U
Result Data
Tag 1
Tag
Tag 2
Instruction
PC
Process Identifier
Result Tag
Trap Signal
Tags
Unit
Trap Dispatch Address
Metadata Uses

Isolation






Multi Level Security (MLS)
Integrity
Robust Error Handling







Elaborate shortly
Enforce OO model
Sandboxing
Pointer abuse
Code bashing
Bounds
Policy
Auditing
Synchronization
…more in white paper…
Operand 1
Data Operand 2
Tag
Tag 1
Tag 2
Instr
PC
PID
Result Tag
A
L Result
U Data
Trap S
Tags
Trap
Unit Addr
Efficient Hardware Support

Process tags in parallel with
datapath



No impact on cycle time
Leverage existing
speculation/in-order exception
and retirement hardware
Implement common-case fast
with small Hash Execution
(HEX) unit

Similar in size/complexity to
TLB
Cost

Dominant cost {area, bandwidth} for tags




All memories, register files, caches
HEX modest size
Memory already dominant area in processors
E.g.: 32b tag on
128b atomic word
Historical Predecessors

Burroughs B5000,6000 (1970s)



Symbolics LISP Machine (1980s)





3b tag
Security based on high-level compiled code
8b tag
Only use for robust error handling
Not explicitly for security
Intel i432 (~1980)
IBM System 38 (1980s)

1b tag
Compartment Tags

Tag every word with a compartment ID
Process Permissions

Policy table specifies rights for process on
each compartment
Support with HEX

HEX Unit implements
policy table on cycleby-cycle basis
Result

Can have


Private data to processes (objects)
Richly shared need-to-know data
 principle

While



of least privilege
Transfer between objects/services as procedure call
Few cycles, no expensive context switch
Change rules


Eliminate performance penalty for strong isolation
Eliminate performance/security tradeoff
Service Integrity

HEX can enforce policies to prevent service
subversion




Only execute words tagged as instructions
Limit PC range for service
Code is tagged write-only
Ordinary code not able to write instructions
 Write
instructions runable as service role
Enables: Compartmentalization

Double win:


Breach containment
 Avoid single point of failure
 Limit impact of any breach
Small code in compartment
 Strong abstraction  complexity management
 ~5K lines/compartment
 Plausibly verifiable
No single or even double
penetration can sink the boat
Secure
Raft
Generic Mechanism

Metadata w/ Programmable HEX unit


Flexible mechanism
Does not build policy into hardware
 Not

even the fielding/use of metadata bits
Large set of uses
 See

white paper
Enables

Selectable security levels
 Same

hardware, different policies
Experimentation
 New
ideas
 Different security strategies
Tiara OS Level
Least Privilege
Isolation
No Kernel
ZKOS Overview

Traditional Operating Systems:






Operate on “Raw Seething Bits”
A separate monolithic kernel all of whose components have
maximum privilege
Kernel separation achieved through address space mappings
User calls for system service are different than normal subroutine
calls
System services require context switch
Zero-Kernel Operating System (ZKOS)

Operates on Structured Object-Oriented Memory

Kernel functionality is not separate or monolithic
Each kernel component has limited privileges corresponding to its
task
Kernel components are in same address space as user code
Separation achieved via STA tagging
User calls for system services are normal procedure calls
System services do not require context switch





ZKOS Structured Memory

All memory is viewed as consisting of Objects



All objects are referenced only through ObjectReferences
Only the Memory Manager can create object
references (in concert with Domain Manager)






Extent, Type, Identity
Base, Bounds, Meta-Data
Object references are (nearly) immutable
Object references do not carry permissions
There are no raw pointers or pointer arithmetic
Reclamation is via Garbage Collection
No “Raw Seething Bits”
ZKOS Kernel-less Isolation

ZKOS employs a modular architecture together with
security tagged memory to manage interfaces between
OS components



Isolation provide by security tags, not separate address space
Each OS component operates in its own security contexts
Communication is via procedure call





Interface memory for each component is separate from internal
memory
ZKOS Components are not different in kind from other
components
All set-up and management of security-context is done
by the Domain Manger
The domain manager only changes security tags
based on authority from the authorization system
Privilege carried in process credentials
Interactions between ZKOS
Components

Procedure call is the only way that components
interact




Internal code and data is inaccessible to all other
components or processes
Each component uses the following security contexts
for memory:





Procedures implemented by methods
Object-oriented modularity enforced by STA
Internal component data
Internal component code
Interface memory
Each component is authorized to perform only its
designated tasks
Other components or processes are never authorized
to access or modify internal data or code within OS
components.
Examples: Least Privilege Operation

Scheduler




Privilege to loads process id register in hardware
No ability to change process credentials
No ability to examine or change application data
System Debugger


Privilege to examine stack of application process
Unable to see or modify private application data on
stack
Tiara Software Level
Object System
Meta Object Protocol
Non-Bypassable Wrappers
Software Layers
Application Data Management
Data Accountability:
Provenance Tracking
Plan Level:
Application
Middleware
Application Substrate:
Self Monitoring and Recovery
Access Control:
Policy Enforcement
Wrapper Management
Operating System:
Hardware Management,
Hardware Level Policy
Object Abstraction:
Structured Memory,
Method Dispatch
Hardware:
Security Tags Processing
System Software
Meta-Object Level:
Multi-method Dispatch




ZKOS is object oriented all the way down to the memory level
All procedures are potentially implemented by methods on object
classes
Multi-method dispatch enables selection of the effective method
based on the types of all of the arguments
Security method dispatch:



Dispatches on all data arguments as usual
But also dispatches on an additional process credential argument
Process authorization credential encodes the role & privileges of the
user-agent on whose behalf the process runs



Failure to match the process authorization credentials with a
method’s invocation security context



System daemon credentials
User credentials
Prevents the effective method from being executed
Invokes a security exception handler
Multi-method dispatch subsumes all object-oriented models
Wrapper Methods

There are different categories of methods



The Effective Method is combination of all
applicable methods



Primary
Wrapper
Wrappers are called first
Control whether primary method is called and with
what arguments
There can be different categories of wrapper
methods
Meta Object Protocol (MOP)



Everything is an instance of some class
Classes, Functions, and methods are
instances of meta-classes
Methods on meta-classes control how the
basic operations of the object system work



Can build embedded object models with different
properties
Enough rope to take over and hang the user
Meta-Object methods can prevent doing bad things
including undoing themselves
Tiara Software Level
Access Control
Execution Monitor
Access Control

Many security policies (like role-based access
control) are naturally expressed at an object level of
granularity using multi-method wrappers





Principal: Who is acting and in what role
Operation: What is being done
Operands: To what objects
Role: Exclude user-agents from adopting certain roles or
from adopting them simultaneously
Trust policies are defined on maximally general types




Reduces the number of policies required
Provides automatic extension as new subtypes are defined
Reduces the time complexity of checking type and context
Data types & data contexts grounded at hardware level
Execution Monitoring
Real Environment (Implementation)
in
Real
Component
out
List of
Conflicts
Reflection
Translator
in
in'
out
Simulated
Component
out'
Simulated Environment (Model)
Real
Output
Differencer
Simulated
Output
Execution Monitoring
Application Tracking
Wrapper
Method
Event Stream
Wrapper
Method
Method
Wrapper
Method Selection
Application Scripting
Data Model
Program
Duplicated Data Model
Wrappers
Integrity Checks
Execution Monitor
Mission Plan
Get Events
Get Next Cmd
cmd
Each component can
be annotated with:
• Entry Events
• Exit Events
• Allowable Events
More Events?
Y
Get event info
event
Take Off?
Y
Get Sortie
Control Flow
N
Get Movement
N
Get Leg
Add Event
Mission
Plan
Add Additional Info
Mission Plan
Data Flow
Mission
Plan
Get Events
Mission Plan
Mission Plan
Tiara Software Level
Provenance Tracking
Provenance Tracking
• “Provenance Wrappers” imposed around
computations
• Values are boxed in “TMS Like Structures”
– Value
– Support
– Certainty
• Code rewritten to track flow through methods
• Output boxed in TMS structure relating
outputs to inputs, computation performed,
and people involved.
Provenance Based Operations
• Assessing reliability, trustability, accuracy of
data
– Bayesian propagation
•
•
•
•
Revocation
Access Control
Trace Back and Drill Down
Diagnosis in the case of bad executions
AWDRAT
Adaptive Method
Recovery and
Selection
Regeneration
Trust Model:
Behavior
Compromises
Attacks
• Architectural monitoring
• Wrapper synthesis
• Diagnosis
• Recovery and regeneration
• Adaptive method selection
• Trust modeling
Failure Localization
Compromise
Descriptions
Diagnosis
Execution Discrepancies
Architecture level
JavaWrappers
Event Stream
Applicatio
n Software
SafeFamily Wrappers
System
DLL’s
Execution Monitor
Model Compiler
Wrapper
Monitor
Synthesizer Synthesizer
System Model
The Trust Model and Recovery
• 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
AWDRAT
AWDRAT
Decision
Theoretic
Choice
Decision
Theoretic
Choice
Trust
Model
Application
Executable
Code
AWDRAT
Monitors
Application
AWDRAT
Diagnostic
Service
Trust
Model
Executable
Code
Tiara Application Demo
• Virtual Briefing Book
• Built incrementally
• Provenance for every entry
–Drill down
• Access control and degrading of info