Download - XPDS13: SecureServe - A Multi-level Secure Server Virtualization Platform on Xen - Jason Sonnek, Adventium Labs

Secure Server Project

Xen Project Developer Summit 2013 Adven9um Labs Jason Sonnek

10/16/13 1 © Adven9um Labs 2013

Outline

I.  Mo9va9on, Objec9ves II.  Threat Landscape III.  Design IV.  Status V.  Roadmap

10/16/13 2 © Adven9um Labs 2013

Mo9va9on

•  In a nutshell: “Secure Server Mul9plexing” –  In a cloud environment –  Mul9ple tenants

•  Goals: –  Ensure data and processing are safe from co-‐tenants –  Ensure controls on informa9on separa9on and flow are sa9sfied

•  Today: –  Xen hypervisor, hardware-‐assisted virtualiza9on provide tools necessary to

isolate hardware –  Problem: many shared components in dom0, insufficient isola9on –  The easy way out:

•  Dedicated hardware for each tenant •  Imprac9cal when there are a large number of tenants, rela9onships are evolving

10/16/13 3 © Adven9um Labs 2013

Objec9ve

•  SecureServe ideal –  Enables mul9ple tenants to share a single pla[orm securely –  High-‐assurance, isolated so]ware par99ons –  Enables controlled informa9on sharing between tenants –  Supports enterprise-‐ready management –  Low cost

10/16/13 4

Green Orange

Xen

SecureServe

Cloud Management

© Adven9um Labs 2013

Current State

•  Weakest guest is the weakest link in the system –  Guest aaack vector: many shared components in dom0

•  Device emula9on, virtual devices, toolstack, XenStore •  Cross-‐VM side channel aaacks

•  Cloud management provides an addi9onal aaack vector –  Users must be able to manage and configure their VMs. –  XAPI:

•  Complex (130K LOC) •  Interfaces with many other components.

10/16/13 5

Green Orange

Xen

dom0 xapi XenStore nic disk

netback blktap QEMU


Current State

•  Desire controlled informa9on sharing between tenants •  Inter-‐VM networking

–  Can define “separate” networks in dom0 –  Separa9on in dom0 is weaker than separa9on provided by hypervisor

•  Goal: enable high-‐assurance private networks

10/16/13 6

Green Orange

Xen


netback blktap QEMU

Compliance


Threat Landscape

•  Recent (2012-‐13) Xen-‐tagged CVE vulnerabili9es (tag cloud below) •  73 vulnerabili9es represented, some with mul9ple poten9al effects

–  65 "guest", e.g. "allows local guest administrators to" –  8 TMEM (transcendental memory) –  4 "overflow" –  4 QEMU –  3 "drivers" (all in reference to backends) –  2 xenstore

10/16/13 7 © Adven9um Labs 2013

Threat Landscape

•  Aaackers target toolstack, hypervisor, management so]ware, … with varying goals: –  Denial of Service –  Escala9on of Privilege –  Acquisi9on of Informa9on

•  Vulnerability types on the radar: –  API -‐-‐ arguments not adequately sanity checked –  Aspects of Intel/AMD instruc9on set that emulator handles incorrectly –  Failure to completely and correctly check permissions –  Weakness in recovering from error condi9ons –  Exploitable PCI pass-‐through devices, especially bus mastering capable ones –  Logic errors that can be triggered by unusual condi9ons –  Memory leaks or similar unbounded resource sinks

10/16/13 8 © Adven9um Labs 2013

Near-‐Term Project Objec9ves

•  Improve security posture of dom0 –  Isolate the network stack –  Isolate the storage stack –  Isolate the device model (QEMU) –  Adapt the toolstack as necessary to support this configura9on

•  Apply well-‐known security principles –  Secure the weak links, separate privileges, do not share mechanisms

(disaggrega9on) –  Grant (and enforce) least privilege (hypervisor MAC) –  Defense-‐in-‐depth (aaesta9on)

•  Establish a baseline for future research and development

10/16/13 9 © Adven9um Labs 2013

Requirements

•  Defined a set of high-‐level requirements based on NIST 800.53 and CNSSI 1253: –  Categories: Confiden9ality, Integrity, Access Control, Accountability, Usability

•  Examples: –  Informa7on in Shared Resources: The system must prevent unauthorized and

unintended informa9on transfers via shared objects.. –  MAC Policies: The system must use mandatory access control policies to

control the flow of informa9on among processing domains. –  SoAware, Firmware, and Hardware Integrity: The system should support

integrity verifica9on tools to detect unauthorized changes to selected so]ware, firmware and hardware.

10/16/13 10 © Adven9um Labs 2013

