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.

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

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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?