SecureBus: Towards Application- Transparent Trusted Computing with Mandatory Access Control Xinwen Zhang 1, Songqing Chen 2 Michael J. Covington 3, and Ravi Sandhu 2 1 Samsung Information Systems America, San Jose, CA, USA 2 George Mason University, Fairfax, VA USA 3 Intel 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 (WISA03) –Separation of conventional OS and applications from secure applications (e.g. DRM application) – Communication through the low-level kernel: not flexible BIND (Oakland05) –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) (USENIX02) –Loadable security modules for enhanced security –No strong isolation

Related Work (cont) Low-level virtualization: strong isolation but not flexible interaction –Terra (SOSP03) –VMWare –Virtual PC Paravirtualized systems: need taming of legacy OS –Xen (SOSP03) –sHype (ACSAC05) High-level virtualization: simple but weak isolation –User-Mode-Linux (UML) –Proper in PlanetLab (USENIX05) Language-based virtualization –TrustedVM (USENIX VM05) –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: –SKs integrity measured by TPM, signed by TPM with some PCRs –SBs integrity measured by SK, signed by SK. –SBs runtime protection with SK, TPM, and other necessary trusted hardware. Isolated runtime environment No write access from external

Architecture (cont) 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 Processes 0. SB 1 has measured the integrity values of D 0 and P 1 1.P 1 takes input D 0 and generates output D 1 2.SB 1 measures integrity of D 1, and generates a signature of all these hash values V 1 –V 1 ={H(H(D 0 ) || H(P 1 ) || H(D 1 ))} k -1 3.SB1 send D1 and V1 to SB2, 4.SB 2 verifies the signature, and sends D 1 to P 2 if success 5.P 2 takes D 1 and generates output D 2, which can be verified by P 1

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 (Sandhu93) –Create subject/object (u, s, create) L(s) L m (u),(u, s, create) L(s) L m (u), (s, o, create) L(o) L(s)(s, o, create) L(o) L(s) –No-read-up (simple property) (s, o, read) L(s) L(o)(s, o, read) L(s) L(o) –No-write-down (*-property) (s, o, write) L(s) L(o)(s, o, write) L(s) L(o) –High-watermark for subject label: Update of subject label (s, o, read) L(s) = (L(s) L(o)) (L(s) L m (u))(s, o, read) L(s) = (L(s) L(o)) (L(s) L m (u)) (s 1, s 2, write) L(s 2 ) = (L(s 1 ) L(s 2 )) (L(s 2 ) L m (u 2 ))(s 1, s 2, write) L(s 2 ) = (L(s 1 ) L(s 2 )) (L(s 2 ) L m (u 2 )) L m (u)Where L m (u) is the users 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 so

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!