TIARA

1
TIARA

• Trust-management, Intrusion-tolerance,
  Accountability and Reconstitution Architecture

Howie Shrobe, Andre de Hon, Tom Knight
2
Outline For Meeting

• Review and progress on core ideas (30 minutes)
• Upper level software (45 minutes)
• Wrapper methods, method dispatch, method
  combination
• Execution monitoring
• Access control
• Data tracing
• System software (45 minutes)
• Scheduler - Thread Manager
• Device Driver and I/O system
• Hardware design ideas (30 Minutes)
• Next steps, discussion, and wrapup (30 minutes)

3
Whats Wrong

• Hardware Architectures provide Raw Seething
  Bits
• Programming languages (C) provide direct access
  to Raw Seething Bits without manifest
• Identity
• Boundaries
• Invariant conditions
• Unifying computational model and constraints
• Anything important (e.g. the OS) must erect
  protection barriers to save itself from the
  screaming ninnies
• This breaks modularity in the infrastructure
• This interferes with introspection, adaptivity,
  etc.
• Ultimately doesnt provide right isolation

4
Origin of the Problem?

• Good engineering tradeoffs based on 1970s and
  1980s technology
• Gates and memory were expensive
• Challenge to build fast, capable systems
• Minimalist designs ruled the day - RISC
• Separate domains context switch
• Known to be expensive (10K-100K cycles)
• System and software engineers know
• Must avoid crossing domains
• Conclusion Efficiency concerns require minimum
  compartmentalization
• Single barrier between system and user code
• System code runs with unlimited privilege
• Single penetration gives away everything

5
TIARA Philosophy

• Memory and processor resources are abundant
• Use them to provide guarantees
• Core system integrity
• Access control
• Accountability of results
• Controlled sharing in an object oriented model
• Everything lives in a common address space
• Everything obeys overall memory conventions
• Provide hardware supported metadata management
• Everything carries rich metadata
• Precise tainting of all data
• Hardware enforcement of access control matrix
• Provide support at many levels
• Hardware, middleware, application frameworks

6
TIARA Approach

• Goal Dramatically increase integrity,
  confidentiality, accountability of both system
  and user code
• Without significantly sacrificing performance
• Method Add rich metadata to all runtime data
  structures
• Metadata defines how data structures can be used
• Spend modest hardware to process metadata in
  parallel with computation
• Enforce proper data usage, information flow,
  compartmentalization
• Structure system code resides in many small
  compartments one for each conceptual usage
• No single, all privileged component
• Enforce structuring conventions to prevent and
  contain effects of common security breaches
• Organizing Principle Least Privilege strong
  compartmentalization
• Provide foundation for analysis and verification

7
TIARAs Zero Kernal OS

• Operates on Structured, Object-Oriented Memory
• Kernel functionality is partitioned into unitary
  components
• Kernel components are isolated from one another
  and from user code using compartment meta-data
• Each kernel component has the minimum privileges
  necessary for its task
• Kernel components and user code are all in single
  uniform address space
• System services are invoked via normal procedure
  calls without expensive context switch
• Privilege carried in per thread process credential

8
TIARA

• Review of Core Ideas

9
TIARA Layers
We are here
10
Objects, Metadata, Tags
Step 1

• Everything is an object.
• Every object has manifest
• Type
• Bounds
• Identity
• Meta-data is in object-header
• Processor checks metadata while processing data

Unique ID
Bounds
Metadata
Type
Slot-1
Slot-2
Data
Slot-n
11
Objects, Metadata, Tags
12
Tags Data Path
Step 6

• The tags data path determine if the operation is
  allowed and if so what the resulting tag is. It
  examines
• The tags of the operands
• Data Type
• Compartment
• The principal
• The instruction
• This can be implemented in a Hash Execution
  (HashEx) unit whose contents are specified by the
  system software
• Different data in the HashEx represents different
  access control and information flow policies

Compartment-1
Compartment-2
Compartment-3
Compartment-4
Compartment-5
Compartment-n




