SecureBus: Towards Application- Transparent Trusted Computing with Mandatory Access Control Xinwen Zhang 1, Songqing Chen 2 Michael J. Covington 3, and.

SecureBus: Towards Application-Transparent Trusted Computingwith Mandatory Access Control

Xinwen Zhang1, Songqing Chen2

Michael J. Covington3, and Ravi Sandhu2

1Samsung Information Systems America, San Jose, CA, USA2George Mason University, Fairfax, VA USA

3Intel Corporation, Hillsboro, OR, USA

Effective June 1, 2007 I am leaving George Mason after 18 years to be Founding Director and Chief Scientist of the new Institute for

Cyber-Security Research at the University of Texas, San Antonio

What is Trusted Computing (TC)? TC = TChw + TCsw

TChw = TPM + (TXT or SEM)TCsw = whatever

TPM: Trusted Platform Module – Standard defined by Trusted Computing Group (TCG)– Combines cryptography with access control– Root keys never leave TPM– Root keys can only be used by approved software (as measured by hash

chains themselves rooted in TPM)– Remote attestation allows computer A to find out if computer B is running

approved software TXT: Trusted eXecution Technology (Intel)

SEM: Secure Execution Mode (AMD)– Isolates process memory much better than traditional x86 architecture– Trusted path for user I/O:

• to monitor• from keyboard/mouse

What can be beneficially done using TChw?

Trusted Applications (Processes)

Trusted to handle data in conformance with security policy

Trusted to interact with other applications (on same or other computers) in conformance with security policy

Trusted TC Applications (Processes)

Why bother about TC for Trusted Applications?

Benefits of TC for Trusted Applications

Superior assurance for– Memory isolation

– Trusted path for user I/O

– Remote attestation for interaction with trusted applications on other computers

Most prior TCsw work has focused on this case of TC for Trusted Applications– May be adequate for low-interaction applications

– Does not scale to high-interactions applications

Partially Trusted Applications

Control interactions by means of mandatory mediation to enforce information flow policies

This contains damage due to malicious behavior (but does not eliminate it)– Information can leak from Secret to Secret but not from

Secret to Unclassified

– Viruses can propagate from Low Integrity to Low Integrity but not from Low Integrity to High Integrity

Covert channel problem remains

Partially Trusted TC Applications

Why bother about TC for Partially Trusted Applications?

Benefits of TC for Trusted Applications

Superior assurance for– Memory isolation– Trusted path for user I/O– Remote attestation for interaction with trusted

applications on other computers Three additional tasks for TCsw

– Attestation for interaction with partially trusted applications on the same computer

– Integrity and authentication of interaction input and output

– Mandatory mediation of interactions to conform with information flow policies

Benefits of TC for Partially Trusted Applications

partially

Application Transparency

How do we inject TC into Partially Trusted Applications without modifying the OS or the Application while allowing interaction?

Prior work suffers from one or more of– Modifies the OS– Modifies the Applications– Prohibits interaction– Permits unmediated interaction

Prior Work

PERSEUS (WISA’03)– Separation of conventional OS and applications from secure applications (e.g. DRM

application)

– Communication through the low-level kernel: not flexible

BIND (Oakland’05)– Use TCG/TPM as root of trust

– Use secure kernel to allocate and enforce isolation of processes

• Only critical sections of a process run in isolated space.

• Process code needs to be modified by inserting functions to call BIND interfaces.

– No communication between isolated processes.

Linux Security Modules (LSM) (USENIX’02)– Loadable security modules for enhanced security

– No strong isolation

Related Work (con’t) Low-level virtualization: strong isolation but not flexible

interaction– Terra (SOSP’03)– VMWare– Virtual PC

Paravirtualized systems: need taming of legacy OS– Xen (SOSP’03)– sHype (ACSAC’05)

High-level virtualization: simple but weak isolation– User-Mode-Linux (UML)– Proper in PlanetLab (USENIX’05)

Language-based virtualization– TrustedVM (USENIX VM’05)– The trust of the VM itself is based on TPM.

Contributions of SecureBus

Strong isolation with flexible interactions between process

Process-level attestation Preserving binary code integrity Ensures data integrity and authenticity

verification of interactions Mandatory mediation for controlled

information flow between processes

Architecture SecureBus (SB):

– Transparent to OS and applications

