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. What’s 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 doesn’t provide right isolation

4. 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

5. 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

6. TIARA’s 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

7. TIARA Review of Core Ideas

8. Application Substrate: Application Data Management Data Accountability: Provenance Tracking Application Middleware Plan Level: Self Monitoring and Recovery Access Control: Policy Enforcement Meta-Object Level: Wrapper Management Operating System: Hardware Management, Hardware Level Policy System Software Object Abstraction: Structured Memory, Method Dispatch Hardware: Security Tags Processing TIARA Layers We are here

9. Step 2: Step 3: • Merge most important metadata with object-reference (or value of immediate data) as a “tag” • Avoid overhead of extra cache • Eliminate redundant representation of metadata • Process Tags and Data in Parallel • Location represents identity • Metadata is read into side cache at same time that object is read into cache • Metadata available when data is Register File Operand 1 A L U Data Data Cache Result Data Meta Data Cache Operand 2 Tag 1 Tags Unit Trap Signal Tag 2 Instruction Tag Trap Dispatch Address Memory PC Process Identifier Metadata not in tags Result Tag Data-1 Tag-1 Data-n Tag-n 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

10. Step 4: • Introduce richer metadata: • Every object lives in a “Compartment” • Any useful aggregation of data Bounds Metadata Type Compartment Slot-1 Data Cache Meta Data Cache Step 5: Data Register File Slot-2 • Introduce Metadata for Threads • The “Principal” represents who the thread is working on behalf of at the moment • Held in processor register • Principals have limited rights to access specific data in specific ways Operand 1 A L U Data Slot-n Result Data Operand 2 Tag 1 Tags Unit Trap Signal Tag 2 Instruction Tag Trap Dispatch Address Memory PC Process Identifier Result Tag Metadata not in tags Principal Data-1 Tag-1 Data-n Tag-n Objects, Metadata, Tags

11. Register File Memory Operand 1 Metadata not in tags A L U Data Data-1 Tag-1 Result Data Operand 2 Tag 1 Tags Unit Trap Signal Tag 2 Data-n Tag-n Instruction Tag Trap Dispatch Address PC Process Identifier Result Tag Principal 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 trap R R R trap trap Principal-2 RW trap trap trap RW trap Principal-3 trap trap RW trap trap R Principal-n

12. Register File Operand 1 A L U Data Result Data Operand 2 Tag 1 Tags Unit Trap Signal Tag 2 Tag Trap Dispatch Address Instruction PC Process Principal Result Tag Tagged Data Path

13. Principal Register Program Counter Address New PC Tag Register File PC Tag Hash Principal RAM OP1 Tag Trap Flag OP 2 Tag Trap Vector Index Instruction Tag Result Tag Op Code = Hit? OP 1 OP 2 Tag OP R1 R2 R3 ALU Current Instruction Result Register The HASHEX Hardware

14. + = 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.

15. Processor Principal = P1 C1 Tag Unit implements policy table on cycle-by-cycle basis Compartment Principal Can Principal P1 Load data in C1? Can Principal P1 store data in C1 over data in C2? Memory Memory C1 C2

16. 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

17. 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 Summary Compartment Base Bounds 1010110001110001000011100101010 Type Data • 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

18. TIARA How these tools support our design philosophy: Rules that lead to least privilege, integrity and robustness

19. The Challenge • Our goal is to make the core system difficult to compromise and to limit the effect of any compromise that can happen • We’ve 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

20. 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

21. Principal Compartment-O Bounds Compartment-S Object-2 Slot-n Offset Rules: Reading • Hardware checks that the offset is within the object’s bounds • The Tags management unit (TMU) checks that the thread’s principal is allowed to read from the object’s compartment) • The Hash-Ex checks that the thread’s principal is allowed to load data from the compartment of the word in the specified slot of the object Can Principal read from Compartment-O? Can Principal load data in Compartment-S into a processor register? Is Offset less than Bounds?

22. Compartment-W Principal Write Data Compartment-O Bounds Compartment-S Object-2 Slot-n Offset Rules: Writing • Hardware checks that the offset is within the object’s bounds • The HashEx checks that the thread’s principal is allowed to write data into object’s compartment • The Hash-Ex checks that the thread’s 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). Can Principal read from Compartment-O? Can Principal overwrite data in Compartment-S with data from Compartment-W? Is Offset less than Bounds?

23. Data Structures Act Like A Lockbox = Principal-1 Object-1 Compartment-1 compartment = Slot-1 Compartment-2 Slot-2 • An object’s 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 it’s text. Object-3 Object-n

24. 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 Ci+1 • 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 Principal2 Principaln-1 Compartment1 Compartment2 Compartment3 Compartmentn

25. 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 object’s 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: There’s no way to “mint” or find a logically invalid reference to an object

26. 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 thread’s 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 procedure’s computation

27. Procedure-reference Reference Meta-Data 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

28. Return Values Local 1 Arg1 Arg0 Continuation Environment Previous Frame Principal Environment Code Block 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 doesn’t 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

29. 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 doesn’t block) • Asks the scheduler to wakeup the original calling thread. • To avoid unintended information leakage the stack is compartmentalized

30. Callee R/W Callee W Caller R/W Caller R/W Caller R Return Values Caller W Callee R/W Local 1 Local 0 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

31. 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 can’t be compromised • Must show that OS doesn’t 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?

32. TIARA Review of Known Exploits and Effectiveness of the TIARA Approach

33. 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

34. 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

35. 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.

36. Code Injection Protections in Tiara

37. 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

38. Rest of What’s 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