This document presents Radium, a secure policy engine in the hypervisor that aims to provide integrity measurement of computing environments. It discusses defining the problem of trusting computing devices and components. It provides background on technologies like SRTM, DRTM and Flask that are used. The Radium architecture employs DRTM to boot a trusted hypervisor and uses asynchronous root of trust for measurement and a secure mandatory access control policy to regulate access between trusted and untrusted environments. The prototype implementation and evaluation show Radium can provide timely integrity measurements with zero downtime compared to traditional trusted systems. Future work areas include incorporating Intel SGX and improving the minimal trusted computing base of the hypervisor.

1. Radium: Secure Policy Engine in
Hypervisor
Tawfiq Shah

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. 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. 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. 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. › 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. 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. Static Root of Trust for Measurement
(SRTM)
8

9. Dynamic Root of Trust for Measurement
(DRTM)
9

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. 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. 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. Radium: Architecture
13
Trusted Hardware
Trusted Hypervisor

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. Radium: Prototype Overview
15

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. Adversary Model
17

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. › 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
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. › 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Questions???
32