Defense

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

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

4


› Introduction




› Adversary Model



› Related Works

› Conclusion

› Future Works

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

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

Introduction Cont…

7


› Introduction

› Background Technologies (SRTM, DRTM, FLASK)



› Adversary Model



› Related Works

› Conclusion

› Future Works

8

Static Root of Trust for Measurement (SRTM)

9

Dynamic Root of Trust for Measurement (DRTM)

10

FLASK Architecture Overview 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


› Introduction




› Adversary Model



› Related Works

› Conclusion

› Future Works

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

13

Radium: Architecture

Trusted Hardware

Trusted Hypervisor

14


› Introduction




› Adversary Model



› Related Works

› Conclusion

› Future Works

15

Radium: Prototype Overview

16


› Introduction




› Adversary Model



› Related Works

› Conclusion

› Future Works

17

Adversary Model

18


› Introduction




› Adversary Model



› Related Works

› Conclusion

› Future Works

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)

Xen Security Module (XSM)

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

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)

23


› Introduction




› Adversary Model



› Related Works

› Conclusion

› Future Works

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


› Introduction




› Adversary Model



› Related Works

› Conclusion

› Future Works

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


› Introduction




› Adversary Model



› Related Works

› Conclusion

› Future Works

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)

29


› Introduction




› Adversary Model



› Related Works

› Conclusion

› Future Works

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

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

Documents

Defense