– Provide application-level TC Hardware-based root of trust:

– TPM/TXT– Secure kernel (SK)

Trust Model: – SK’s integrity measured by TPM,

signed by TPM with some PCRs – SB’s integrity measured by SK,

signed by SK.– SB’s runtime protection with SK,

TPM, and other necessary trusted hardware.

• Isolated runtime environment• No write access from external

Architecture (con’t) Primitive functions of SB:

– Allocate and maintain isolated memory space before launching a process.

• By calling functions of SK and trusted hardware

– Measure code integrity before launching a process– Process-based attestation

• Intra- and inter-platform

– Access and information flow control between processes

Data Authenticity between Processes0. SB1 has measured the integrity values of D0 and P1

1. P1 takes input D0 and generates output D1

2. SB1 measures integrity of D1, and generates a signature of all these hash values V1

– VV11={H(H(D={H(H(D00) || H(P) || H(P11) || H(D) || H(D11))}))}kk-1-1

3. SB1 send D1 and V1 to SB2,

4. SB2 verifies the signature, and sends D1 to P2 if success

5. P2 takes D1 and generates output D2, which can be verified by P1

Mandatory Access Control between Processes

Requirements:– Fine-grained– Configurable policies– Policy neutral: role/domain/type/history-based policies– Minimum of PEP – put policy management outside

Features:– Separation of policy definition and application development

• enable parallel development

– Support composition of PDPs

Access Control Model Attribute-based access control model Subjects: processes Subject attributes: the user (pid) context

– domain/group, clearance, role– Application-specific– Can be from external attribute authorities

Objects: processes and pure objects (e.g., files) Object attributes:

– Type, directory, user context info of the processes– Application-specific: e.g., last accessing subject id

Attribute values can be updated as side-effects of accesses– e.g., Labels for history-based policies

User authentication: – To get valid user context info – Prerequisite for policy enforcement– Not included here

Chinese Wall Policies History-based access control policies Can be described with a lattice-based model (Sandhu’93)

– Create subject/object• (u, s, create) (u, s, create) L(s) L(s) L Lmm(u),(u),• (s, o, create) (s, o, create) L(o) L(o) L(s) L(s)

– No-read-up (simple property)• (s, o, read) (s, o, read) L(s) L(s) L(o) L(o)

– No-write-down (*-property)• (s, o, write) (s, o, write) L(s) L(s) L(o) L(o)

– High-watermark for subject label: Update of subject label• (s, o, read) (s, o, read) L(s)’ = (L(s) L(s)’ = (L(s) L(o)) L(o)) (L(s)’ (L(s)’ L Lmm(u))(u))• (s(s11, s, s22, write) , write) L(s L(s22)’ = (L(s)’ = (L(s11) ) L(s L(s22)) )) (L(s (L(s22)’ )’ L Lmm(u(u22))))• Where LLmm(u)(u) is the user’s maximum label of a process.

SB provides mechanisms for recording security labels and trusted updates

Prototype Implementation

Process isolation with virtualization– User-Mode-Linux (UML), user-space VMs

SB is implemented as a daemon in host OS IPC with Socket

– Communicate with Tun/Tap interface in host OS

VM1

Tun/tap

Reference Monitor

Tun/tap

VM2

token

send/recv

VMM

Host OS

Host OS user space

s o

Access Control Performance Read/Write accesses are implemented with send/recv

method of TCP socket. Security labels:

– Process security labels are set of groups names of the user– file/directory labels are defined with SB_LABEL file in the same

directory A security token is issued by SB for an access request. Performance can be improved with a token caching

mechanism.

Conclusions

We propose SecureBus architecture:– Process-level isolation and attestation– Trusted communication between processes– Comprehensive integrity protection:

• Code integrity

• Input/output authenticity

• Mandatory access control of interactions

– Can be built in a layer transparent to applications

Ongoing and Future Work XACML implementation of a general PDP for SB

– OASIS standard access control policy specification and enforcement– Support general subject and object attributes – Can support multiple-level PDPs in distributed systems

Support general MAC models– Lattice-based, Role-based, domain/type-based, history-based, and usage-

based policies

Trusted collaborative computing systems– Grids, Web Services, and P2P systems– Virtual domains/organizations/coalitions

Prototype implementation with TPM/TXT-enabled platform

Thanks!