securebus: towards application-transparent trusted computing with mandatory access control
Post on 12-Jan-2016
24 Views
Preview:
DESCRIPTION
TRANSCRIPT
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!
top related