Virtualization and Security

Transcription

1 Virtualization and Security T , Teemu Rinta-aho

2 C o n t e n t s OS Virtualization Background Types of virtualization Xen Open source paravirtualization shype A MAC-based security architecture for Xen

3 Part I: OS Virtualization

4 O S V i r t u a l i z a t i o n Provides an abstraction from the physical hardware Allows running of several OS instances on a single hardware platform Achieved by inserting a new software layer (hypervisor) between the guest OS and the hardware

5 E m u l a t e d V i r t u a l i z a t i o n Complete emulation of the hardware Allows running of unmodified guest OS Tricks needed on e.g. x86 platform Performance penalty VMware, QEMU

6 P a r a v i r t u a l i z a t i o n Presenting similar, but not identical hardware to guest OS Requires patching of the guest OS Performance can be close to running natively on hardware A guest OS may benefit on seeing both the real and virtual resources, e.g. time TCP RTT timers etc. Xen, L4

7 V i r t u a l i z a t i o n A p p l i c a t i o n s Server virtualization Optimal usage of physical resources Live relocation Virtual appliances Disposable web browser Running several different OS on a same desktop, at the same time System snapshots Debugging

8 W i n 2 K o n V M W a r e o n L i n u x

9 Part II: Xen

10 X e n An x86 virtual machine monitor Supports paravirtualization Provides the x86/xen platform that the guest OS needs to support Close to x86 Currently Linux, Windows, NetBSD,... No need to change the applications

11 X e n 3. 0 A r c h i t e c t u r e VM0 Device Manager & Control s/w VM1 Unmodified User Software VM2 Unmodified User Software VM3 Unmodified User Software AGP ACPI PCI GuestOS (XenLinux) Back-End Native Device Drivers GuestOS (XenLinux) Front-End Device Drivers GuestOS (XenLinux) SMP Front-End Device Drivers Unmodified GuestOS (WinXP)) Front-End Device Drivers VT x x86_32 x86_64 IA64 Control IF Safe HW IF Event Channel Virtual CPU Xen Virtual Machine Monitor Hardware (SMP, MMU, physical memory, Ethernet, SCSI/IDE) Virtual MMU Source: [3]

12 x 8 6 P a r a v i r t u a l i z a t i o n : M M Paging Guest OS is responsible for allocating and managing the hardware page tables Allocated pages are registered to Xen All subsequent updates have to be validated by Xen Xen exists in a 64MB section at the top of every address space

13 x 8 6 P a r a v i r t u a l i z a t i o n : M M Segmentation Virtualized in a similar way as paging Updates to hardware segment descriptor tables are validated by Xen

14 x 8 6 P a r a v i r t u a l i z a t i o n : C P U Usually OS runs in the most privileged level in the system To protect the hypervisor from OS misbehavior, guest OS must be modified to run at a lower privilege level x86 provides four distinct privelege levels Ring 0: Xen Ring 1: Guest OS Ring 3: Applications in guest OS

15 x 8 6 P a r a v i r t u a l i z a t i o n : C P U Privileged instructions are required to be validated and executed within Xen If guest OS attempts to run it directly, the CPU won't execute it due to privilege level A table describing the handlers for exceptions is registered with Xen for validation

16 x 8 6 P a r a v i r t u a l i z a t i o n : C P U A 'fast' exception handler To optimize performance for system calls and page faults Accessed directly by the processor The handler is validated before installing into table

17 x 8 6 P a r a v i r t u a l i z a t i o n : I / O Instead of emulating hardware devices, device abstractions are exposed I/O data is transferred to and from every domain via Xen Using shared memory asynchronous bufferdescriptor rings A light-weight asynchronous event delivery mechanism from Xen to domains Similar to hardware interrupts

18 Part III: shype

19 B a c k g r o u n d VMM provides isolation between VMs Some VMs may want to share information Either explicitly point-to-point, or Via a shared virtual resource, e.g. disc Other VMs (on same hardware) may still need complete isolation from each other The information sharing must enforced to certain policies set by the administrator

