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 - -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, , 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: > Global Zone > Hierarchical labels Solaris Kernel > Principle of least privilege SPARC, x86 or x64 Hardware > Trusted path Local or 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 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 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 > : 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 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 > , 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