XPDS13: In-Guest Mechanism to Strengthen Guest Separation - Philip Tricca, Citrix


Published on

Terms related to security like 'disaggregation' and 'stubdom' have found their way into the standard Xen vernacular. Implementations of these architectures still require heavy lifting but examples have made their way into both the open source and commercial products. In this talk Philip presents a lesser known but complimentary method to confine QEMU processes using SELinux type enforcement. This architecture alone is interesting but Philip believes its utility extends beyond QEMU and SELinux. Future problems like inter-VM communication mechanisms hold unique challenges with regard to access control and policy semantics. Philip will argue that an approach influenced by sVirt and user-space object managers will be useful here. As always, attendees should expect tangents into abstract topics like the nature of trust and the utopic world that strong security mechanisms will bring about.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

XPDS13: In-Guest Mechanism to Strengthen Guest Separation - Philip Tricca, Citrix

  1. 1. In-Guest Mechanisms to Strengthen Guest Separation XenSummit 2013 Philip Tricca <philip.tricca@citrix.com>
  2. 2. Background • Xen does security well – Strong isolation using hardware – Doesn’t try to do too much • Offload complexity to VMs / userspace – Drivers / QEMU / inter-VM communication (IVC) – Keeps Xen small – Separation now requires guest cooperation • Value is added when VMs communicate / cooperate provided that … – Separation is preserved & mechanisms are strong – Sensible policy semantics are preserved – By “policy” I mean FLASK / XSM / SELinux
  3. 3. User-space mechanisms • Some work we’ve done – Strengthen separation between guest specific resources in dom0 – sVirt implementation on XenClient XT – Separate QEMU instances • Some work we’re doing – Strengthen separation between guest VMs – Multi-tenant orchestration of mutually distrusting orgs – sVirt for management • Apply these architectures to new work – Inter-VM communication (IVC) – Policy semantics in V4V in XenClient XT – IVC using front/back driver model
  4. 4. Caution • Will move around a lot – Architectures that touch all aspects of virtualization – High-level concept to low-level implementation – Ask questions • References provided – Time constraints – Please engage ‘off-line’
  5. 5. Diagrams & Conventions • Colors – Green for ‘platform’ stuff (Xen + VMs) – NDVM = Network Driver VM – Blue & orange for ‘guest’ VMs vm2A A vm1 A vm0 process vm2A A vm1 B vm0 A • Boxes – VMs are above ‘Xen’ – Processes are inside VMs – Not drawn to scale, may shrink / grow • Arrows denote binding or interaction • Security boundaries: something_t is a FLASK type (SELinux / XSM) domA_t dom0 processA_t domB_t processB dom0 vm0A NDVM processB_t Xen Hardware vm0B
  6. 6. sVirt • Separation between guests relies on mechanisms in dom0 / Linux – QEMU instances backing guests – Run with ‘root’ perms – Add SELinux but policy granularity is still wrong – qemu_t r/w blktap_t qemu1 blktap_t dom0 vm1 qemu_t qemu0 Xen Hardware vm0
  7. 7. sVirt • Goals – Separate QEMU instances – Limit access to appropriate resources qemu1 blktap_t:cXX qemu_t:cXX dom0 • Implementation – Assign random MCS category to QEMU & relevant resources – Ensure category uniqueness vm1 qemu0 blktap_t:cYY qemu_t:cYY Xen Hardware vm0
  8. 8. sVirt Details • Specification from SELinux community – Not a new thing: 2008 – http://selinuxproject.org/p age/Svirt_requirements_v1 .0 – libvirt security driver • XenClient XT implementation – Minimally invasive – libvirt not an option – Binary interposed between toolstack and QEMU • SELinux constraint / categories – Sets are cool – http://twobit.us/blog/2011/07/u nderstanding-multi-levelsecurity-part-3/ • OpenSource – Code: https://github.com/flihp/svirtinterpose – Analysis: http://twobit.us/blog/2012/02/s virt-in-xenclient/ – Works on Xen OSS (requires some tweaks) – Interest from upstream?
  9. 9. Multi-Tennant Orchestration • On-going work in XenClient XT • Goals – Provide separate orgs management mechanisms on a single platform – Maintain mutual distrust between orgs • Increasingly relevant – Multiple virtualization mgmt stacks – Security concerns in larger ‘cloud’ context – BYOD / multi-personality devices • Who owns the device? • Which interests does the device represent?
  10. 10. Multi-tenant Orchestration • Similar issue with XSM & guest VMs – Guest VMs use a single XSM type – See domHVM_t ‘self’ rules – Implications when we consider groups of VMs belonging to different orgs domHVM_t hvm_guest_t vm2A A vm1 A vm0 domHVM_t dom0 vm2B B vm1 B vm0 NDVM Xen Hardware
  11. 11. Multi-tenant Orchestration • VM dedicated to orchestration – Represents the interests / actions of a single org – Bootstrapping non-trivial – Unique category to represent each mgmt realm – Prevent cross realm actions • sVirt architecture applied to similar problem – Work on-going domHVM_t:cYY mgmt_t:cYY mgmtA vm2A A vm1 A vm0 mgmt_t:cXX domHVM_t:cXX mgmtB vm2B B vm1 B vm0 NDVM Xen Hardware
  12. 12. Inter-VM Communication • Short discussion on xen- • Proposed new approach devel back in June – Negotiate shared pages – http://lists.xen.org/archi ves/html/xendevel/201306/msg01123.html – Alternative to V4V from XenClient is imminent through rendezvous service – Possibly a 3rd party daemon – Possibly through xenstore • Doing this with existing mechanisms is a ‘very good thing’
  13. 13. IVC policy model • policy semantics of V4V were desirable – First-class xen object == clear XSM policy – Send / receive semantics – Communication channels between VMs were clear • Policy for new IVC mechanism – Coms channel reflected in XSM for grant mechanism – Interesting possibility to extend XSM to vsock connections to create higher-level semantics • Feasibility? – Caution against introducing new / competing policy mechanisms – Seems connection mgmt will land in XenStore anyways – XenStore perms sufficient? – User-space object manager? – BOF?
  14. 14. Policy Semantics • Flexible, loosely-coupled, disaggregated systems – Good engineering practices enable good security – Make changes easier – Make dependencies obvious – Clear interfaces • Hazards w/r to separation / policy goals can be subtle • Consider attack scenarios w/r to – Enforcement mechanisms – Desired policy semantics • What will policy look like after addition of new mechanism?