In-Guest Mechanisms to Strengthen Guest Separation XenSummit 2013 - PowerPoint PPT Presentation

In-Guest Mechanisms to Strengthen Guest Separation XenSummit 2013 Philip Tricca <philip.tricca@citrix.com>

Background • Xen does security well • Value is added when VMs communicate / cooperate – Strong isolation using hardware provided that … – Doesn’t try to do too much – Separation is preserved & • Offload complexity to mechanisms are strong – Sensible policy semantics VMs / userspace are preserved – Drivers / QEMU / inter-VM – By “policy” I mean FLASK / communication (IVC) XSM / SELinux – Keeps Xen small – Separation now requires guest cooperation

User-space mechanisms • Some work we’ve done • Apply these architectures to new work – Strengthen separation between guest specific – Inter-VM communication resources in dom0 (IVC) – sVirt implementation on – Policy semantics in V4V in XenClient XT XenClient XT – Separate QEMU instances – IVC using front/back driver • Some work we’re doing model – Strengthen separation between guest VMs – Multi-tenant orchestration of mutually distrusting orgs – sVirt for management

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’

Diagrams & Conventions • Colors – Green for ‘platform’ stuff ( Xen + VMs) A A vm 2 vm 2 A A vm 1 vm 1 – NDVM = Network Driver VM A B vm 0 vm 0 – Blue & orange for ‘guest’ VMs process A A vm 0 • Boxes – VMs are above ‘ Xen ’ domA_t processA_t domB_t – Processes are inside VMs dom0 – Not drawn to scale, may shrink / grow • Arrows denote binding or process B B vm 0 interaction • Security boundaries: dom0 NDVM something_t is a FLASK type processB_t (SELinux / XSM) Xen Hardware

sVirt • Separation between guests relies on mechanisms in dom0 qemu1 vm1 / Linux – QEMU instances blktap_t qemu_t dom0 backing guests – Run with ‘root’ perms vm0 qemu0 – Add SELinux but policy granularity is still wrong – qemu_t r/w blktap_t Xen Hardware

sVirt • Goals – Separate QEMU instances qemu1 vm1 – Limit access to blktap_t:cXX qemu_t:cXX appropriate resources dom0 • Implementation – Assign random MCS qemu0 vm0 category to QEMU & relevant resources blktap_t:cYY qemu_t:cYY – Ensure category uniqueness Xen Hardware

sVirt Details • Specification from • SELinux constraint / categories SELinux community – Sets are cool – Not a new thing: 2008 – http://twobit.us/blog/2011/07/u – http://selinuxproject.org/p nderstanding-multi-level- security-part-3/ age/Svirt_requirements_v1 .0 • OpenSource – libvirt security driver – Code: • XenClient XT https://github.com/flihp/svirt- interpose implementation – Analysis: – Minimally invasive http://twobit.us/blog/2012/02/s – libvirt not an option virt-in-xenclient/ – Binary interposed between – Works on Xen OSS (requires toolstack and QEMU some tweaks) – Interest from upstream?

Multi-Tennant Orchestration • On-going work in • Increasingly relevant XenClient XT – Multiple virtualization mgmt stacks • Goals – Security concerns in – Provide separate orgs larger ‘cloud’ context management – BYOD / multi-personality mechanisms on a single devices platform • Who owns the device? – Maintain mutual distrust between orgs • Which interests does the device represent?

Multi-tenant Orchestration • Similar issue with domHVM_t hvm_guest_t XSM & guest VMs A vm 2 A vm 1 A vm 0 – Guest VMs use a single XSM type – See domHVM_t domHVM_t dom0 ‘self’ rules – Implications when B vm 2 B vm 1 we consider groups B vm 0 of VMs belonging to NDVM different orgs Xen Hardware

Multi-tenant Orchestration • VM dedicated to domHVM_t:cYY mgmt_t:cYY orchestration – Represents the interests / mgmt A A vm 2 A vm 1 actions of a single org A vm 0 – Bootstrapping non-trivial – Unique category to mgmt_t:cXX represent each mgmt realm domHVM_t:cXX mgmt B – Prevent cross realm B actions vm 2 B vm 1 B vm 0 • sVirt architecture NDVM applied to similar problem Xen – Work on-going Hardware

Inter-VM Communication • Short discussion on xen- • Proposed new approach devel back in June – Negotiate shared pages – http://lists.xen.org/archi through rendezvous service ves/html/xen- – Possibly a 3 rd party devel/2013- 06/msg01123.html daemon – Alternative to V4V from – Possibly through XenClient is imminent xenstore • Doing this with existing mechanisms is a ‘very good thing’

IVC policy model • • Feasibility? policy semantics of V4V were desirable – Caution against introducing – First-class xen object == clear new / competing policy XSM policy mechanisms – Send / receive semantics – Seems connection mgmt – Communication channels will land in XenStore between VMs were clear anyways • Policy for new IVC mechanism – XenStore perms sufficient? – Coms channel reflected in XSM – User-space object for grant mechanism – Interesting possibility to extend manager? XSM to vsock connections to – BOF? create higher-level semantics

Policy Semantics • Flexible, loosely-coupled, • Consider attack scenarios disaggregated systems w/r to – Good engineering practices – Enforcement mechanisms enable good security – Desired policy semantics – Make changes easier • What will policy look like – Make dependencies after addition of new obvious mechanism? – Clear interfaces • Hazards w/r to separation / policy goals can be subtle