Transcript Xen-Cap - Flux Research Group

Xen-Cap
A Capability Framework for Xen
Yathindra Naik
School of Computing
University of Utah
Advisor
Robert Ricci
Flux Research Group
University of Utah
Co-Advisor
Anton Burtsev
Flux Research Group
University of Utah
0
Traditional systems are monolithic
User Space
Untrusted
PDF App
PDF
App1 App2 App3 App4
Parse
OS interface
compromised
Kernel Space
Javascript engine is
compromised
Privilege escalation
Network
Stack
File
System
Device Drivers
1
Network
Stack
File
System
Stack
Window
Manager
Kernel
Network
Driver
Disk
Driver
Application VMs
Disaggregated architecture
Graphics
Driver
Qubes/Bromium
design
Xen Hypervisor
2
Ideal system?
3
File System
4
GUI cannot talk
to User
File System
GUI
User
5
Render
screen
File write
PDF reader
compromised
Word processor
File read
Render
screen
PDF reader
File System
GUI
User
6
Challenges
VM 1
VM 2
Objects at
application
level
Shared
memory
Objects at
kernel level
Hypercalls
Higher
level IPC
Objects at
hypervisor
level
Hypervisor
7
Proposed solution
• Single interface for every layer to manage
capabilities
– Uniform access control across the system
• Applications decide the semantics of the
object they manage
– Applications bind capabilities to objects
– Do security checks
• Hypervisor protects capabilities
– Hypervisor also protects a small set of objects which it
implements
8
Contributions
Engineering
• Extended Xen 4.3 with a capability interface
– Can run unmodified Xen VMs on top of Xen-Cap
– Provide support for easy construction of guest-level
capability services
– Implemented an NFS-based capability protected file
system
Intellectual
• Capability framework for virtualized environments
• Design recipe for implementing least-privilege services
9
Design/Architecture
10
Xen-Cap capabilities
• Record inVMthe
data
VM 2
1 hypervisor protected
structure
Xen-Cap Interface
Xen-Cap Interface
Xen Hypervisor
64-bit
Integer
CSpace
Capability
11
Xen-Cap Interface
• 3 hypercallsVM 1
VM2
Read/Write
– cap_create()
Application
Application
– cap_grant(domain id, capability_name)
OK
cap_create
– cap_check(domain_id,
capability_name)
Kernel
Kernel
0xcafebeef
Hypercall Interface
• Capability rulescap_check
are enforced by
the hypervisor
• Capability checks made
by high-level code
Xen Hypervisor
Hypercall Interface
cap_grant
12
Xen-Cap properties
• Global capability names
– Name is decided by the hypervisor
– Generated randomly
• Capabilities are regenerated after reboot
– No persistent capabilities
• Xen-Cap interface is the only way to interact
with capabilities
13
Securing critical services
14
Xen Overview
Domain 0
XenStore
Guest Domain
xl tool
local
- domain
--- 0
------ disk
…
------ network
…
Disk Blkback
Net back
Disk Blkfront
Net front
Xen Hypervisor
15
Xen Overview
Domain 0
XenStore
Guest Domain
xl tool
local
- domain
--- 0
------ disk
…
------ network
…
Disk Blkback
Hypercalls
Net back
Disk Blkfront
Net front
Xen
Hypervisor
Event
Channels
16
Xen-level objects
• Hypervisor-level objects
– Hypercall invocation points
– Event-channels
– shared memory
• Use XSM to avoid re-engineering
• XSM is a general security framework like
SELinux for Xen
• XSM hooks transfer to Xen-Cap interfaces
17
Boot protocol
• The hypervisor creates capabilities for hypervisorlevel objects upon boot
– Grants them to the first booting domain
• First domain needs to learn capability names for
specific objects
– E.g., a capability name for each hypercall to grant
them to other domain
• get_cap_names interface resolves a resource
name into a capability name
– Hypervisor implements it as a shared page with a
known structure, where capability names are stored
18
Hypercalls
• Creating and binding capabilities
– Hypervisor creates capabilities and grants them to
first booting domain
• Distribution
– Grant all hypercalls listed in a VM config file to the
new VM
• Check
– Hypervisor checks capability on every hypercall
invocation
19
Event channels
• Inter-VM communication is built on top of two
primitives – shared memory and event
channels
• Events are signaling mechanism in Xen
• Securing event channels with capabilities
allows us to restrict the communication
channels available to VMs
20
Securing event channels
Domain 0
xl tool
Backend
est_evtchn
Hypervisor
object to
bind
capability
Xen
cap_create
Grant
est_evtchn
Dom 1
Dom 2
Frontend
Frontend
Grant
est_evtchn
est_evtchn
est_evtchn
cap_create
Event channel
Securing event channel
21
XenStore
XenStore
Domain 0
Guest
/local
… domain
…… 0
……… backend
………… disk
…………
…………
xl tool
Read/Write
Frontend/Back
end pair
connected
cap_grant
…… 1
……… frontend
………… disk
…………
…………
App
OK
Blk
backend
cap_check
Blk
Frontend
cap_create
Xen
22
Configuring capabilities via config file
• Xen config files specify VM configuration
• We specify capabilities using additional
parameters in config file
• Provides easy mechanism to invoke VM with
specific capabilities
• cap_hypercalls, cap_files, cap_evtchn.
23
24
Constructing least-privilege
environment
25
Xen-Cap for file system
•
•
•
•
File system common for sharing, even in VMs
Need flexible, fine-grained delegation of rights
NFS makes it easy to share files on Ethernet
NFS comes with ACLs but does not have
delegation capabilities
• We construct a least-privilege NFS shared
environment using Xen-Cap
26
Least-privilege file system
Export
Boo.pdf
Boo.
pdf
Kernel
File System
Export
Foo.pdf
xl
tool
Application VMs
Foo.
pdf
Kernel
cap_create
Foo.pdf
Xen
cap_grant
Foo.pdf
cap_grant
Foo.pdf
27
Creating
NFS request
the NFS
path
VMs
NFSNFS
server
VM
client
config
VM
config
file file
Domain
0 VM
NFS
Server
/
File
System
/home
XenStore ydev
/local
… domain
…… NFS
……… backend
LSM
…………
Hooks
………… /ydev
……
………
…… frontend
………… 1
………… 10.1.0.1
cap_check
/etc
NFS
VM
Client VM
NFS Server
xl tool
File
File
System
System
/lib /usr
aburtsev
Write the
filesytem to
be exported
NFS
Server
VifWrite the
domid and TCP/IP
frontend
ip addr of
NFS client
//
App
Grant
capabilities
for exported
files
Virtual
Create
private
capabilities
network
for exported
files
/home
/etc /lib
/lib /usr
/usr
/client /etc
Readaburtsev
/ydev/foo.pdf
ydev
ydev
NFS
Client
Vif
frontend
Vif
Vif
TCP/IP
frontend
frontend
NFS
NFS
Server
Client
TCP/IP
TCP/IP
OK
Xen
28
Related Work
• SELinux, AppArmor, FLASK, Smack and Solaris
Trusted Extensions are notable MAC
frameworks
• Capsicum adopts capabilities on FreeBSD at
file descriptor level
• Qubes and Bromium and XenClient sandbox
apps by running them in separate VMs
• A number of research OS such as EROS, seL4
etc., implement capabilities from scratch
29
Conclusions
• Xen-Cap serves as a stepping stone towards
realizing a full capability access control model on
popular hypervisors
• Xen-Cap works on unmodified OS due to its
transparent capabilities
• We were able to secure a number of critical
services using Xen-Cap without significant
amount of code changes
• Xen-Cap is simple to use (with just 3 hypercalls)
30
Future work
• Capability rules needs more refinements
– cap_revoke could not be implemented
– cap_grant needs to be thought more carefully as
we do not address transitive grant rules yet
• CSpace needs more efficient data structure
• Using persistence store for capabilities is
another area that needs thinking
• Mechanisms to spawn light-weight VMs
31
Acknowledgements
•
•
•
•
•
Robert Ricci
Anton Burtsev
Mike Hibler
Eric Eide
All the members of Flux Research Group
32
Thank you
Questions/Answers? 
33
Backup slides
34
Isolation alone is not enough
• Virtualization provides strong isolation
• Isolation does not guarantee security
• Isolated services but runs with ambient
authority
• Need flexible and fine-grained access control
• Goal is to minimize authority
35
Flexible access control
• Existing security models lack flexible, finegrained access control
• Dynamic privilege management is hard to get
right
• Capabilities have been shown to provide
flexible and fine-grained access control
mechanism
• Applications need to have privileges to
perform their task and no more
36
Capabilities are well understood in
microkernel community
App
Foo.PDF
File Read
IPC
•
•
•
Invokes capability
Capability references the object
and authorizes valid operations
Capability is the only way to
access the object
Microkernel does the capability
check
Microkernel
Object-oriented capability design in microkernel
37
Capabilities
• Capability – Special token that uniquely
identifies an object and allows certain
operations on the object.
• seL4 and EROS implement object capability
model from scratch.
• Hypervisors do not offer objects as the basic
abstraction for resources.
38
Event channels
Domain 0
Guest
Read
reply
Read
request
Backend
Notify
Read
request
Xen
Frontend
Shared ring buffer
Event channel
Event channel communication
39