R
RW
Principal-1
trap
trap
trap
trap
R
R
R
trap
trap
trap
Principal-2
RW
RW
trap
trap
trap
trap
Principal-3
RW
R
trap
trap
trap
trap
Principal-n
13
Tagged Data Path
14
The HASHEX Hardware
15
Compartments Principals

• Compartments
• Lattice of Collections of Data
• When combining data from 2 compartments results
  is in the LUB
• Policy restricts flows between compartments

• Principals
• Lattice of Roles a process may play
• A process may switch Principal
• Access rights granted to Principals on
  compartments
• These imply flows that a principal can effect

Both Principals and Compartments have
representations as objects in a compartment.
16
Tag Unit implements policy table on
cycle-by-cycle basis
Compartment
C1 C2 C3 C4
P1 R/W R -- W
P2 -- R/W W --
P3 W R R/W --
Principal
Can Principal P1 Load data in C1?
Can Principal P1 store data in C1 over data in C2?
Memory
Memory
C1
C2
17
Hardware provided support

• Every word is tagged with meta-data
• Every thread has an associated Principal
• Principals are objects like any other
• They have metadata that limit access to them
• Compartments are objects
• They have metadata that limit access to them
• Instructions also have meta-data
• All internal registers have meta-data
• Including the PC
• On every operation the combination of operand
  meta-data, PC meta-data, the Principal, the
  instruction and instruction meta-data are
  checked.
• Every object reference is bounds checked

18
Summary

• Memory is treated as structured pool of objects
• Base and Bounds
• All references are bounds checked
• No raw pointers
• Every word carries meta-data
• Data Type
• Instruction, Immediate data, Reference
• Compartment
• Metadata can be encoded in a tag
• Every thread has an associated Principal

Compartment
Base
Bounds
1010110001110001000011100101010
Data
Type

• Example 96 bit word
• 64 bits data
• Base and Bounds for references
• 8 bits data type
• 16 bits compartment
• 8 bits for other use

• Each Principal has limited (or no) rights to each
  compartment
• These rights are checked on every instruction

19
TIARA

• How these tools support our design philosophy
  Rules that lead to least privilege, integrity and
  robustness

20
The Challenge

• Our goal is to make the core system difficult to
  compromise and to limit the effect of any
  compromise that can happen
• Weve eliminated the traditional single,
  address-space boundary between OS and user code
• Instead, we provide hardware support for a set of
  structuring rules (supplied by the system
  software designer) that hopefully limit
  information flows to those actually desired
• Our goal is to show that we can design a
  reasonable OS that provides stronger protections
  than those provided by the conventional design
• Structuring rules help establish abstractions
  that support analysis and verification

21
Rules Data Structures

• There are no raw pointers, only object references
• Object references are created only by the memory
  allocator at the time an object is created
• Object references are immutable
• There are privileged retagging operations for
  special purposes
• As a consequence, a thread can access an object
  only if
• It created the object
• It has access to a second object which contains a
  reference to the first object
• It is passed a reference to the object in a
  cross-thread call
• All data accesses are bounds checked by the
  hardware

22
Rules Reading

• Hardware checks that the offset is within the
  objects bounds
• The Tags management unit (TMU) checks that the
  threads principal is allowed to read from the
  objects compartment)
• The Hash-Ex checks that the threads principal is
  allowed to load data from the compartment of the
  word in the specified slot of the object

1. Can Principal read from Compartment-O?
2. Can Principal load data in Compartment-S into a
   processor register?
3. Is Offset less than Bounds?

23
Rules Writing

• Hardware checks that the offset is within the
  objects bounds
• The HashEx checks that the threads principal is
  allowed to write data into objects compartment
• The Hash-Ex checks that the threads principal is
  allowed to overwrite the word in the specified
  slot of the object with data from the compartment
  of the write data (Compartment-W).

1. Can Principal read from Compartment-O?
2. Can Principal overwrite data in Compartment-S
   with data from Compartment-W?
