XPDS13: SecureServe - A Multi-level Secure Server Virtualization Platform on Xen - Jason Sonnek, Adventium Labs
•
2 gefällt mir•2,808 views
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.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (15)
Andere mochten auch
Andere mochten auch (7)
Ähnlich wie XPDS13: SecureServe - A Multi-level Secure Server Virtualization Platform on Xen - Jason Sonnek, Adventium Labs
Ähnlich wie XPDS13: SecureServe - A Multi-level Secure Server Virtualization Platform on Xen - Jason Sonnek, Adventium Labs (20)
Mehr von The Linux Foundation
Mehr von The Linux Foundation (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
XPDS13: SecureServe - A Multi-level Secure Server Virtualization Platform on Xen - Jason Sonnek, Adventium Labs
- 1. Secure Server Project Xen Project Developer Summit 2013 Adven9um Labs Jason Sonnek 10/16/13 © Adven9um Labs 2013 1
- 2. Outline I. Mo9va9on, Objec9ves II. Threat Landscape III. Design IV. Status V. Roadmap 10/16/13 © Adven9um Labs 2013 2
- 3. 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 © Adven9um Labs 2013 3
- 4. Objec9ve Cloud Management Green Orange SecureServe Xen • SecureServe ideal – – – – – 10/16/13 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 © Adven9um Labs 2013 4
- 5. Current State Green QEMU xapi XenStore Orange dom0 netback blktap nic disk Xen • 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 © Adven9um Labs 2013 5
- 6. Current State Green QEMU xapi Orange Compliance XenStore dom0 netback blktap nic disk Xen • 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 © Adven9um Labs 2013 6
- 7. 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 © Adven9um Labs 2013 7
- 8. 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 © Adven9um Labs 2013 8
- 9. 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 © Adven9um Labs 2013 9
- 10. 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 © Adven9um Labs 2013 10
- 11. Dom0 Disaggrega9on nic disk xapi QEMU netbk blktap nic XenStore Storage QEMU QEMU Network Storage blktap QEMU Network netbk Orange Green disk dom0 Xen Secure weak links, separate mechanisms / privileges 10/16/13 © Adven9um Labs 2013 11
- 12. Hypervisor Mandatory Access Controls nic disk xapi XSM QEMU netbk blktap nic XenStore Storage QEMU QEMU Network Storage blktap QEMU Network netbk Orange Green disk dom0 Xen Grant and enforce least privilege 10/16/13 © Adven9um Labs 2013 12
- 13. Isn’t that overkill? Green QEMU xapi Orange dom0 XenStore netback blktap nic disk Xen Proposal: Encrypt orange and green traffic 10/16/13 © Adven9um Labs 2013 13
- 14. Isn’t that overkill? Green QEMU xapi Orange dom0 XenStore netback blktap nic disk Xen Compromise of dom0 via malicious tenant provides unfePered access to memory! 10/16/13 © Adven9um Labs 2013 14
- 15. Isola9ng the Weak(est) Links nic disk xapi XSM QEMU netbk blktap nic XenStore Storage QEMU QEMU Network Storage blktap QEMU Network netbk Orange Green disk dom0 Xen If one tenant on Secure Server is compromised ... 10/16/13 © Adven9um Labs 2013 15
- 16. Isola9ng the Weak(est) Links nic disk xapi XSM QEMU netbk blktap nic XenStore Storage QEMU QEMU Network Storage blktap QEMU Network netbk Orange Green disk dom0 Xen … the aPack is contained because the compromised tenant lacks privileges necessary to access co-‐tenant resources. 10/16/13 © Adven9um Labs 2013 16
- 17. Isola9ng the Weak(est) Links nic disk xapi XSM QEMU netbk blktap nic XenStore Storage QEMU QEMU Network Storage blktap QEMU Network netbk Orange Green disk dom0 Xen Provides stronger data confiden7ality assurance as well 10/16/13 © Adven9um Labs 2013 17
- 18. Dynamic Mandatory Access Controls Purple Green QEMU xapi XenStore Orange dom0 netback blktap nic disk Xen • 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 © Adven9um Labs 2013 18
- 19. 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 © Adven9um Labs 2013 19
- 20. Knowledge (trust) Knowledge (trust) SRTM, DRTM and Dynamic Aaesta9on Core Root Trust Sta9c Root of Trust Entropy leads to decay of • Hardware? knowledge of system state: • Firmware? • Configura9on? • Drivers? 9me Core Root Trust Gap Dynamic Launch Entry Dynamically Launched Measured Environment (e.g., tboot) Dynamic Root of Trust 9me AAer ini7al boot, knowledge of system state decays with 7me 10/16/13 © Adven9um Labs 2013 20
- 21. 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 © Adven9um Labs 2013 21
- 22. 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 © Adven9um Labs 2013 22
- 23. 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 © Adven9um Labs 2013 23