Virtualization in Multilevel Security Environments
Dr. Christoph Schuba [email protected] http://blogs.sun.com/schuba
1 Agenda • Using OS Virtualization to Build MLS Architecture > OS Virtualization > Labeled Local and Remote File Systems > Trusted Desktop • Overview Trusted VirtualBox • What We Can Do Today • What We Can Do Tomorrow
- 2 - Agenda • Using OS Virtualization to Build MLS Architecture > OS Virtualization > Labeled Local and Remote File Systems > Trusted Desktop • Overview Trusted VirtualBox • What We Can Do Today • What We Can Do Tomorrow
- 3 - Virtualization Technologies • Type 1 - Hypervisor-based virtualization > xVM - style (think XEN) > Logical Domains (LDOM) - firmware-style, Sparc CMT • OS virtualization > Containers (aka Zones), both x64 and Sparc • Type 2 - Hypervisor-based virtualization • Desktop and network virtualization > Sunray, VDI, Crossbow, ... • Combinations!
- 4 - Server Virtualization Categories
Hard Partitions Virtual Machines OS Virtualization Resource Mgmt.
App
OS
Server Multiple OS Single OS
> Very High RAS > Ability to live migrate > Very scalable and low > Very scalable and low an OS overhead overhead > Very Scalable > Ability to run different > Single OS to manage > Single OS to manage > Mature Technology OS versions and types > Cleanly divides system > Fine grained resource > Ability to run different > De-couples OS and and application management OS versions HW versions administration > Fine grained resource management
- 5 - Virtualization
Virtualization is the idea to introduce an abstraction layer that decouples previously adjacent layers to deliver greater resource utilization and flexibility.
• Layers? > application, operating system, network, storage, file system, memory, resources, etc.
- 6 - A Word About the Software • Solaris vs. OpenSolaris > Initially Developer Focus, soon Enterprise > Free > Open Source > Superior prototyping Environment for Security Research – virtualization technologies, – process privileges, – fault and service management, – open storage, especially ZFS – cryptographic framework, etc. • Type-2 Hypervisor VirtualBox
- 7 - Multilevel Architecture • Layered architecture Need-to- Internal know Use Public implements: > Mandatory access control Global Zone > Hierarchical labels Solaris Kernel > Principle of least privilege SPARC, x86 or x64 Hardware > Trusted path Local or Sun Ray display > Role-based access
- 8 - Solaris Trusted Extensions
• All objects are labeled, based on sensitivity • Access governed by label hierarchal relationship
Commercial Hierarchy Government Hierarchy Executive Non-Hierarchical Management Top Secret VP and Above Secret
Directors Daisy's Confidential Net Inc. Music Online Florists All Employees Solaris 10 with or w/out Classified Trusted Extensions Trusted Extensions Trusted Extensions
Mandatory Access Control & Security Labels
- 9 - What's Solaris Trusted Extensions? • A redesign of the Trusted Solaris product using a layered architecture. • An extension of the Solaris 10 security foundation providing access control policies based on the sensitivity/label of objects • A set of software packages integrated into the standard Solaris 10 system. • A set of label-aware services which implement multilevel security
- 10 - What are Label-Aware Services? • Services which are trusted to protect multilevel information according to predefined policy • Trusted Extensions Label-aware service include: > Labeled Desktops > Labeled Printing > Labeled Networking > Labeled Filesystems > Label Configuration and Translation > System Management Tools > Device Allocation
- 11 - Trusted Extensions in a Nutshell • Every object has a label associated with it > Files, windows, printers, devices, network packets, network interfaces, processes, etc... • Accessing or sharing data is controlled by the objects' label relationship to each other > 'Secret' objects do not see 'Top Secret' objects • Administrators utilize Roles for duty separation > Security admin, user admin, installation, etc... • Processes use privileges rather than root access • Strong independent certification of security
- 12 - Trusted Solaris History
• 1990, SunOS MLS 1.0 > Conformed to TCSEC (1985 Orange Book) • 1992, SunOS CMW 1.0 > Compartmented-mode workstation requirements > Release 1.2 ITSEC certified for FB1 E3, 1995 • 1996, Trusted Solaris 2.5 > ITSEC certified for FB1 E3, 1998 • 1999, Trusted Solaris 7 • 2000, Trusted Solaris 8 > Common Criteria: CAPP, RBACPP, LSPP at EAL4+ • 2008, Solaris 10 Trusted Extensions > Common Criteria: CAPP, RBACPP, LSPP at EAL4+ - 13 - Solaris™ Trusted Extensions
Trusted Solaris 8 Trusted Extensions Label- Label- Trusted Trusted Trusted Trusted Aware Aware Networking Desktop Networking Desktop Services Services
Modified Process Trusted's Process Containment TCP/IP Containment Privileges TCP/IP [Labels] Privileges [Zones] Solaris 10* ●Benefits: ● Software portability ● Patch compatibility ● Shorter release window ● More familiar
- 14 - Integration of Trusted Extensions • Leveraging Solaris functionality: > Process & User Rights Management, auditing, zones > Make use of existing Solaris kernel enhancements • Elimination of patch redundancy: > All Solaris patches apply, hence available sooner > No lag in hardware platform availability • Extend Solaris Application Guarantee • Full hardware and software support > File systems (UFS, VxFS, ZFS, SAM-FS, QFS, etc.) > Processors (SPARC, x86, AMD64)
> Infrastructure (Cluster, Grid, Directory, etc.) - 15 - Labeled Zones in Trusted Extensions • Each zone provides a security boundary > Unique sensitivity label per zone > Labels are implied by process zone IDs > Processes and data are isolated by label • No object is writable by more than one zone > Mount policy prevents writing down or reading up > Network policy requires endpoint label equality (default) • Information sharing between zones is based on label relationships
- 16 - Solaris Kernel Services • Multilevel Networking Need-to- Internal Public know Use • Filesystem mount policy Global Zone • Containment (zones) Solaris Kernel > Processes SPARC, x86 or x64 Hardware > Devices Local or Sun Ray display > Resource Pools
- 17 - Multilevel Services • Label Policy Administration Need-to- Internal Public know Use • Name Services • Labeled Printing Global Zone • File relabeling Solaris Kernel • Device Allocation
SPARC, x86 or x64 Hardware • Labeled Windows Local or Sun Ray display • Single Sign-on
- 18 - Single Level Applications • Application Launchers Need-to- Internal Public know Use • Windows XP Remote Desktop Global Zone • Mozilla
Solaris Kernel • StarOffice • CDE or Java SPARC, x86 or x64 Hardware Local or Sun Ray display Desktop System
- 19 - Agenda • Using OS Virtualization to Build MLS Architecture > OS Virtualization > Labeled Local and Remote File Systems > Trusted Desktop • Overview Trusted VirtualBox • What We Can Do Today • What We Can Do Tomorrow
- 20 - Filesystem MAC policies • Labels derived from a filesystem owner's label • Mount policy is always enforced > No reading-up – Read-write mounts require label equality in labeled zones > Reading-down – Read-only mounts require dominance by client – Can be restricted via zone's limit set and network label range > Writing-up – Cannot write-up to regular files – Limited write-up to label-aware services (via TCP and doors) > Writing-down – Restricted to privileged label-aware global zone services - 21 - Labeled Filesystems
Global Zone / • Read-only zone usr access to lower- need-to-know internal public level directories
root root root Need to know Internal Zone Public Zone • Supports all Zone export export export filesystem types • Both local and NFS filesystems • Administered y h c r a
r ADMIN_HIGH
Legend e via Global Zone i NEED TO KNOW H
Subdirectory l INTERNAL USE ONLY e
b PUBLIC a Loopback Mount L ADMIN_LOW
- 22 - Labeled Filesystems
Global Zone / • Read-only zone usr access to lower- need-to-know internal public level directories
root root root Need to know Internal Zone Public Zone • Supports all Zone export usr export usr export usr filesystem types • Both local and NFS filesystems • Administered y h c r a
r ADMIN_HIGH
Legend e via Global Zone i NEED TO KNOW H
Subdirectory l INTERNAL USE ONLY e
b PUBLIC a Loopback Mount L ADMIN_LOW
- 23 - Labeled Filesystems
Global Zone / • Read-only zone usr access to lower- need-to-know internal public level directories
root root root Need to know Internal Zone Public Zone • Supports all Zone export zone usr export usr export usr filesystem types
internal • Both local and NFS filesystems export • Administered y h c r a
r ADMIN_HIGH
Legend e via Global Zone i NEED TO KNOW H
Subdirectory l INTERNAL USE ONLY e
b PUBLIC a Loopback Mount L ADMIN_LOW
- 24 - Labeled Filesystems
Global Zone / • Read-only zone usr access to lower- need-to-know internal public level directories
root root root Need to know Internal Zone Public Zone • Supports all Zone export zone usr export zone usr export usr filesystem types
internal public public • Both local and NFS filesystems export export export • Administered y h c r a
r ADMIN_HIGH
Legend e via Global Zone i NEED TO KNOW H
Subdirectory l INTERNAL USE ONLY e
b PUBLIC a Loopback Mount L ADMIN_LOW
- 25 - NFS Support for Zones • NFS clients: > Each zone has its own automounter > Kernel enforces MAC policy for NFS mounts • NFS servers: > Per-zone sharing policy set in global zone > Kernel enforces MAC policy for NFS requests • The global zone administrator can export filesystems from labeled zones > Each export must be a single-level filesystem > Zone's label automatically applied to each export
- 26 - Labeled Networking
Intranet Intranet Intranet
Need-to- Internal know Use Public
SunRay Network Global Zone
Solaris Kernel
Multilevel Network
- 27 - Single and Multilevel Ports • Kernel maintains cache of labels and endpoints > Implicit labels based on IP address or Network > Explicit labels based on CIPSO label in packet • Packets are routed to hosts and zones by label matching rules > Generally label equality required between endpoints > Multilevel ports accept labels within range or set > For NFS operations, read-down is supported – Sockets are marked with special socket attribute – Unique binding of port, label, and IP address
- 28 - Agenda • Using OS Virtualization to Build MLS Architecture > OS Virtualization > Labeled Local and Remote File Systems > Trusted Desktop • Overview Trusted VirtualBox • What We Can Do Today • What We Can Do Tomorrow
- 29 - Solaris Trusted Desktop • Provides a user friendly graphical environment to interact with multiple classifications of data simultaneously whilst maintaining the security of that data • Screen real estate is shared, everything else is compartmentalized according to security label > Filesystem and other device access, Interclient communication, Copy & Paste, Drag & Drop are all restricted to applications with the same security label • Workspace role assumption for performing user accountable, privileged tasks within the same desktop session
- 30 - Trusted Desktop - Key Features • Workspaces are labeled to allow launching of applications at different security labels
• Windows are labeled both on their frames and the tasklist to provide a visual indicator of their security context
- 31 - Trusted Desktop – Key Features • Labels are color coded to make them even more easily identifiable
- 32 - Trusted Desktop – Key Features • The Trusted Stripe is the primary trust indicator, showing a shield icon when the user is interacting with the Trusted Path of the system e.g. entering passwords • Also has a role assumption menu, a current workspace label indicator and window label indicator for the window with the current pointer focus
- 33 - Trusted Desktop – Key Features • The selection manager intercepts C&P and D&D requests and denies them unless the security policy permits the user to reclassify data
- 34 - Labeled Desktops and Thin Clients
- 35 - Agenda • Using OS Virtualization to Build MLS Architecture > OS Virtualization > Labeled Local and Remote File Systems > Trusted Desktop • Overview Trusted VirtualBox • What We Can Do Today • What We Can Do Tomorrow
- 36 - Virtualization inside Labeled Zones
Vista Vista
VirtualBox VirtualBox Public Need-to- Internal Public know Use
- 37 - Trusted VirtualBox - What is it? • Combination of existing technology into solutions • Layered virtualization: > VirtualBox inside Labeled Zones • Extending Solaris Trusted Extensions functionality to other Operating Systems Vista Vista > Mandatory Access Control VirtualBox VirtualBox Need-to- Public know Internal Public > Multilevel Security Use
> Labeled desktop, networking, Solaris Global Zone/Kernel device access Hardware
- 38 - Delivered as...? • Configuration software • Live CD image builder • Service • Preconfigured hardware > laptop, workstation
- 39 - Recipe - Blend to perfection
- 40 - Recipe - Blend to perfection
1. Solaris Trusted Extensions 2. VirtualBox instances in Labeled Zones 3. Encrypted ZFS datasets for data storage 4. Labeled IPsec for communications security 5. Validated Execution for system file integrity protection
- 41 - Virtualization inside Labeled Zones
Vista Vista
VirtualBox VirtualBox Public Need-to- Internal Public know Use
- 42 - Virtualization for SNAP • Multiple Windows instances in the Sun Ray server • Currently requires separate machines
Vista Vista
VirtualBox VirtualBox Need-to- Public know Internal Public Use
Solaris Global Zone/Kernel / SRSS Hardware
One server - 43 - Fat Client running apps in labeled zones
Vista Vista
VirtualBox VirtualBox Need-to- Public know Internal Public Use
Solaris Global Zone/Kernel Hardware
One FAT client
- 44 - Secure Laptop OLPCeo • Secure laptop for high value information • Preconfigured to provide secure Windows
Vista Vista
VirtualBox VirtualBox Need-to- Public know Internal Public Use
Solaris Global Zone/Kernel Hardware
One FAT laptop - 45 - Agenda • Using OS Virtualization to Build MLS Architecture > OS Virtualization > Labeled Local and Remote File Systems > Trusted Desktop • Overview Trusted VirtualBox • What We Can Do Today • What We Can Do Tomorrow
- 46 - What we can do today • Prevent unauthorized dissemination of confidential data (leaks) • Isolation via Virtualization • Prevent loss of confidential data via remote attack • Medium assurance of system integrity
- 47 - Preventing Leaks • Trusted Desktop provides isolation • Data is contained in labeled zones • Networking is constrained by labeling policy • Confidential data cannot be: > Downgraded to the public zone > Observed by public zones processes > Exported to removable media > Sent to a public printer
- 48 - Isolation by Virtualization • User programs run in uniquely labeled zones (including VirtualBox) • Security enforcing programs and administrative data are protected in the global zone • No object is writable by more than one zone • Information sharing between zones is based on label relationships
- 49 - Defense Against Remote Attack • No network services are listening for remote connections in labeled zones • Clients in the internal zone cannot access the Internet except through VPN • The global zone only serves local clients
- 50 - Medium Assurance of System Integrity • All policy configuration is inaccessible from labeled zones • Shared data is always read-only for clients • Auditing is enabled and cannot be observed or erased by from labeled zones • Separation of duty is enforced through administrative roles • System is Common Criteria certified at EAL4+ for CAPP, RBAC, and LSPP
- 51 - Agenda • Using OS Virtualization to Build MLS Architecture > OS Virtualization > Labeled Local and Remote File Systems > Trusted Desktop • Overview Trusted VirtualBox • What We Can Do Today • What We Can Do Tomorrow
- 52 - What we can do tomorrow • Prevent loss of data from theft • Privacy based on need to know • Loss of data from impersonation • High assurance of system integrity
- 53 - Loss of data from theft • Each zone will have a unique ZFS dataset encrypted with a unique key • Zones cannot be booted without providing the key • Key could be provided via a USB dongle or smartcard
- 54 - Privacy based on need to know • Access to remote data can be restricted via labeled IPsec • Security Associations will match data to the appropriately labeled zone • Network privacy and Integrity will be provided
- 55 - Loss of Data from Impersonation • Use of multi-factor authentication to mitigate password attacks • Use combination of biometric, smartcard, or USB dongle to provide something > you are and/or you have as well as something you know
- 56 - High Assurance of System Integrity • Use of Digital Signatures to validate executables, shared libraries and administrative databases • Use of TPM as root of trust for system to ensure that OS is itself trustworthy
- 57 - Thank you. Questions?
Dr. Christoph Schuba [email protected] http://blogs.sun.com/schuba
58