XPDS14: Xenstore Mandatory Access Control - James Bielman, Galois
4 likes1,921 views
The document discusses the necessity of implementing mandatory access control (MAC) for Xenstore to enhance security by preventing unauthorized communication between domains. It outlines the limitations of discretionary access control (DAC) in Xenstore and describes the implementation specifics of MAC in Mirage's Xenstore, including security policy examples and labeling strategies. The goal is to merge these MAC changes upstream into Mirage's Xenstore for improved security overall.
XPDS14: Xenstore Mandatory Access Control - James Bielman, Galois
- 1. © 2014 Galois, Inc. All rights reserved. XenStore Mandatory Access Control James Bielman(jamesjb@galois.com) Xen Developer Summit| August 18th, 2014
- 2. © 2014 Galois, Inc. All rights reserved. Example scenario: Xen host with two customer VMs Xen dom1 (Customer A) dom2 (Customer B) XenStore Domain
- 3. © 2014 Galois, Inc. All rights reserved. What’s the problem? Xen dom1 (Customer A) dom2 (Customer B) XenStore Domain XSM can prevent direct communication between dom1 and dom2 Denied by XSM policy
- 4. © 2014 Galois, Inc. All rights reserved. What’s the problem? Xen dom1 (Customer A) dom2 (Customer B) XenStore Domain But XSM cannot prevent communication via XenStore if both domains can access the same nodes write to shared node read from shared node
- 5. © 2014 Galois, Inc. All rights reserved. What’s the problem? ƒ XenStore allows information to flow between domains that is not under the control of XSM policy.
- 6. © 2014 Galois, Inc. All rights reserved. Xen, MAC, and XSM ƒ Xen has supported Mandatory Access Control (MAC) via the Xen Security Modules (XSM) Flask module since version 4.3. ƒ XSM/Flask is an optional Xen component that centralizes access control in a security policy. However, this does not extend to XenStore. ƒ In this talk, I will show: • Why MAC for XenStore is important. • Our implementation of MAC for Mirage’s XenStore.
- 7. © 2014 Galois, Inc. All rights reserved. Roadmap ƒ Why is XenStore’sDAC not enough? ƒ Why add MAC to XenStore? ƒ How is XenStore+MAC implemented? ƒ What does XenStore security policy look like?
- 8. © 2014 Galois, Inc. All rights reserved. Why is XenStore’sDAC not enough? ƒ XenStore’saccess control is discretionary: • Nodes are owned by a domain • Domains control the permissions of the nodes they own
- 9. © 2014 Galois, Inc. All rights reserved. Why is XenStore’sDAC not enough? ƒ XenStore’sDAC allows domains to give away access to nodes. dom1# xenstore‐write /local/domain/1/data/x secret dom1# xenstore‐chmod/local/domain/1/data/x n1 r2 dom2# xenstore‐read /local/domain/1/data/x secret
- 10. © 2014 Galois, Inc. All rights reserved. Roadmap ƒ Why is XenStore’sDAC not enough? ƒ Why add MAC to XenStore? ƒ How is XenStore+MAC implemented? ƒ What does XenStore security policy look like?
- 11. © 2014 Galois, Inc. All rights reserved. Why add MAC to XenStore? ƒ With mandatory access control in XenStore, the security policy states which domains may access which XenStore nodes. ƒ Domains cannot give away access to XenStore nodes they own, unless explicitly allowed by the policy.
- 12. © 2014 Galois, Inc. All rights reserved. How XenStore+MAC works ƒ All objects are assigned a security label. • Xen domains • XenStore nodes ƒ Example labeling: • /local/domain/1/data xs_dom1_data_t • /local/domain/1/data/x xs_dom1_data_t • /local/domain/2/data xs_dom2_data_t
- 13. © 2014 Galois, Inc. All rights reserved. How XenStore+MACworks ƒ A security policy lists which operations are allowed based on: • the subject performing the request • the object being accessed • the type of access being requested
- 14. © 2014 Galois, Inc. All rights reserved. How XenStore+MACworks ƒ Example policy: • allow dom1_txs_dom1_data_t : xenstore { read write create delete }; • allow dom2_txs_dom2_data_t : xenstore { read write create delete };
- 15. © 2014 Galois, Inc. All rights reserved. How does XenStore+MAC address this threat? ƒ Each domain has full access to its own “data” nodes, but there is no cross-domain access allowed by the policy. ƒ Domains cannot grant additional access beyond the policy, so the communication channel between dom1 and dom2 is closed.
- 16. © 2014 Galois, Inc. All rights reserved. Roadmap ƒ Why is XenStore’sDAC not enough? ƒ Why add MAC to XenStore? ƒ How is XenStore+MAC implemented? ƒ What does XenStore security policy look like?
- 17. © 2014 Galois, Inc. All rights reserved. XenStore+MAC: Platform ƒ Work is based on Mirage’s XenStore ƒ Why Mirage? • Mirage is under active development and contains a solid XenStore implementation. • A unikernel is a good fit for XenStore.
- 18. © 2014 Galois, Inc. All rights reserved. XenStore+MAC: Nested Security Server ƒ XenStore security policy should be managed by XenStore, not the hypervisor. ƒ But XenStore policy must be able to reference Xen domains from the hypervisor’s XSM policy.
- 19. © 2014 Galois, Inc. All rights reserved. XenStore+MAC: Nested Security Server ƒ XenStore is responsible for loading its policy and performing security checks against it. ƒ A “context database” describes how to map security labels from the parent XSM policy to XenStore policy.
- 20. © 2014 Galois, Inc. All rights reserved. XenStore+MAC: Low-Level Design ƒ Modular design: • added security hooks to core XenStore module • added security checks against installed hooks • same approach taken by LSM in Linux and XSM in Xen ƒ Default “dummy” security hooks revert to existing DAC-only behavior.
- 21. © 2014 Galois, Inc. All rights reserved. XenStore+MAC: xenstore-flask module ƒ Uses libsepolto load and perform access checks against an SELinux binary policy. ƒ The SELinux policy compiler (checkpolicy) is used without modification to compile policy. ƒ The binary policy is augmented with: • a path database used for labeling • a context database to import security IDs from XSM
- 22. © 2014 Galois, Inc. All rights reserved. Roadmap ƒ Why is XenStore’sDAC not enough? ƒ Why add MAC to XenStore? ƒ How is XenStore+MAC implemented? ƒ What does XenStore security policy look like?
- 23. © 2014 Galois, Inc. All rights reserved. Policy examples: Node Labeling Node Path Security Label / xs_root_t /local xs_root_t /local/domain xs_local_domain_t /local/domain/1 xs_dom1_ctl_t /local/domain/1/data xs_dom1_data_t /local/domain/2 xs_dom2_ctl_t /local/domain/2/data xs_dom2_data_t
- 24. © 2014 Galois, Inc. All rights reserved. Policy example: Binding ƒ The security policy can define the shape of the XenStore tree by how the “bind” permission is allowed.
- 25. © 2014 Galois, Inc. All rights reserved. Policy example: Binding Newly created nodes must be allowed to bind to their parent. # parentchild allow xs_root_txs_local_domain_t: xenstore bind; allow xs_local_domain_txs_dom1_ctl_t: xenstore bind; allow xs_dom1_ctl_txs_dom1_data_t: xenstore bind;
- 26. © 2014 Galois, Inc. All rights reserved. Policy example: Node labeling ƒ By default, new nodes inherit their security label from parent node. ƒ To override the default behavior: • Assign the path a label in the path database. • Add a type_transitionstatement to the policy assigning the node a label based on the parent and path labels.
- 27. © 2014 Galois, Inc. All rights reserved. Policy example: Node labeling Path database: Specifies what kind of type transition is used to label a new node. # type path label ctx/local/domain xs_local_domain_path_t dom/local/domain/* ctx/local/domain/*/data xs_domain_data_path_t
- 28. © 2014 Galois, Inc. All rights reserved. Policy example: Node labeling Labeling policy: Specifies new node label based on path type and the parent node label or domain ID from the path. type_transitionxs_root_txs_local_domain_path_t : xenstore xs_local_domain_t; type_transitionxs_dom1_ctl_t xs_domain_data_path_t : xenstore xs_dom1_data_t; type_transitiondom1_txs_local_domain_t : xenstore xs_dom1_ctl_t;
- 29. © 2014 Galois, Inc. All rights reserved. Policy example: Macros ƒ M4 macros are used to capture common patterns in policy such as connecting XenStore nodes for device frontends and backends.
- 30. © 2014 Galois, Inc. All rights reserved. Policy example: Macros Connecting device frontends in domU domains to a driver domain with M4 macros: # Privileged dom0, driver domain: xs_domain(dom0) xs_device_backend(dom0, vbd) # domUcreated by, and using devices from, dom0: xs_domain(domU) xs_control_domain(domU, dom0) xs_device(domU, dom0, vbd)
- 31. © 2014 Galois, Inc. All rights reserved. Policy example: Macros These macros expand into policy setting up permissions for the front and back driver domains: # Allow the frontend domain to read backend nodes. allow domU_txs_vbd_backend_for_domU_t: xenstore { read }; # Allow the frontend domain to write frontend nodes. allow domU_txs_domU_vbd_frontend_t: xenstore { write create }; # Allow the backend domain to read frontend nodes. allow dom0_txs_domU_vbd_frontend_t: xenstore { read };
- 32. © 2014 Galois, Inc. All rights reserved. Summary ƒ MAC is cool; Xen already supports it via XSM. ƒ XenStore should be secured with MAC as well. ƒ Get our MAC implementation for Mirage XenStore: • opam repo add https://github.com/GaloisInc/opam‐repo.git • opam install mirage • git clone https://github.com/GaloisInc/ocaml‐xenstore‐ xen.git ƒ Our goal is to merge these changes upstream to Mirage’s XenStore.