1 / 21

SecureBus: Towards Application-Transparent Trusted Computing with Mandatory Access Control

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

dinahh
Download Presentation

SecureBus: Towards Application-Transparent Trusted Computing with Mandatory Access Control

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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, USA 2George 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

  2. 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?

  3. Trusted Applications (Processes) Trusted TC 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 Why bother about TC for Trusted Applications?

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

  5. Partially Trusted Applications Partially Trusted TC 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 Why bother about TC for Partially Trusted Applications?

  6. Benefits of TC for Trusted Applications Benefits of TC for Partially 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 partially

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

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

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

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

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

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

  13. Data Authenticity between Processes 0. SB1 has measured the integrity values of D0 and P1 • P1 takes input D0 and generates output D1 • SB1 measures integrity of D1, and generates a signature of all these hash values V1 • V1={H(H(D0) || H(P1) || H(D1))}k-1 • SB1 send D1 and V1 to SB2, • SB2 verifies the signature, and sends D1 to P2 if success • P2 takes D1 and generates output D2, which can be verified by P1

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

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

  16. Chinese Wall Policies • History-based access control policies • Can be described with a lattice-based model (Sandhu’93) • Create subject/object • (u, s, create)  L(s)  Lm(u), • (s, o, create)  L(o)  L(s) • No-read-up (simple property) • (s, o, read)  L(s)  L(o) • No-write-down (*-property) • (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)’  Lm(u)) • (s1, s2, write)  L(s2)’ = (L(s1)  L(s2))  (L(s2)’  Lm(u2)) • Where Lm(u) is the user’s maximum label of a process. • SB provides mechanisms for recording security labels and trusted updates

  17. VM1 VM2 send/recv s o Host OS user space token Tun/tap VMM Tun/tap Host OS Reference Monitor 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

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

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

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

  21. Thanks!

More Related