Upload
russell-pavlicek
View
1.824
Download
1
Embed Size (px)
DESCRIPTION
Exploring some of the important security options available in the Xen Hypervisor.
Citation preview
Introduction Network path Bootloader Device model Xen Conclusion
Securing Your Cloud with Xen Project’sAdvanced Security Features
Russell Pavlicek, Xen Project Evangelist
CloudOpen North America 2013
Introduction Network path Bootloader Device model Xen Conclusion
Who is the Old, Fat Geek Up Front?
I Xen Project Evangelist
I Employed by Citrix, focused entirely on the Xen Project
I History with Open Source begins in 1997
I Former columnist with Infoworld, Processor magazines
I Former panelist on The Linux Show webcast, repeat guest onThe Linux Link Tech Show
I Over 150 pieces published, plus one book on Open Sourcedevelopment and several blogs
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 2 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Introduction: Xen Project and Security
I Xen Project is an enterprise-grade Type I hypervisor
I Built for the Cloud before it was called the CloudI A number of advanced security features
I Driver Domains, Stub Domains, FLASK, and more
I Most of them are not (or cannot) be turned on by default
I Although they are simple to use, sometimes they can appearto be complicated
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 3 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Presentation Goals
I Introduce you to key Xen Project Security Tools
I Discuss some key Xen security features
I Get you started in the right direction toward securing yourXen installation
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 4 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Presentation Outline
I A few thoughts on the problem of securing the Cloud
I Overview of the Xen architecture
I Brief introduction to principles of security analysisI Consider some attack surfaces and Xen features we can use to
mitigate them:I Driver DomainsI PVgrubI Stub DomainsI Paravirtualization (PV) mode vs Hardware Virtualization
(HVM) modeI FLASK example policy
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 5 / 32
Introduction Network path Bootloader Device model Xen Conclusion
The Cloud Security Conundrum
I Security: The 800 pound gorilla of the Cloud worldI Nothing generates more fear in specific, and FUD in generalI Probably the single greatest barrier to Cloud adoption
I Immediately behind it is the inability to get out of a 20thcentury IT mindset (i.e., ”Change is Bad”)
I The good news: we don’t need to fear it – we just need tosolve it
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 6 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Cloud Security: New Visibility to Old Problem
I Security has always been an issue
I Putting a truly secure system in the open does not reduce itssecurity, just increases the frequency of attack
I Unfortunately, system security behind the firewall has notalways been comprehensive
I Having solutions in Clouds forces us to solve the securityissues we should have already solved
I Security through obscurity is no longer sufficient
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 7 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Security by Design, not by Wishful Thinking
I Security by Wishful Thinking is Officially DeadI Merely hoping that your firewall holds off the marauding
hordes is NOT good enoughI Addressing security in one area while ignoring others is NOT
good enoughI Saying, ”We’ve never had a problem before” is NOT good
enough
I Comprehensive security starts with designI It needs to planned and carefully thought throughI It needs to be implemented at multiple levelsI It needs components which are themselves securable
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 8 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Xen Project: Security by Design
I Xen Project was designed for Clouds before the term ”Cloud”was coined in the industry
I Designers foresaw the day of an ”infrastructure for wide-areadistributed computing” which we now call ”the Cloud”
I http://www.cl.cam.ac.uk/research/srg/netos/xeno/publications.html
I Xen is designed to thwart attacks from many attack vectors,using different defensive techniques
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 9 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Xen Architecture: A Basic Picture
Xen Hypervisor
Hardware
device model(qemu)
toolstack
dom 0
HardwareDrivers
I/O Devices CPU Memory
Paravirtualized(PV)
Domain
Fully Virtualized
(HVM)Domainnetback
blkbacknetfrontblkfront
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 10 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Security Overview
I Threat Models:I Attacker can access networkI Attacker controls one Guest VM
I Security considerations to evaluate:I How much code is accessible?I What is the interface like? (e.g., pointers vs scalars)I Defense-in-depth
I Then combine security tactics to secure the installationI There is no single ”magic bullet”I Individual tactics reduce danger; combined tactics go even
farther
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 11 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Example System, for our Discussion
I Hardware setupI Two networks: one Control network, one Guest networkI IOMMU with interrupt remapping (AMD or Intel VT-d v2) to
allow for full Hardware Virtualization (HVM)
I Default configurationI Network drivers in the Control Domain (aka ”Domain 0” or
just ”Dom0”)I Paravirtualized (PV) guests using PyGrub (grub-like boot
utility within context of Guest Domain)I Hardware Virtualized (HVM) guests using Qemu (as the device
model) running in the Control Domain
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 12 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Attack surface: Network path
Xen Hypervisor
Hardware
toolstackdom 0
NICDriver
Control NIC
RogueDomain
netback netfront
Guest NIC
bridgeiptables
Domain
netfront
I Where might an exploit focus?I Bugs in hardware driverI Bugs in bridging / filteringI Bugs in netback (via the ring protocol)
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 13 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Attack surface: Network path
Xen Hypervisor
Hardware
toolstackdom 0
NICDriver
Control NIC
RogueDomain
netback netfront
Guest NIC
bridgeiptables
Domain
netfront
I What could a successful exploit yield?I Control of Domain 0 kernelI Pretty much control of the whole system
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 14 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Security feature: Driver Domains
Xen Hypervisor
Hardware
toolstack
dom 0
NICDriver
Control NIC
RogueDomain
netback netfront
Guest NIC
bridgeiptables
Domain
netfront
NICDriver
Driver Domain
I What is a Driver Domain?I Unprivileged VM which drives hardware, provides access to
guests
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 15 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Security feature: Driver Domains
Xen Hypervisor
Hardware
toolstack
dom 0
NICDriver
Control NIC
RogueDomain
netback netfront
Guest NIC
bridgeiptables
Domain
netfront
NICDriver
Driver Domain
I Now a successful exploit could yield:I Control of the Driver Domain (PV hypercall interface)I Control of that guest’s network trafficI Control of NICI An opportunity to attack netfront of other guests
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 16 / 32
Introduction Network path Bootloader Device model Xen Conclusion
HowTo: Driver Domains
I Create a VM with appropriate driversI Use any distribution suitable as a Control Domain
I Install the Xen-related hotplug scriptsI Just installing the Xen tools in the VM is usually good enough
I Give the VM access to the physical NIC with PCI pass-throughI Configure the network topology in the Driver domain
I Just like you would for the Control Domain
I Configure the guest Virtual Network Interface (vif) to use thenew domain ID
I Add backend=domnet to vif declaration
vif = [ ’type=pv, bridge=xenbr0, backend=domnet’ ]
I http://wiki.xenproject.org/wiki/Driver Domain
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 17 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Attack surface: PyGrub
Xen Hypervisor
toolstackdom 0
Paravirtualized(PV)
Domain
domainbuilder
pygrub
guestdisk
I What is PyGrub?I grub implementation for PV guestsI Python program running in Control DomainI Reads guest filesystem, parses grub.conf, shows menuI Passes resulting kernel image to domain builder
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 18 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Attack surface: PyGrub
Xen Hypervisor
toolstackdom 0
Paravirtualized(PV)
Domain
domainbuilder
pygrub
guestdisk
I Where might an exploit focus?I Bugs in file system parserI Bugs in menu parserI Bugs in domain builder
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 19 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Attack surface: PyGrub
Xen Hypervisor
toolstackdom 0
Paravirtualized(PV)
Domain
domainbuilder
pygrub
guestdisk
kernel
I What could a successful exploit yield?I Control of Domain 0 user spaceI Pretty much control of the whole system
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 20 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Security practice: Fixed kernels
Xen Hypervisor
toolstackdom 0
Paravirtualized(PV)
Domain
domainbuilder
kernelimage
guestdisk
I What is a fixed kernel?I Passing a known-good kernel from Control Domain
I Removes attacker avenue to domain builder
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 21 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Security practice: Fixed kernels
Xen Hypervisor
toolstackdom 0
Paravirtualized(PV)
Domain
domainbuilder
kernelimage
guestdisk
I DisadvantagesI Host admin must keep up with kernel updatesI Guest admin can’t pass kernel parameters, custom kernels,
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 22 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Security feature: PVgrub
Xen Hypervisor
toolstackdom 0
domainbuilder
guestdisk
MiniOS
pvgrub
I What is PVgrub?I MiniOS + PV port of grub running in a guest contextI PV equivalent of HVM “BIOS + grub”
I Now a successful exploit could yield:I Control of the attacked guest domain alone
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 23 / 32
Introduction Network path Bootloader Device model Xen Conclusion
HowTo: PVgrub
I Make sure that you have the PVgrub imageI pvgrub-$ARCH.gzI Normally lives in /usr/lib/xen/bootI Included in Fedora Xen packagesI Debian-based: need to build yourself
I Use appropriate PVgrub as bootloader in guest configuration
kernel="/usr/lib/xen/boot/pvgrub-x86_32.gz"
I http://wiki.xenproject.org/wiki/Pvgrub
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 24 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Attack surface: Device model (Qemu)
I Where might an exploit focus?I Bugs in NIC emulator parsing packetsI Bugs in emulation of virtual devices
I What could a successful exploit yield?I Control Domain privileged userspaceI Pretty much control of the whole system
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 25 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Security feature: Qemu stub domains
I What is a stub domain?I Stub domain: a small “service” domain running just one
applicationI Qemu stub domain: run each Qemu in its own domain
I What could a successful exploit yield?I Control only of the stub domain VM (which, if FLASK is
employed, is a relatively small universe)I You need to devise another attack entirely to do anything
more significant
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 26 / 32
Introduction Network path Bootloader Device model Xen Conclusion
HowTo: Qemu stub domains
I Make sure that you have the PVgrub image:I ioemu-$ARCH.gzI Normally lives in /usr/lib/xen/bootI Included in Fedora Xen packagesI On Debian (and offshoots), you will need to build it yourself
I Specify stub domains in your guest config
device_model_stubdomain_override = 1
I http://wiki.xenproject.org/wiki/Device Model Stub Domains
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 27 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Attack Surface: Xen Hypervisor itself
I Where might an exploit focus?I On Paravirtualized (PV) Guests:
I PV Hypercalls
I On full Hardware Virtualized (HVM) Guests:I HVM hypercalls (Subset of PV hypercalls)I Instruction emulation (MMIO, shadow pagetables)I Emulated platform devices: APIC, HPET, PITI Nested virtualization
I Security practice: Use PV VMs whenever possible
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 28 / 32
Introduction Network path Bootloader Device model Xen Conclusion
Security feature: FLASK example policy
I What is FLASK?I Xen Security Module (XSM): Xen equivalent of LSMI FLASK: Framework for XSM developed by NSAI Xen equivalent of SELinuxI Uses same concepts and tools as SELinuxI Allows a policy to restrict hypercalls
I What can FLASK do?I Basic: Restricts hypercalls to those needed by a particular
guestI Advanced: Allows more fine-grained granting of privileges
I FLASK example policyI This contains example roles for the Control Domain (dom0),
User/Guest Domain(domU), stub domains, driver domains,etc.
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 29 / 32
Introduction Network path Bootloader Device model Xen Conclusion
HowTo: Use the example FLASK policy
I Build Xen with XSM enabled
I Build the example policyI Add the appropriate label to guest config files
I seclabel=[foo]I stubdom label=[foo]
I Make sure you TEST the example policy in your environmentBEFORE putting it into production!
I NOTE: As an example policy, it is not as rigorously tested asother parts of Xen during release, and it may not be suitableas-is if you are doing unusual things
I http://wiki.xenproject.org/wiki/Xen Security Modules : XSM-FLASK
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 30 / 32
Introduction Network path Bootloader Device model Xen Conclusion
ARM: Right solution for security
I Stays in ARM Hypervisor ModeI The ARM architecture has separate Hypervisor and Kernel
modesI Because Xen’s architecture maps so well to the ARM
architecture, Xen never has to use Kernel modeI Other hypervisors have to flip back and forth between modesI If a hypervisor has to enter Kernel mode, it loses the security
of running in a privileged mode, isolated from the rest of thesystem
I This is a non-issue with the Xen Hypervisor on ARM
I Does not need to use device emulationI No emulation means a smaller attack surface for bad guys
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 31 / 32
Introduction Network path Bootloader Device model Xen Conclusion
For More Information...
Details at http://wiki.xenproject.org/wiki/Securing Xen
Thanks to George Dunlap for supplying much of the informationpresented here, and Stefano Stabellini for ARM information
Check out our blog: http://blog.xenproject.org/
Contact me at [email protected]
——————————–
Thank You!
CloudOpen North America 2013 Securing Your Cloud with Xen Project’s Advanced Security Features 32 / 32