In-Guest Mechanisms to
Strengthen Guest Separation
XenSummit 2013
Philip Tricca
<philip.tricca@citrix.com>
Background
• Xen does security well
– Strong isolation using
hardware
– Doesn’t try to do too much

• Offload complexity t...
User-space mechanisms
• Some work we’ve done
– Strengthen separation
between guest specific
resources in dom0
– sVirt impl...
Caution
• Will move around a lot
– Architectures that touch all
aspects of virtualization
– High-level concept to low-leve...
Diagrams & Conventions
• Colors
– Green for ‘platform’ stuff (Xen
+ VMs)
– NDVM = Network Driver VM
– Blue & orange for ‘g...
sVirt
• Separation between
guests relies on
mechanisms in dom0
/ Linux
– QEMU instances
backing guests
– Run with ‘root’ p...
sVirt
• Goals
– Separate QEMU
instances
– Limit access to
appropriate resources

qemu1
blktap_t:cXX

qemu_t:cXX
dom0

• Im...
sVirt Details
• Specification from
SELinux community
– Not a new thing: 2008
– http://selinuxproject.org/p
age/Svirt_requi...
Multi-Tennant Orchestration
• On-going work in
XenClient XT
• Goals
– Provide separate orgs
management
mechanisms on a sin...
Multi-tenant Orchestration
• Similar issue with
XSM & guest VMs
– Guest VMs use a
single XSM type
– See domHVM_t
‘self’ ru...
Multi-tenant Orchestration
• VM dedicated to
orchestration
– Represents the interests /
actions of a single org
– Bootstra...
Inter-VM Communication
• Short discussion on xen- • Proposed new approach
devel back in June
– Negotiate shared pages
– ht...
IVC policy model
• policy semantics of V4V were
desirable
– First-class xen object == clear
XSM policy
– Send / receive se...
Policy Semantics
• Flexible, loosely-coupled,
disaggregated systems
– Good engineering practices
enable good security
– Ma...
Upcoming SlideShare
Loading in...5
×

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

1,584

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
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,584
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
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?
  1. Gostou de algum slide específico?

    Recortar slides é uma maneira fácil de colecionar informações para acessar mais tarde.

×