sHype: Mandatory Access Control For XEN

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 doesnt 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
Information Flows
16
Type of Flow

• Through Shared or Exclusive Resources
• Through non-isolated virtual resources
• Through non-isolated real system resources
• Through Covert Channels

17
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

18
sHype Architecture
19
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)

20
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

21
Chinese Wall Policy (cont.)
Shell Oil
General Steel
ExxonMobil
Oil Companies
Steel Companies
22
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
Shipping
Ads
Customers
VM A
1
0
0
1
VM B
0
1
0
1
VM C
1
1
1
0
23
Reference Monitor Basics

• Reference monitor enforces policies
• Mediates all security-critical operations
• Can protect itself from modification
• Already provided by VM properties
• Is as simple as possible to enable software
  validation
• Thin software layer

24
Security-Critical Operations

• Any operation that is regulated by the policy
• Example memory sharing between VMs
• If memory sharing prohibited between VMs
  hypercalls to map memory must fail
• Example establishing event channel between VMs

25
MAC Bridging
Trusted vLAN
MAC Domain
V M
MAC Domain
MAC Domain
V M
MAC Domain
XEN
XEN
Sys. Hardware
Sys. Hardware
Network
26
Policy Enforcement

• Policy enforcement separated from access control
  policy as in Flask (SELinux architecture)
• Security hooks embedded in core hypervisor
• Hooks query access control module (ACM) and
  enforce decisions
• Decisions cached until policy changes
• Trusted policy management VM manages ACM

27
Reference Monitor
28
Policy Changes

• Updates ACM caches
• Revokes event channels and shared memory regions
  that are currently in use and are no longer
  authorized
• Users of event channels receive errors which
  must be handled anyway
• Users of shared memory (e.g. device drivers)
  receive memory error
• sHype may soon inform VM when memory is revoked
  to allow graceful shutdown

29
Performance

• 10 transfers of 108 disk blocks from Dom0 to DomU
• dd if/dev/hda7 of/dev/null count10000000
• No perceivable overhead took 1196-1198 seconds
• Grant-table (shared memory permissions) hook
  invoked 12106 times

30
References/Related Work

• Terra
• PHYP
• Vax VMM Security Kernel

31
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.pdfkey1945464key24071529311collGU
  IDEdlACMCFID67774667CFTOKEN76212332

32
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

33
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/peducati
  on/wp/2bb2/2bb2.pdf

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

35
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

36
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

37
Hypervisor Architecture
38
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

39
Problem Statement

• How to control information flow to achieve
• integrity
• confidentiality

40
Example Information Flows
41
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

42
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

43
Isolation guaranties of rHype

• Direct information flow between different virtual
  resources must be prevented
• Direct information flow between real resources
  must be prevented

44
Reference Monitor Architecture
45
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

46
Reference Monitor Architecture

• Formal Security Policy defines
• access rules
• security labels for partitions and logical
  resources

47
Reference Monitor Architecture

• High performance ( lt 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)

48
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

49
Access Control Enforcement
50
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

51
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

52
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

53
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
  partitions rights suffice to apply certain
  operation to an object

54
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

55
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

56
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

57
Security Labels
58
Security Labels

• virtual resource
• one integrity UAC and one confidentiality UAC
• partition
• range of from and to UACs

59
Security Labels

• single-level partitions
• when from and to UACs are the same
• multi-level partitions
• when the range includes more than one UAC

60
Policy Change

• re-evaluation call-back function
• invoked by ACM
• re-evaluates the original access control decision
• revokes shared resources in case the
  authorization is no longer granted

61
Security Evaluation of sHype

• layered approach to security
• small security apparatus which is easy to validate

62
Security Evaluation of sHype

• Assumptions
• correct identification of partitions and
  resources for initial labeling
• correct security policies
• fault-tolerant hardware and physical components
• no covert channeling
• no malicious behavior or corruption of hyperviser
  or any of the privileged partitions (policy or
  I/O partitions)