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

2. Traditional systems are monolithic Network Stack Network Stack File System Device Drivers App1App2App3App4 PDF App Parse Untrusted PDF User Space Kernel Space Privilege escalation Parse Javascript engine is compromised OS interface compromised 1

3. Disaggregated architecture Kernel Network Stack Network Stack File System Stack File System Stack Window Manager Window Manager Network Driver Network Driver Disk Driver Disk Driver Graphics Driver Graphics Driver Xen Hypervisor Application VMs Qubes/Bromium design 2 Kernel File System Stack File System Stack

4. Ideal system? 3

5. 4 File System

6. 5 GUI User GUI cannot talk to User File System

7. 6 GUI User File System PDF reader File read Render screen Word processor File write File read Render screen PDF reader compromised

8. Challenges Hypervisor 7 VM 2 VM 1 Objects at application level Objects at kernel level Objects at hypervisor level Higher level IPC Shared memory Hypercalls

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

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

11. Design/Architecture 10

12. Xen-Cap capabilities 11 Xen Hypervisor VM 1 VM 2 Xen-Cap Interface 64-bit Integer Capability Record in the hypervisor protected data structure CSpace

13. 3 hypercalls – cap_create() – cap_grant(domain id, capability_name) – cap_check(domain_id, capability_name) Capability rules are enforced by the hypervisor Capability checks made by high-level code Xen Hypervisor VM 1 VM2 Application Hypercall Interface Xen-Cap Interface Kernel cap_create Read/Write cap_check OK 12 Application Kernel cap_grant 0xcafebeef

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

15. Securing critical services 14

16. Xen Overview Xen Hypervisor local - domain --- 0 ------ disk … ------ network … XenStore Disk Blkback Net back Domain 0 xl tool Guest Domain Disk Blkfront Net front 15

17. Xen Overview Xen Hypervisor local - domain --- 0 ------ disk … ------ network … XenStore Disk Blkback Net back Domain 0 xl tool Guest Domain Disk Blkfront Net front 16 Hypercalls Event Channels

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

19. Boot protocol The hypervisor creates capabilities for hypervisor- level 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

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

21. 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 Event channels 20

22. Xen Frontend Dom 1 Securing event channel Backend Domain 0 xl tool Frontend Dom 2 est_evtchn cap_create est_evtchn cap_create Grant est_evtchn Grant est_evtchn Grant est_evtchn Securing event channels Event channel 21 Hypervisor object to bind capability

23. XenStore Xen /local … domain …… 0 ……… backend ………… …… ……… ………… /local … domain …… 0 ……… backend ………… …… ……… ………… XenStore Domain 0 Guest disk Blk backend Blk Frontend Blk Frontend disk Frontend/Back end pair connected 1 frontend cap_create cap_grant App cap_check OK Read/Write xl tool 22

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

25. 24

26. Constructing least-privilege environment 25

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

28. Least-privilege file system Kernel Xen Application VMs Export Foo.pdf Export Boo.pdf xl tool cap_create Foo.pdf cap_create Foo.pdf cap_grant Foo.pdf cap_grant Foo.pdf cap_grant Foo.pdf cap_grant Foo.pdf File System Foo. pdf Boo. pdf 27

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

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

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

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

33. Acknowledgements Robert Ricci Anton Burtsev Mike Hibler Eric Eide All the members of Flux Research Group 32

34. Thank you Questions/Answers? 33

35. Backup slides 34

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

37. Flexible access control Existing security models lack flexible, fine- grained 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

38. Capabilities are well understood in microkernel community Microkernel Foo.PDF App File Read IPC Invokes capability Object-oriented capability design in microkernel Capability references the object and authorizes valid operations Capability is the only way to access the object Microkernel does the capability check Capability references the object and authorizes valid operations Capability is the only way to access the object Microkernel does the capability check 37

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

40. Event channels 39 Xen Backend Frontend Domain 0Guest Event channel Read request Read reply Read reply Shared ring buffer Notify Read request Notify Read request Event channel communication