Dom0 Disaggrega9on

10/16/13 11

Green Orange

Xen

QEM

U

Network

Storage

QEM

U

dom0 xapi XenStore

nic disk

Network

nic

netbk

Storage

disk

blktap blktap netbk QEMU QEMU

Secure weak links, separate mechanisms / privileges


Hypervisor Mandatory Access Controls

10/16/13 12

Green Orange

Xen

QEM

U

Network

Storage

QEM

U

dom0 xapi XenStore

nic disk

XSM

Network

nic

netbk

Storage

disk


Grant and enforce least privilege


Isn’t that overkill?

Proposal: Encrypt orange and green traffic

10/16/13 13

Green Orange

Xen

dom0 xapi XenStore

nic disk

netback blktap QEMU


Isn’t that overkill?

10/16/13 14

Green Orange

Xen


netback blktap QEMU

Compromise of dom0 via malicious tenant provides unfePered access to memory!


Isola9ng the Weak(est) Links

10/16/13 15

Green Orange

Xen

QEM

U

Network

Storage

QEM

U

dom0 xapi XenStore

nic disk

XSM

Network

nic

netbk

Storage

disk


If one tenant on Secure Server is compromised ...



10/16/13 16

Green Orange

Xen

QEM

U

Network

Storage

QEM

U

dom0 xapi XenStore

nic disk

XSM

Network

nic

netbk

Storage

disk


… the aPack is contained because the compromised tenant lacks privileges necessary to access co-‐tenant resources.



10/16/13 17

Green Orange

Xen

QEM

U

Network

Storage

QEM

U

dom0 xapi XenStore

nic disk

XSM

Network

nic

netbk

Storage

disk


Provides stronger data confiden7ality assurance as well


Dynamic Mandatory Access Controls

•  Can easily define a sta9c policy for mul9-‐tenant environments •  Not good enough

–  Tenants come and go –  Rela9onships evolve

•  How can we support a dynamic XSM policy?

10/16/13 18

Green Orange

Xen


netback blktap QEMU

Purple


TCB: Trust, but verify

•  Un9l now, assumed a trusted compu9ng base that includes Xen and the hardware

•  Don’t really intend to trust these things: –  Use measured launch to check integrity –  Use dynamic aaesta9on to verify run9me integrity

•  Especially important on servers

10/16/13 19 © Adven9um Labs 2013

SRTM, DRTM and Dynamic Aaesta9on

20

Know

ledge

(trust)

Know

ledge

(trust)

9me

Sta9c Root of Trust

Entropy leads to decay of knowledge of system state:

Core Root Trust • Hardware?

• Firmware? • Configura9on? • Drivers?

9me

Dynamic Root of Trust Gap Core Root Trust Dynamic

Launch Entry

Dynamically Launched Measured Environment (e.g., tboot)

10/16/13

AAer ini7al boot, knowledge of system state decays with 7me


Current Status

•  Started with XenServer 6.2 appliance –  Built network driver domain (working)

•  openvswitch or bridged networking

–  Built storage driver domain (working) •  iSCSI and SATA controller backend

–  Developing QEMU stub domain –  Defined MAC policy for a specific use case; verified, validated

•  Built tools for genera9ng sta9c policies based on high-‐level specifica9on

•  Challenges –  Deducing rela9onship between XAPI and Xen constructs –  Adap9ng toolstack to support disaggregated opera9on

10/16/13 21 © Adven9um Labs 2013

Roadmap

•  Secure inter-‐VMcommunica9on –  Survey: more than a dozen published mechanisms

•  More fine-‐grained disaggrega9on –  XenAPI, XenStore, domain builder –  Informed by prior work: Windsor, Xoar, Murray et al., Qubes, …

•  Service VM model –  Reduce footprint, maintain generality

•  Assess scalability –  Per tenant sharing

•  Iden9fy future R&D challenges –  Migra9on –  Server longevity –  High availability configura9ons

10/16/13 22 © Adven9um Labs 2013

Conclusion

•  Secure Server Mul9plexing –  Ensure data and processing are safe from co-‐tenants –  Ensure controls on informa9on separa9on and flow are sa9sfied

•  Building a baseline prototype –  By drawing on past dom0 disaggrega9on, MAC and aaesta9on R&D –  Targe9ng EOY 2013 release

•  Prototype can be used as a founda9on for future R&D –  Phase 2: iden9fy outstanding challenges and long-‐term R&D roadmap

•  Call for Par9cipa9on –  Collabora9ng via xs-‐devel mailing list –  Feedback welcome

10/16/13 23 © Adven9um Labs 2013