Upload
xen-project
View
1.127
Download
0
Embed Size (px)
DESCRIPTION
Due to the rapid shift toward cloud computing, virtual desktop infrastructure (VDI) and thin client computing, many organizations in the government desire a high assurance, multi-level secure server virtualization platform that is low-cost, open and enterprise ready. In this presentation, Jason Sonnek will present SecureServe, a recently launched effort to develop such a platform by building on the open-source Citrix XenServer. The SecureServe project will draw upon research in a number of areas, including dom0 disaggregation, Xen Security Modules mandatory access controls and static/dynamic attestation. In this presentation, Jason will describe the project objectives and requirements, the project's relation to Citrix XenClient XT and XenServer Windsor, current development status and plans for moving forward.
Citation preview
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
© Adven9um Labs 2013
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
dom0 xapi XenStore nic disk
netback blktap QEMU
Compliance
© Adven9um Labs 2013
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
© Adven9um Labs 2013
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
blktap blktap netbk QEMU QEMU
Grant and enforce least privilege
© Adven9um Labs 2013
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
© Adven9um Labs 2013
Isn’t that overkill?
10/16/13 14
Green Orange
Xen
dom0 xapi XenStore nic disk
netback blktap QEMU
Compromise of dom0 via malicious tenant provides unfePered access to memory!
© Adven9um Labs 2013
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
blktap blktap netbk QEMU QEMU
If one tenant on Secure Server is compromised ...
© Adven9um Labs 2013
Isola9ng the Weak(est) Links
10/16/13 16
Green Orange
Xen
QEM
U
Network
Storage
QEM
U
dom0 xapi XenStore
nic disk
XSM
Network
nic
netbk
Storage
disk
blktap blktap netbk QEMU QEMU
… the aPack is contained because the compromised tenant lacks privileges necessary to access co-‐tenant resources.
© Adven9um Labs 2013
Isola9ng the Weak(est) Links
10/16/13 17
Green Orange
Xen
QEM
U
Network
Storage
QEM
U
dom0 xapi XenStore
nic disk
XSM
Network
nic
netbk
Storage
disk
blktap blktap netbk QEMU QEMU
Provides stronger data confiden7ality assurance as well
© Adven9um Labs 2013
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
dom0 xapi XenStore nic disk
netback blktap QEMU
Purple
© Adven9um Labs 2013
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
© Adven9um Labs 2013
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