1 / 55

sHype: Mandatory Access Control For XEN

sHype: Mandatory Access Control For XEN. Reiner Sailer, Trent Jaeger, Enriquillo Valdez, Ramon Caceres, Ronald Perez, Stefan Berger, John Linwood Griffin, Leendert var Doorn Presented by Michael LeMay. Introduction. IBM Project, originally implemented for rHype (next presentation)

rianna
Télécharger la présentation

sHype: Mandatory Access Control For XEN

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. sHype: Mandatory Access Control For XEN Reiner Sailer, Trent Jaeger, Enriquillo Valdez, Ramon Caceres, Ronald Perez, Stefan Berger, John Linwood Griffin, Leendert var Doorn Presented by Michael LeMay

  2. Introduction • IBM Project, originally implemented for rHype (next presentation) • Focuses on controlled resource sharing • Current hypervisors allow resource sharing, but do not regulate it with formal policies • Xen shared resources: shared memory and event channels • Hard to analyze security properties • Not scalable

  3. Why Isolation is Necessary • Malicious or manipulated OSs • OS Security Controls do not solve isolation issues because processes share: • Libraries • File systems • Networks • Displays • Sharing can be useful, but it must be regulated • Hypervisor treats OSs as processes

  4. Fundamental Security Problems • Discretionary controls assume users act in authorized way. • Vulnerable applications or careless users may allow malicious code to enter and compromise a system • Accounts for success of most email viruses, man-in-the-middle, and phishing attacks • Susceptible to attacks by root

  5. Attacks on Operating Systems • Malicious developers • Trap doors during distribution • Boot-sector viruses • Compiler trap-doors • Hypervisors can isolate malicious operating systems from other VMs • Is this less of a problem for hypervisors?

  6. sHype • Security architecture for virtualization environments • Controls sharing between VMs according to formal policies • Objectives: • Near-zero overhead on critical paths • Non-intrusiveness on existing VMM code • Scalable system management to many machines • Support for VM migration via machine-independent policies

  7. Goals • Goals derived from requirements of commercial environments • High-assurance VMMs attempt to control all information flows • sHype controls explicit information flows • Memory sharing, event channel messages, virtual disks • sHype doesn’t attempt to control all covert channels • Processor usage, error messages, memory allocation

  8. Foundation • Implemented for Xen hypervisor, IBM rHype, and IBM PHYP • Controls all inter-VM communications • Only added 2600 lines of code to Xen • 3 hooks required • Adds about 1% overhead • Achieves EAL4 medium assurance

  9. EAL4

  10. EAL4 Highlights • Fully-defined external interfaces • Must specify all the ways the system can be affected by users and other software • Security enforcing high-level design • Descriptive low-level design • Informal correspondence demonstration • Independent testing • Independent vulnerability analysis • Linux and Win2k are EAL4

  11. Controlled Access Protection Profile • Based on the Controlled Access Protection Profile: • http://niap.nist.gov/cc-scheme/pp/PP_CAPP_V1.d.pdf

  12. Xen VM Separation • Virtual machines run within domains • Special domain: Dom0 (domain zero) • Manages other VMs • Create, destroy, migrate, save, restore • Assigns I/O devices to VMs • DomUs (user domains) • Can run any para-virtualized OS • Two shared resources between DomUs: • Event channels • Shared memory

  13. VM Coalitions • Some VMs will cooperate with each other • Groups of cooperating VMs should be separated from other coalitions • Two VMs both processing orders • May need to share a single virtual disk • Sharing controlled by MAC policy

  14. Sample Coalitions

  15. Dom0: Device Domain • Device domain hosts device drivers • Hypervisor controls connections to device domain from other VMs • Device domain is trusted to isolate virtual disks and their data • Thus, part of trusted computing base

  16. sHype Architecture

  17. Design Basics • sHype uses built-in VM separation • TPM attestation allows hypervisor and VMs to prove their integrity at runtime to remote systems • Authorizes access to resources only upon initial access and after policy changes • Low performance overhead • Enforces formal policies • Basis for defenses against DoS through resource policies • Supports service level agreements (SLA)

  18. Chinese Wall Policy • Based on concept of Conflict-of-Interest (COI) • Cosider an investment firm that serves three companies: • ExxonMobil • Shell Oil • General Steel • It is not desirable to run workloads for Exxon and Shell on the same machine simultaneously • It is acceptable to run General Steel tasks with either Exxon or Shell tasks, since they do not compete

  19. Chinese Wall Policy (cont.) Shell Oil General Steel ExxonMobil Oil Companies Steel Companies

  20. Type Enforcement • VMs can only share resources if they share at least one type • Each type represents a coalition • Can be implemented in vector form: -------- Types -------- Orders Ads Shipping Customers VM A 0 1 0 1 VM B 0 1 1 0 VM C 1 1 0 1

  21. MAC Bridging Trusted vLAN MAC Domain V M MAC Domain MAC Domain V M MAC Domain XEN XEN Sys. Hardware Sys. Hardware Network

  22. Performance • 10 transfers of 108 disk blocks from Dom0 to DomU • dd if=/dev/hda7 of=/dev/null count=10000000 • No perceivable overhead, took 1196-1198 seconds • Grant-table (shared memory permissions) hook invoked 12*106 times

  23. References/Related Work • Terra • PHYP • Vax VMM Security Kernel

  24. Terra • “Trusted VMM” • Requires trusted platform support, including hardware and software attestation • T. Garfinkel, et. al.; “Terra: A Virtual Machine-Based Platform for Trusted Computing”, http://delivery.acm.org/10.1145/950000/945464/p193-garfinkel.pdf?key1=945464&key2=4071529311&coll=GUIDE&dl=ACM&CFID=67774667&CFTOKEN=76212332

  25. Terra (cont.) • Supports open- and closed-box VMs • Open-box: current general purpose systems • Closed-box: not controlled by machine operator, controlled by software distributor. Can prove to remote systems that software is well-behaved. • Used to implement closed-box version of Quake

  26. PHYP • Commercial IBM hypervisor • Dynamically partitions resources among VMs • Increases utilization, ROI • sHype being integrated into PHYP • http://www-03.ibm.com/servers/enable/site/peducation/wp/2bb2/2bb2.pdf

  27. VAX VMM Security Kernel • Explains how VAX microcode was modified to support both full virtualization (all sensitive instructions trap), and recursive virtualization • VMM designed to achieve A1 rating from NCSC • http://ieeexplore.ieee.org/iel2/300/2323/00063834.pdf?tp=&arnumber=63834&isnumber=2323

  28. sHype: Secure Hypervisor Approach to Trusted Virtualized Systems Reiner Sailer, Enriquillo Valdez, Trent Jaeger, Ronald Perez, Leendert var Doorn, John Linwood Griffin, Stefan Berger presented by Anna Yershova

  29. Contribution • Implemented reference monitor interface • Incorporated into vHype (IBM research hypervisor for the Intel x86 platform) • Achieves • medium assurance (EAL4) • near-zero security-related overhead

  30. Hypervisor Architecture

  31. Problem Statement • Hypervisors offer isolation at the virtual resource level • Information flow occur when partitions: • share virtual recourses • assignment of exclusive virtual resources is incorrectly handled

  32. Problem Statement • How to control information flow to achieve: • integrity • confidentiality

  33. Example: Information Flows

  34. Types of Flow • access the same S virtual resource (vLAN) or the same E resource at different times (virtual disk) • access different E resources, which are not correctly isolated from each other • access virtual resources that are mapped onto uncontrolled shared real resources • covert channeling

  35. Access Control Policies of sHype • Non-exclusive access of partitions to virtual resources must be guarded and strictly controlled according to security policy • Exclusive assignment must be guarded and strictly controlled according to security policy

  36. Isolation guaranties of rHype • Direct information flow between different virtual resources must be prevented • Direct information flow between real resources must be prevented

  37. Reference Monitor Architecture

  38. Reference Monitor Architecture • Based on full separation of • access control enforcement, using enforcement hooks • access control policy is referenced by hooks to retrieve access control decisions

  39. Reference Monitor Architecture Formal Security Policy defines: • access rules • security labels for partitions and logical resources

  40. Reference Monitor Architecture • High performance ( <= 1% security related overhead on the critical path) • ability to enforce policy autonomously (system administration) • allow for flexible enforcement of various policies (hypervisor and ACM module are independent, allowing separation of system security and administration)

  41. Access Control Enforcement: Security Hook Function • gathers access control information • partition label • virtual resource label • access operation type • determines access decision by calling to ACM • enforces access control decision

  42. Access Control Enforcement

  43. Access Control Enforcement • to keep overhead near-zero • bind-time authorization for access control decisions • works for vLAN, vSCSI, shared memory, vTTY • the binding must be revoked if the policy changes • explicit caching of access control decisions for other resources locally in LPAR0

  44. Access Control Module • stores policies • allows flexible policy management • makes policy decisions • triggers call-back functions to re-evacuate access control decisions when the policy changes

  45. Access Control Module • exports several functions: • H_security – policy management • acm_init – initial labeling inserted in hyperviser core whenever the resource or partition is created • acm_authorize – takes labels and returns true or false

  46. Security Policy • For each virtual object defines the requirements to access it • For each partition subject defines the authorization to access resources • Access rules that decide whether a logical partition’s rights suffice to apply certain operation to an object

  47. Security Policy • Each object and subject gets a label • To get access of partitions to virtual resources, the partitions’ label should “dominate” the resources security label with regards to the access type • “Dominate” predicate is specific to the policy

  48. Caernarvon Security Policy • A static security policy (resources are not relabeled during operation) • Decisions change only if the underlying policy changes • Good for moving the decisions to the binding phase of virtual resources

  49. Security Labels • organizational access classes (OACs) • type: • secrecy (unclassified, secret, top secret) • integrity (low, medium, high) • organization ID (orgID) • universal access classes (UACs) • aggregate multiple OACs with the same OAC type

  50. Security Labels

More Related