3. Is Offset less than Bounds?

24
Data Structures Act Like A Lockbox

Principal-1
Object-1
Compartment-1
compartment

Slot-1
Slot-2
Compartment-2

• An objects compartment says which principals can
  look inside
• The data inside have other compartments
• You can safely pass arbitrary data between two
  threads by packing the data into an object whose
  compartment is only accessible to the principals
  of those threads

compartment
Slot-n
Object-2
Compartment-3
Compartment-n
compartment
3.14159
compartment
Object-n is a string, this is its text.
Object-3
Object-n
25
Information Flow

• Data can flow from compartment1 to compartmentn
  only if there is a sequence of principals P1, P2,
  , Pn-1 and compartments C2, C3, , Cn-1 such
  that each Pi can
• Read data from compartment Ci
• Write data to compartment Ci1
• For any specific datum Dk in C1 these conditions
  may not suffice, since the thread may not have
  any way to obtain a reference to Dk

Principal1
Principaln-1
Principal2
Compartment1
Compartment2
Compartmentn
Compartment3
26
Rules Allocation Reclamation

• Memory is allocated only as well-formed objects
• All sub-fields initialized with value, datatype,
  compartment
• Typically with null value and null datatype
• A thread can only allocate storage in
  compartments sanctioned by policy
• Memory is only freed via garbage collection
• No explicit free operation
• An objects memory is reclaimed when there are no
  remaining references to it
• There are no dangling pointers
• Meta data is immutable
• Except for a few highly specialized system
  services
• Consequence Theres no way to mint or find a
  logically invalid reference to an object

27
Rules Control Flow

• All instructions are contained in code-objects
• A reference to a code-object is called a
  procedure-reference
• This is normal reference with datatype,
  compartment, etc.
• All branches are relative to the base of the
  code-object and are bounds checked
• The only non-local transfer of control is via
  procedure call
• Traps, throws, condition signaling and
  condition-handling are all performed via
  procedure calls
• A call can only be performed on a
  procedure-reference
• And only if the threads principal has
  procedure-call rights to the compartment of the
  code block
• Returns are performed by calling a continuation
  passed as part of the call
• A continuation is a just another code-block
  representing the rest of the procedures
  computation

28
Procedure Data Structures
Size
All branches are to an offset from the base of
the current code-object and are bounds checked as
are all accesses of an object
Principal
Call
Size
HashEx
Trap?
The call is allowed only if the Principal has
procedure-call rights to compartment of
Code-Object-2
Code-object-1
Branch
Code-object-2
29
Closures

• A procedure call is actually performed on a
  Closure
• Traditionally Closure Code-object Environment
• We add a slot to closures for the Principal
• If the principal is non-null, the called
  procedure runs with the new principal.
• Closures are objects with metadata, including a
  compartment
• This is the only way to change principal
• A call is trapped if the current principal
  doesnt have rights to call something in the
  compartment of the closure

Principal Register
Principali
Principalj
Call allowed only if principali has call rights
to Compartmentk
Closure reference for call
HashEx
Compartmentk
Closurem
30
Procedure Calls and Threads

• Associated with every thread is a process queue
• This is a queue of closures
• There is a variant of the call instruction that
  makes a call between two separate threads
• The call is not made immediately
• The called closure is added to the process queue
  of the called thread
• The instruction has both blocking and
  non-blocking variants
• When the called thread completes the operation,
  it calls the return closure using a cross thread
  call to the calling thread (but doesnt block)
• Asks the scheduler to wakeup the original calling
  thread.
• To avoid unintended information leakage the stack
  is compartmentalized

31
Compartmented Stack Structure
Caller
Callee
Return Values
Local 1
Local 0
Frame Pointer
Locals Pointer
Local Pointer
Arg1
Arg1
Arg0
Arg0
Continuation
Continuation
Previous Frame
Previous Frame
32
System Software

• The system has a flat address space
• There is no traditional memory barrier between OS
  components and user components