20 s H y p e IBM Project, originally implemented for rhype (IBM hypervisor) Focuses on controlled resource sharing Coalitions of VMs VMM reference monitor Enforces MAC policies on inter-vm operations Supports a variety of hypervisors For Xen 3.0: 2600 lines of code, 3 hooks

21 V M C o a l i t i o n s Some VMs will co-operate 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 disc Sharing controlled by MAC policy

22 S a m p l e C o a l i t i o n Source: [4]

23 S e c u r i t y - c r i t i c a l O p e r a t i o n s Sharing of virtual resources between VMs Event channels, shared memory, domain ops Controlled and isolated inside the Xen Sharing of local virtual resources among local VMs Local VLANs, virtual discs Access controlled and isolated within MACdomains

24 S e c u r i t y - c r i t i c a l O p e r a t i o n s Sharing of distributed virtual resources VLANs spanning multiple hypervisor systems Access controlled and isolated in MACbridging domains of multiple systems

25 S e c u r i t y P o l i c i e s shype supports various kinds of security policies Biba, Bell-LaPadula, Caernarvon, Type Enforcement and Chinese Wall Implemented for Xen: Chinese Wall Type Enforcement

26 C h i n e s e W a l l P o l i c y Enables administrators to ensure that certain VMs cannot run at the same time Useful to mitigate covert channels Other requirements, e.g. workload types of competitors Not running Neste and Shell accounting at the same time

27 C h i n e s e W a l l P o l i c y VMs are assigned ChWall-types ChWall-conflictsets are defined VMs in a conflict set may not be run simultaneously

28 T y p e E n f o r c e m e n t Specifies which running VMs can share resources Implemented by mapping coalition membership onto TE-types Each VM is assigned a TE-type (coalition membership) VMs can share virtual resources only if they have a TE-type in common

29 s H y p e A r c h i t e c t u r e Policy manager Mediation hooks Access Control Module (ACM)

30 s H y p e A r c h i t e c t u r e Source: [4]

31 P o l i c y M a n a g e m e n t Offers means to create and maintain policies Translates XML to binary presentations The binary policy includes the assignment of VMs to ChWall-types, TE-types and Chinese Wall conflict sets Policy management can run in its own domain or a special purpose system Even on separate hardware

32 P o l i c y E n f o r c e m e n t 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

33 R e f e r e n c e M o n i t o r Source: [4]

34 A c c e s s C o n t r o l H o o k s Domain management operations create, destroy, save, restore, migrate Mediated by a dom_op hook Event channel operations setup, destroy Mediated by an event_op hook Shared memory operations setup, grant access, remove access Mediated by a shmem_op hook

35 D o m a i n O p e r a t i o n H o o k Hook reports to ACM The security reference of the domain originating the operation The security reference of the domain being created or destroyed ACM Assigns security labels to created domains Checks ChWall conflict sets Adjusts the sets when allowing operation Decision not cached

36 E v e n t C h a n n e l H o o k Hook reports to ACM The security references of the domains ACM Checks that TE-types of the domains match Decision cached

37 S h a r e d M e m o r y H o o k Hook reports to ACM The security references of the domains ACM Checks that TE-types of the domains match Decision cached

38 A c c e s s C o n t r o l M o d u l e Maintains policy state Makes policy decisions Interacts with the policy manager VM Updates the decision caches Stores all security policy information locally in the hypervisor

39 D e c i s i o n C a c h i n g The ACM decisions are cached locally in the VM structures of the domains Only one call to ACM needed unless policy changes for all subsequent inter-vm communication channel setups When a VM is destroyed, the VM-id must be cleared from all caches If a policy changes, the access authorization changes are propagated in caches of VMs

40 P o l i c y C h a n g e s 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

41 M A C - d o m a i n s Enable multiple coalitions to share a real resource MAC policy enforcement done inside the domain providing the resource Based on e.g. SELinux shype offers to MAC-domains a hypervisor call that returns the coalition membership information

42 The End

43 R e f e r e n c e s 1. Xen and the Art of Virtualization, 2. Building a MAC-based Security Architecture for the Xen Opensource Hypervisor, s/hypervisor/index.html 3. Updated overview of Xen 3.0, 4. shype: Mandatory Access Control For XEN,