Secure Server Project. Xen Project Developer Summit 2013 Adven9um Labs Jason Sonnek

Transcription

1 Secure Server Project Xen Project Developer Summit 2013 Adven9um Labs Jason Sonnek 1

2 Outline I. Mo9va9on, Objec9ves II. Threat Landscape III. Design IV. Status V. Roadmap 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 3

4 Objec9ve Cloud Management Green Orange SecureServe 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 Xen 4

5 Current State Green Orange netback xapi XenStore dom0 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. 5

6 Current State Green Compliance Orange netback xapi XenStore dom0 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 Xen 6

7 Threat Landscape Recent ( ) 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 3 "drivers" (all in reference to backends) 2 xenstore 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 8

9 Near- Term Project Objec9ves Improve security posture of dom0 Isolate the network stack Isolate the storage stack Isolate the device model () 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 9

10 Requirements Defined a set of high- level requirements based on NIST 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

11 Dom0 Disaggrega9on Green Orange Network Storage Network Storage netbk netbk xapi XenStore dom0 Xen Secure weak links, separate mechanisms / privileges 11

12 Hypervisor Mandatory Access Controls Green Orange Network Storage Network Storage netbk netbk xapi XenStore dom0 XSM Xen Grant and enforce least privilege 12

13 Isn t that overkill? Green Orange xapi XenStore dom0 netback Xen Proposal: Encrypt orange and green traffic 13

14 Isn t that overkill? Green Orange xapi XenStore dom0 netback Xen Compromise of dom0 via malicious tenant provides unfepered access to memory! 14

15 Isola9ng the Weak(est) Links Green Orange Network Storage Network Storage netbk netbk xapi XenStore dom0 XSM Xen If one tenant on Secure Server is compromised... 15

16 Isola9ng the Weak(est) Links Green Orange Network Storage Network Storage netbk netbk xapi XenStore dom0 XSM Xen the apack is contained because the compromised tenant lacks privileges necessary to access co- tenant resources. 16

17 Isola9ng the Weak(est) Links Green Orange Network Storage Network Storage netbk netbk xapi XenStore dom0 XSM Xen Provides stronger data confiden7ality assurance as well 17

18 Dynamic Mandatory Access Controls Green Purple Orange netback xapi XenStore dom0 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? 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 19

20 SRTM, DRTM and Dynamic Aaesta9on Knowledge (trust) Knowledge (trust) Core Root Trust Core Root Trust Gap Dynamic Launch Entry Dynamically Launched Measured Environment (e.g., tboot) Sta9c Root of Trust Entropy leads to decay of Hardware? knowledge of system state: Firmware? Configura9on? Drivers? 9me Dynamic Root of Trust 9me AAer ini7al boot, knowledge of system state decays with 7me 10/16/13 Adven9um Labs

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 stub domain Defined MAC policy for a specific use case; verified, validated Challenges Built tools for genera9ng sta9c policies based on high- level specifica9on Deducing rela9onship between XAPI and Xen constructs Adap9ng toolstack to support disaggregated opera9on 21

22 Roadmap Secure inter- VMcommua9on 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 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 23