Upload
the-linux-foundation
View
1.080
Download
4
Tags:
Embed Size (px)
DESCRIPTION
Released as Open Source Software (OSS) in June 2014, OpenXT is a collection of hardened Linux VMs configured to provide a user facing Xen platform for client devices. This default configuration was mostly static, applying some disaggregation techniques to segregate system components based on a general threat analysis. The goals embodied in this code base up to its release produced a one-size-fits-most configuration with extensibility in specific areas to encapsulate 3rd party value-add. With a community now forming around OpenXT we must come to terms with the limitations of the this approach. In this talk Philip will define what OpenXT is and in this definition, show that OpenXT can meet the varied needs of the security and virtualization community through the construction of a toolkit for the configurable disaggregation of a Xen platform.
Citation preview
Background• Work on Xen dom0 disaggregation goes back 10 years
– Fault-tolerance, Performance & Scalability– Security and scalability– Relevant papers collected @ http://openxt.org/references.html
• Talks about Xen and Disaggregation / Security @ XenSummit– Client Virtualization Framework, Ze'ev Maor @ Neocleus, 2009– Disaggregated Xen, Patrick Colp @ University of British Columbia, 2011– XenClient XT, Gianluca Guida @ Citrix, 2012– Windsor / XCP disaggregation, James Bulpin @ Citrix, 2012– Secure Server Project, Jason Sonnek @ Adventium, 2013– XenClient XT, Phililp Tricca (me) @ Citrix, 2013
• LinuxCon– Securing your Xen-Based Cloud, George Dunlap @ Citrix, 2013– Security in the Cloud: Containers, KVM, and Xen, George Dunlap @
Citrix, 2014
Terminology
• Guest VM: user facing VM (windows / linux)• Service VM
– as defined in Xoar paper– Virtual machine providing ‘services’ to guests– Can provide duplication for scalability– Can perform security sensitive function for isolation
• APIs– Well defined interfaces between components– Xen front/back device model (block, network)– Platform API like input / ouput plugin architecture– DBus over Inter-VM communication API– Application level discovery, proxies, interposition / layer 7 etc
Disaggregation: Scalability / Security
bump-in-
the-wire
Guest
VM 1
Device Isolation VM
bump-in-
the-wire
Guest
VM 2
• Model described in the earlier literature
• Implemented in Qubes, OpenXT, XCP
• Scalability / security by removing dom0 from I/O path
• Value-add @ bump-in-the-wire (encryption, introspection)
F
B
F
B
F
B
F
B
Disaggregation: Management
• Model described in Xoar and XenClient XT XenSummit talk
• Cursory implementation in OpenXT
• Separates sphere of influence of mgmt. domain
• Can provide compatibility for multiple toolstacks
• API between mgmt. and outside world & domain builder
• Think libvirt and xapi mgmt. on one system
Guest
VM 1
Mgmt
Service VM 1
Guest
VM 2
Guest
VM 3
Mgmt
Service VM 2
Guest
VM 4
Domain Builder
NDVM
Disaggregation: Future
• Disaggregation at application level– Graphics composition– Peer-to-Peer storage / transfer– Mesh networking– “Layer 7” protocol / data interposition
• Proxies of all colors• In-line rewriting / injection: javascript etc
• Unikernels / Pioneering OS research– Service VM as a unit of experimentation & innovation– Minimal driver work (PV)
• Purpose-built appliances– Mesh networking– Anonymity proxies– ClickOS
Where We Are
• “the Snowden effect”
• Increase use of privacy preserving tech
– Tor
– Startpage / Ixquick
– SSL protected traffic increased from 1% to 3%
Where We Are• (U) I hunt sys admins
– Targeted attacks on high-value targets
– Targeting the tech community
• Response– BlackPhone– Protonet (huge crowd-
funding campaign)– Whisper Systems:
RedPhone / TextSecure / Flock
– TrueCrypt audit– Tor PORTAL– cryptech.is
• Produces results or rhetoric?– BlackPhone Hacked in 5
minutes @ DEFCON– Protonet “NSA-Proof” /
“Data Sovereignty”
• XenClient XT 3.0 released 2012• Subsequent maintenance releases
• OpenXT 0.01 released June 2014– https://github.com/OpenXT (59 repos)
• Focus remains– Platform disaggregation & integrity: benefits for
security and scalability– Mainstream client devices
• Room for growth– Additional device profiles– Platform research & value-add
Who / What is OpenXT
What We Have
• Platform is infrastructure– Others have built bridges
– We’ve built another one
• Economic value– transporting “stuffs”
from one side to the other
– How many “stuffs” (quantity \ variety)
– Implies extension
– How safe are the “stuffs” in transit
• So Many Xen Platforms– Client Virtualization
Framework (CVF)– XenClient Initiative (XCI)– Xen Cloud Platform (XCP)– OpenXCI– Qubes– OpenXT
What We Want• Have
– Platform, means for extension and working examples– Full build environment
• Want– Curators: maintainers for core platform components– API hackers: Inter-domain communication (IDC)– Service VM developers– Accelerated Graphics
• Paul Durrant: Multiple Device Emulators for HVM Guests
– AMD DRTM / SKINIT & security co-processor– Composable storage layer with integrity measurement
• Collaboration with other OSS projects– Service VM compatibility (XCP / OpenXCI / Qubes / Alpine Xen)– New Service VMs (HalVM / Mirage / ClickOS / CoreOS)– New hardware targets
• “Headless” mode for server• ARM compatibility
Service VM SDK
• Virtual Appliance – initial prototype OVF• Rootfs template (immutable)• Configuration (immutable)• Configuration (user / administrator writeable)• Data (writeable)• Map concepts from current “containerization”
projects to strong isolation in Service VM– Migration tool– VtoV migration
• Better tools and documentation
Why this “virtual platform”?
• Buildable from source by anyone who reads docs– Embedded-style build using OpenEmbedded (OE) / Yocto– OE layer / distro mechanisms support flexible build time config– Small change in workflow brings larger benefits
• Configurable disaggregation granularity at build-time– Respect hardware constraints– Embedded / Client / Server / Cloud– (Everything is embedded, you just don’t know it yet)
• With specific security properties– Minimize added threat to guest beyond bare metal– Improve security properties where possible– Integrity measurements rooted in hardware
• Have Intel via tboot, want AMD SKINIT
– Mandatory access control
“Upstreaming”
• OpenXT has a lot of code that forks “upstream” currently– Not sustainable
• OpenXT will aim to treat everything as an upstream except– Unique build metadata– Configuration– Platform mgmt.
• Contributions to upstream OE– Xen recipe in meta-virtualization (thanks Chris!)– meta-selinux (lots already)– meta-measured (TPM / TXT / measurement architecture)
UpstreamDevelopment
UpstreamPlatform
OpenXT
OSS Distro
UpstreamBuild Metadata
Bitbake / OE / Yocto
Metadata
RPM Metadata
DPKG Metadata
UpstreamBuild System
DownstreamConsumer
OE / YoctoImage
Recipes
Scripts + apt
Spins / Pungi
ServiceVMProvider
CloudIaaS / PaaS /
SaaS
Hardware OEM
OSV Distro / Embedded
Xen
toolstacks
Qemu
GNU
.
.
.
Linux
Ecosystem
OpenXT
• Project page
– http://openxt.org
• Project repos hosted on Github
– https://github.com/OpenXT
• OpenXT documentation / build instructions
– https://github.com/OpenXT/openxt/wiki/
• Google Group
– https://groups.google.com/forum/#!forum/openxt