XenCap A Capability Framework for Xen Yathindra Naik

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 1 App 2 App 3 App 4 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 Objects at application level Objects at kernel level VM 2 Shared memory 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 in the hypervisor protected data VM 2 VM 1 structure Xen-Cap Interface Xen Hypervisor 64 -bit Integer CSpace Capability 11

Xen-Cap Interface • 3 hypercalls. VM 1 VM 2 Read/Write – cap_create() Application – cap_grant(domain id, capability_name) OK cap_create – cap_check(domain_id, capability_name) Kernel 0 xcafebeef • Capability rules are enforced by the hypervisor • Capability checks made by high-level code Xen Hypervisor Hypercall Interface cap_check 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 Xen. Store Guest Domain xl tool local - domain --- 0 ------ disk … ------ network … Disk Blkback Net back Disk Blkfront Net front Xen Hypervisor 15

Xen Overview Domain 0 Xen. Store 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 Grant est_evtchn cap_create Event channel Securing event channel 21

Xen. Store 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 Kernel File System Domain 0 xl tool NFS Server Export Foo. pdf Kernel cap_create Foo. pdf Xen Application VMs Foo. pdf cap_grant Foo. pdf 27

Creating the NFS VMs NFS request path Domain 0 NFS Server VM NFS server NFS VM config client VM config file / File System xl tool App File System /home /etc /lib /usr Xen. Store ydev aburtsev /local … domain …… NFS ……… backend LSM ………… Hooks ………… /ydev …… …… frontend ………… 10. 1 cap_check NFS Server VM NFS Client VM Write the filesytem to be exported NFS Server Vif. Write the domid and ip TCP/IP frontend addr of NFS client Grant capabilities for exported files Virtual Create private capabilities network for exported files / /home /etc /lib /usr /client /etc /lib /usr Read /ydev/foo. pdf ydev aburtsev ydev NFS Client Vif frontend Vif TCP/IP frontend NFS Server Client TCP/IP OK Xen 28

Related Work • SELinux, App. Armor, FLASK, Smack and Solaris Trusted Extensions are notable MAC frameworks • Capsicum adopts capabilities on Free. BSD at file descriptor level • Qubes and Bromium and Xen. Client sandbox apps by running them in separate VMs • A number of research OS such as EROS, se. L 4 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. • se. L 4 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 communication 39