• No additional overhead to OS calls
• Must show that OS cant be compromised
• Must show that OS doesnt create unintended
  information flows

File System
Dynamic Loader
I/O Systems
?
Memory Allocation
?
Virtual Memory Manager
?
Device Managers
?
Garbage Collector
Scheduler and Thread Management
Inter-thread Communication
?
?
Compartment and Principal Management
Boot Loader
Data Formats
Control Flow
HashEx Management
?
?
How much magic happens here is in the design?
33
TIARA

• Review of Known Exploits and Effectiveness of the
  TIARA Approach

34
Firefox Exploits

• In a separate project we reviewed the documented
  attacks against Firefox version 1.0
• Part of DARPA Application Communities project
• There are over 100 categories of exploits
• One Group, Code Injection, was examined for
  vulnerabilities within TIARA design
• 33 of original categories
• 6 sub-categories
• TIARA would be impervious to all
• Basic structuring conventions explain robustness

35
Firefox Exploits

• Arb-code (91) The exploiter can execute
  arbitrary code on the user's machine.
• Binary Code Injection (33)
• Application Specific (6)
• JS Privilege Escalation (41)
• Spoof (11)
• Destroy (2) The exploiter can destroy
  information (files) on the user's machine.
• DOS (1) The exploiter can crash the application
  (Denial-of-Service)
• Info (29) The exploiter can access some of the
  users information.
• Often information related to other websites
  (logins, passwords, etc), but sometimes files on
  the users machine.
• Not-security (4) The bug isn't related to
  security

36
Code Injection Exploits

• stack-overflow (2) A buffer on the stack is
  overflowed.
• Arbitrary code can be executed if the user can
  control the bytes that are written after the
  overflow.
• The most common method is to overwrite the return
  pointer with a pointer to exploit code.
• array-access (2) Binary code injection via out
  of bound array accesses (normally reads).
• Arbitrary code can be executed if the memory
  accessed can be controlled by the user and
  virtual calls are executed on it.
• heap-overflow (11) A buffer in the heap is
  overflowed.
• Arbitrary code can be executed if the user can
  control the bytes that are written after the
  overflow.
• dead-pointer (3) Pointers remain to memory that
  has been freed.
• Arbitrary code can be executed if the memory can
  be controlled by the user and virtual calls are
  made through the dead pointers.
• js-trampoline (2) The type of a javascript
  object passed to a system routine is not checked.
  
• This allows the caller to pass in a different
  type of object (such as a dobuble) that can
  contain user controlled data where to pointer to
  the virtual table would be in a correctly typed
  object.
• If a virtual call is ever made on the object in
  C, arbitrary code can be executed (by placing
  the code in the heap in allocated JS objects).
• js-gc (13) Java script garbage collection error.
  
• This error results when a javascript writer can
  obtain a reference to an object that has been
  garbage collected.
• Arbitrary data can be placed in the object (since
  it points to an active object of a different
  type).
• The object can be exploited by calling a virtual
  function through it.

37
Code Injection Protections in Tiara
Stack overflow Bounds execution permission checks
Array access Bounds execution permission checks
Heap overflow Bounds execution permission checks
Dead pointers Garbage collection and execution checks
JS trampolines Data type execution permission checks
JS GC Garbage collection type checks and execution permission checks
JS Privilege escalation Principal transition checks
38
Summary

• Operating system is structured as a set of
  independent, isolated, least privilege components
• Using many system specific compartments,
  principals, data-types and instructions
• Structuring rules provide strong limits on
  unintended control and information flows
• These are the building blocks in the design of
  new style of operating system
• Hardware enforces the rules
• Examination of Firefox exploits shows that TIARA
  design is far more robust
• Provides strong platform for high level
  abstraction infrastructure

39
Rest of Whats to come

• Overview of application substrate
• More macroscopic use of metadata for access
  control
• Information flow tracing
• Execution monitoring
• Core system software
• Scheduler and thread management
• I/O design and device drivers
• Hardware micro-architectual ideas