Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Defense

682 views

Published on

  • Be the first to comment

  • Be the first to like this

Defense

  1. 1. Radium: Secure Policy Engine in Hypervisor Tawfiq Shah
  2. 2. Agenda › Defining the problem › Introduction › Background Technologies (SRTM, DRTM,FLASK) › Radium Architecture Overview › Radium Prototype Overview › Adversary Model › Access Control Policy (XSM) › Radium Security and Performance › Related Works › Conclusion › Future Works 2
  3. 3. Problem › How many of us here have sensitive and/or private data stored in their personal devices? › Laptops › iPads/Tablets › Cell phones › The Cloud › How many of you actually implicitly trust those devices??? › Fact: everyone!!! (passwords, bank accounts, pictures, etc., )  We need a way to help us assess the state of our computing devices (The computing components/environments) › Access control 3
  4. 4. Agenda › Defining the problem › Introduction › Background Technologies (SRTM, DRTM,FLASK) › Radium Architecture Overview › Radium Prototype Overview › Adversary Model › Access Control Policy (XSM) › Radium Security and Performance › Related Works › Conclusion › Future Works 4
  5. 5. Introduction › Given two software stacks, how can one differentiate between a certified stack and one with sophisticated malware?? › A computing platform is trustworthy if it behaves as expected. › Computing components: – Firmware (BIOS) – System Software (OS) – Application Software › Integrity Measurement ( An approach to verify the trustworthiness of a computing platform is to measure each individual component.) – Measurement represents the state/behavior of an entity – Integrity measurement acts as a basis for trust 5
  6. 6. › Trusted Computing Group (Consortium of companies, e.g. AMD, CISCO, IBM, Intel, etc.,) – TCG Design Solution › Trusted Platform Module (TPM) › Current TPM employed solutions – SRTM (static root of trust for measurement) – DRTM (dynamic root of trust for measurement) › Axiom – Measured components do not change after measurement › Radium ARTM (Asynchronous Root of Trust for Measurement) – Leverage ARTM to overcome TOCTOU attacks – Allow concurrent execution of untrusted/trusted virtual domains – Zero down time – Secure MAC policy in hypervisor (hypercall granularity) – Remote attestation capability 6 Introduction Cont…
  7. 7. Agenda › Defining the problem › Introduction › Background Technologies (SRTM, DRTM, FLASK) › Radium Architecture Overview › Radium Prototype Overview › Adversary Model › Access Control Policy (XSM) › Radium Security and Performance › Related Works › Conclusion › Future Works 7
  8. 8. Static Root of Trust for Measurement (SRTM) 8
  9. 9. Dynamic Root of Trust for Measurement (DRTM) 9
  10. 10. FLASK Architecture Overview 10  Mandatory access control security architecture that supports dynamic policies (User, Role, Targeted/Type and Sensitivity)  Flask makes a distinction on security policy decision and enforcement functions  Uses context labels between subjects and objects to grant access (The subject is the requesting element, while the object is the element being requested.)  A prominent extension of Flask is Security-Enhanced Linux (SELinux) System_U:System_R:Type_T:S0...S10
  11. 11. Agenda › Defining the problem › Introduction › Background Technologies (SRTM, DRTM,FLASK) › Radium Architecture Overview › Radium Prototype Overview › Adversary Model › Access Control Policy (XSM) › Radium Security and Performance › Related Works › Conclusion › Future Works 11
  12. 12. Radium Design Overview › Employs DRTM to boot trusted Hypervisor › Use of ARTM to overcome TOCTOU attacks › Provide efficient and detailed measurements › Allow more than one measured environment to co-exist and co-operate › Contain an Access Control Policy which regulates access between all trusted and untrusted environments 12
  13. 13. Radium: Architecture 13 Trusted Hardware Trusted Hypervisor
  14. 14. Agenda › Defining the problem › Introduction › Background Technologies (SRTM, DRTM,FLASK) › Radium Architecture Overview › Radium Prototype Overview › Adversary Model › Access Control Policy (XSM) › Radium Security and Performance › Related Works › Conclusion › Future Works 14
  15. 15. Radium: Prototype Overview 15
  16. 16. Agenda › Defining the problem › Introduction › Background Technologies (SRTM, DRTM,FLASK) › Radium Architecture Overview › Radium Prototype Overview › Adversary Model › Access Control Policy (XSM) › Radium Security and Performance › Related Works › Conclusion › Future Works 16
  17. 17. Adversary Model 17
  18. 18. Agenda › Defining the problem › Introduction › Background Technologies (SRTM, DRTM,FLASK) › Radium Architecture Overview › Radium Prototype Overview › Adversary Model › Access Control Policy (XSM) › Radium Security and Performance › Related Works › Conclusion › Future Works 18
  19. 19. › XSM is light weight compared to SELinux › XSM also uses the same semantic concepts and tools as SELinux › For simplicity we employ Type Enforcement › Changes or updates on the policy require a system boot (Privilege domain capability) › Decomposed domain – Principle of least privilege for each domain (hypercall grantuality) – Ability to allow certain domains to control resource allocations › Theoretically create multiple domain builders › Existing XSM modules – Dummy (XSM default) – Secure hypervisor access control (sHype by IBM) – Flask (NSA and most widely used) 19 Xen Security Module (XSM)
  20. 20. 20 Radium Access Control Policy Capabilities › Prevent/allow two domains from communicating via event channels or accessing memory pages. › Grant a set of privileges and capabilities to a virtual machine, which is typically unavailable for unprivileged domains. › Restrict operations performed by privileged domains
  21. 21. › Type/domains Enforcement types – dom0_t – domU_t (PV domain is XEN aware) › PV does not require virtualization extensions from the host CPU – domHVM_t (HVM domain fully virtualized) – measuringService_t (The VM domain giving Radium ARTM capability) › Creating a new type › type measuringService_t – Define attributes › type measuringService_t, domain_type, domain_self_type, domain_target_type, event_type, xen_type, grant_type › But need a corresponding “allow rules” – allow sourceDomain_t targetDomain_t:className { hypercallOfTheClass } › allow measuringService_t domHVM_t:grant {read map transfer copy}; › Once the policy is in enforcing mode every virtual domain configuration file must be labeled with a security context/label – sid measuringService system_u:system_r:measuringService_t – seclabel = system_u:system_r:measuringService_t – Default system_u:system_r:Unknown_t 21
  22. 22. XSM Classes › Classes categorize related hypercalls (related to attributes) – Declaring a new class › Class class_name › Eight classes currently offered in the policy › Class Xen (consists of Dom0 only, operations dealing with the hypervisor itself but can be extended to other domains) › Class Xen {settime, readconsole, sleep, getcpuinfo} › Class domain and domain2 › Class domain {pause, unpause, resume, create, _self, _target} › Class event (contains hypercalls that refer to inter-domain communication between both domains. For a domain to communicate the allow rules have to be set for both the source and the target virtual domains) › Class event {bind, send, status, create, reset}. › Class security › Class security {compute_avc, compute_create, check_context, load_policy, compute_relabel, setenforce} › Xenstore (currently not part of XSM) must be set via Dom0 – Volatility with LibVMI, which requires Xenstore permissions to be configured › xenstore-chmod -r /local/domain/2/memory n0 r1} // if you want write ability (w1) 22
  23. 23. Agenda › Defining the problem › Introduction › Background Technologies (SRTM, DRTM,FLASK) › Radium Architecture Overview › Radium Prototype Overview › Adversary Model › Access Control Policy (XSM) › Radium Security and Performance › Related Works › Conclusion › Future Works 23
  24. 24. Radium: Security and Performance › Hypervisor verified and trusted using DRTM (Important to ensure integrity of the MAC policy) › All access is protected by the trusted Mandatory Access Control policy within the Hypervisor › Traditional trusted systems (DRTM) – 26.7 seconds to measure an untrusted/normal environment – 35.8 seconds for booting the untrusted/normal environment – A total of an average of 62.5 seconds to ensure the trustworthiness › Radium system – 27.3 seconds to measure measuring service – 11.1 seconds to boot the measuring service – 1.7 seconds to measure the untrusted/normal environment (querying ACP + memory introspection +results) – A total of an average of 40.1 seconds to ensure the trustworthiness
  25. 25. Agenda › Defining the problem › Introduction › Background Technologies (SRTM, DRTM,FLASK) › Radium Architecture Overview › Radium Prototype Overview › Adversary Model › Access Control Policy (XSM) › Radium Security and Performance › Related Works › Conclusion › Future Works 25
  26. 26. Related Works › Trusted Computing – Trusted Platform Module: Building a Trusted Software Stack and Remote Attestation › Trusted hypervisors – Flicker › Rootkit Detectors – Rootkit Detection on Virtual Machines through Deep Information Extraction at Hypervisor Level › Hypervisor based secure access control – Flux Advanced Security Kernel (Flask) – Meeting Critical Security Objectives with SELinux – Using the Flask Security Architecture to Facilitate Risk Adaptable Access Control
  27. 27. Agenda › Defining the problem › Introduction › Background Technologies (SRTM, DRTM,FLASK) › Radium Architecture Overview › Radium Prototype Overview › Adversary Model › Access Control Policy (XSM) › Radium Security and Performance › Related Works › Conclusion › Future Works 27
  28. 28. Conclusion › DRTM + VT-d boot of the hypervisor ensures integrity of the secure MAC policy › Using secure MAC policy to create a measuring service with the ability to provide use time measurements. › Using use time measurements to prevent TOCTOU attacks (you can measure at anytime) › Use of a trusted measuring service with a secure MAC policy is more efficient than rebooting/resetting an environment › Radium architecture achieves measurements with zero downtime › The use of a secure MAC policy guarantees that hypercall invocation can be controlled (unprivileged domains have access to few hypercalls) 28
  29. 29. Agenda › Defining the problem › Introduction › Background Technologies (SRTM, DRTM,FLASK) › Radium Architecture Overview › Radium Prototype Overview › Adversary Model › Access Control Policy (XSM) › Radium Security and Performance › Related Works › Conclusion › Future Works 29
  30. 30. Future Works › Incorporate Intel SGX into the Radium architecture › Create a minimal TCB hypervisor (Possibly extend Amit, Vasudevan design of eXtensible Modular Hypervisor Framework) – Multiple guest virtual domains – Incorporate MAC ACP › Employ Risk Adaptable Access Control (RAdAC) › Create two policies based on the state › Incorporate role/user and sensitivity with type/domain based 30
  31. 31. References 1. Trusted computing using AMD "Pacifica" and "Presidio" secure virtual machine technology; Geoffrey Strongin, Advanced Micro Devices, Inc. 2. BIOS chronomancy: fixing the core root of trust for measurement; John Butterworth, Corey Kallenberg, Xeno Kovah, Amy Herzog 3. Trusted Boot: Veriifyiing the Xen Launch; Joseph Cihula 4. Flicker: an execution infrastructure for TCB minimization; Jonathan M. McCune, Bryan J. Parno, Adrian Perrig, Michael K. Reiter, Hiroshi Isozaki 5. TrustVisor: Efficient TCB Reduction and Attestation; Jonathan M. McCune, Yanlin Li, Ning Qu, Zongwei Zhou, Anupam Datta, Virgil Gligor, Adrian Perrig 6. An architecture for concurrent execution of secure environments in clouds; Ramya Jayaram Masti, Claudio Marforio, Srdjan Capkun 7. Copilot - a coprocessor-based kernel runtime integrity monitor; Nick L. Petroni, Jr., Timothy Fraser, Jesus Molina, William A. Arbaugh 8. Terra: a virtual machine-based platform for trusted computing; Tal Garfinkel, Ben Pfaff, Jim Chow, Mendel Rosenblum, Dan Boneh 9. NoHype: virtualized cloud infrastructure without the virtualization; E Keller, J Szefer, J Rexford, RB Lee 10. Building a MAC-based security architecture for the Xen open-source hypervisor; Sailer, R.; Jaeger, T.; Valdez, E.; Caceres, R.; Perez, R.; Berger, S.; Griffin, J.L.; van Doorn, L. 11. Srujan Kotikela , Tawfiq Shah, Mahadevan Gomathisankaran, Gelareh Tabani, et al. Radium: Racefree on-demand integrity measurement architecture. 2015. 12. ELI: Bare-Metal Performance for I/O Virtualization; Abel Gordon, Nadav Amit, Nadav Har’El, Muli Ben-Yehuda, Alex Landau, Assaf Schuster, Dan Tsafrir 13. Breaking up is hard to do: security and functionality in a commodity hypervisor; Colp, Patrick and Nanavati, Mihir and Zhu, Jun and Aiello, William and Coker, George and Deegan, Tim and Loscocco, Peter and Warfield, Andrew 14. Innovative Instructions and Software Model for Isolated Execution; McKeen, Frank and Alexandrovich, Ilya and Berenzon, Alex and Rozas, Carlos V. and Shafi, Hisham and Shanbhogue, Vedvyas and Savagaonkar, Uday R
  32. 32. Questions??? 32

×