http://selinuxproject.org/w/?title=Svirt_requirements_v1.0&limit=50&action=history&feed=atom Svirt requirements v1.0 - Revision history 2024-03-19T08:33:20Z Revision history for this page on the wiki MediaWiki 1.23.13 http://selinuxproject.org/w/?title=Svirt_requirements_v1.0&diff=267&oldid=prev JamesMorris: New page: <pre> 11 Aug 2008 sVirt: Integration of SELinux and Linux-based Virtualization Requirements and Design ... 2008-08-11T02:20:15Z <p>New page: &lt;pre&gt; 11 Aug 2008 sVirt: Integration of SELinux and Linux-based Virtualization Requirements and Design ...</p> <p><b>New page</b></p><div>&lt;pre&gt;<br /> <br /> 11 Aug 2008<br /> <br /> sVirt: Integration of SELinux and Linux-based Virtualization<br /> <br /> Requirements and Design Considerations v1.0<br /> <br /> <br /> 1. Introduction<br /> <br /> This document establishes a set of functional and technical<br /> requirements for integrating SELinux with Linux-based<br /> virtualization (i.e. Linux-as-hypervisor schemes such as KVM/Qemu<br /> amd lguest).<br /> <br /> Note that non-Linux hypervisor models such as Xen are not covered<br /> explicitly in this document, although may be afforded some MAC<br /> coverage due to shared infrastructure (e.g. libvirt). Non-Linux<br /> hypervisor models may considered further at a later stage.<br /> <br /> Also, while this document focuses on SELinux as the MAC scheme,<br /> consideration should be given to ensuring support for other<br /> label-based MAC schemes.<br /> <br /> <br /> 1.1 Rationale<br /> <br /> With increased use of virtualization, one security benefit of<br /> physically separated systems -- strong isolation -- is reduced, an<br /> issue which may be ameliorated with the application of Mandatory<br /> Access Control (MAC) security in the host system.<br /> <br /> Integration of MAC with virtualization will also help increase the<br /> overall robustness and security assurance of both host and guest<br /> systems. Many threats arising from flaws in the VM environment, or<br /> misconfiguration, may be mitigated through tighter isolation and<br /> specific MAC policy enforcement.<br /> <br /> By incorporating MAC support into the virtualization toolchain and<br /> documentation, users will also be able to make more use of the MAC<br /> security capabilities provided by the OS.<br /> <br /> <br /> 1.2 Use-cases<br /> <br /> The following use-cases have been identified:<br /> <br /> o Providing virtualized services with a level of isolation<br /> similar to that previously afforded by physical separation.<br /> <br /> o Increased protection of the host from untrusted VM guests (e.g.<br /> for VM hosting providers, grid/cloud servers etc.).<br /> <br /> o Increased protection of VM guests from each other in the event<br /> of host flaws or misconfiguration. Some protection may also be<br /> provided against a compromised host.<br /> <br /> o Consolidating access to multiple networks which require strong<br /> isolation from each other (e.g. military, government, corporate<br /> extranets, internal &quot;Chinese wall&quot; separation etc.)<br /> <br /> o Strongly isolating desktop applications by running them in<br /> separately labeled VMs (e.g. online banking in one VM and World<br /> of Warcraft in another; opening untrusted office documents in<br /> an isolated VM for view/print only).<br /> <br /> o Forensic analysis of disk images, binaries, browser scripts<br /> etc. in a highly isolated VM, protecting both the host system<br /> and the integrity of the components under analysis.<br /> <br /> o Isolated test environments, preventing e.g. simulated trades<br /> from entering a production system, leakage of sensitive<br /> customer data to internal networks etc.<br /> <br /> o General ability to specify a wide range of high-level security<br /> goals for virtualization through flexible MAC policy.<br /> <br /> <br /> 2. Current Situation<br /> <br /> SELinux is already able to provide general MAC protection to<br /> Linux-based virtualization, such as protecting the integrity and<br /> confidentiality of disk images and providing strong isolation of<br /> Linux hypervisor processes from the rest of the system.<br /> <br /> There is, however, no explicit support for Linux-based<br /> virtualization in SELinux, and all VMs currently run in the same<br /> security context. Thus, there is no MAC isolation applied between<br /> VMs.<br /> <br /> 3. Functional Security Requirements<br /> <br /> 3.1 Strong isolation between active VMs<br /> <br /> Running different VMs with different MAC labels allows stronger<br /> isolation between VMs, reducing risks arising from flaws in or<br /> misconfiguration of the VM environment. For example, the threat of<br /> a rogue VM exploiting a flaw in KVM could be greatly reduced if it<br /> is isolated from other VMs by MAC security policy.<br /> <br /> <br /> 3.2 Improved control over access to VM resources<br /> <br /> Distinct MAC labeling of resources belonging to VMs (disk images,<br /> disk partitions etc.) binds VM instances to those resources,<br /> ensuring that VMs can only access their own resources. This can<br /> protect the VM from invalid VM resources; and protect VM resources<br /> from flawed or misconfigured VMs.<br /> <br /> <br /> 3.3 Improved control over access to shared resources<br /> <br /> Where VMs may share resources (e.g. miscellaneous devices, virtual<br /> networking, read-only disk images etc.), fine-grained MAC policy<br /> may be specified to control information flow between VMs.<br /> <br /> <br /> 3.4 Fine-grained interaction with the host<br /> <br /> With distinct labeling of VMs and their resources, interactions<br /> with host entities on a per-VM basis may then be controlled by MAC<br /> policy.<br /> <br /> An example of this would be to safely allow different users on the<br /> host to administer different VMs. Configuration of this could be<br /> managed via the RBAC scheme integrated with SELinux.<br /> <br /> <br /> 3.5 Coarse MAC containment of VMs<br /> <br /> High-level security constraints may be applied to different VMs, to<br /> allow simplified lock-down of the overall system. For example, a<br /> VM may be restricted so that it cannot transmit TCP traffic on port<br /> 25 via virtual networking (i.e. the guest cannot be used as a spam<br /> bot even if it is compromised via a rootkit).<br /> <br /> <br /> 3.6 Leverage general MAC architecture<br /> <br /> As MAC is extended to the desktop, it will be possible to apply<br /> uniform MAC policy to the OS, desktop and Linux-based<br /> virtualization components. This will provide a basis for a variety<br /> of sophisticated security applications such as a virtualized MLS<br /> desktop with different windows running VMs at different security<br /> levels.<br /> <br /> <br /> 4. Design Considerations<br /> <br /> 4.1 Consensus in preliminary discussion appears to be that adding<br /> MAC to libvirt will be the most effective approach. Support<br /> may then be extended to virsh, virt-manager, oVirt etc.<br /> <br /> 4.2 Initially, sVirt should &quot;just work&quot; as a means to isolate VMs,<br /> with minimal administrative interaction. e.g. an option is<br /> added to virt-manager which allows a VM to be designated as<br /> &quot;isolated&quot;, and from then on, it is automatically run in a<br /> separate security context, with policy etc. being generated<br /> and managed by libvirt.<br /> <br /> 4.3 We need to consider very carefully exactly how VMs will be<br /> launched and controlled e.g. overall security ultimately must<br /> be enforced by the host kernel, even though VM launch will be<br /> initially controlled by host userspace.<br /> <br /> 4.4 We need to consider overall management of labeling both<br /> locally and in distributed environments (e.g. oVirt), as well<br /> as situations where VMs may be migrated between systems,<br /> backed up etc.<br /> <br /> One possible approach may be to represent the security label<br /> as the UUID of the guest and then translate that to locally<br /> meaningful values as needed.<br /> <br /> 4.5 MAC controls/policy will need to be considered for any control<br /> planes (e.g. /dev/kvm).<br /> <br /> 4.6 We need to ensure that we have high-level management tools<br /> available from the start, avoiding past mistakes with SELinux<br /> where we dropped a bunch of complicated pieces in the user's<br /> lap. All aspects of sVirt must be managed by the via the virt<br /> tools and only present high-level abstractions to the user<br /> (and then, only if essential).<br /> <br /> 4.7 As sVirt involves creating and managing arbitrary numbers of<br /> security labels, we will need to address the effects of label<br /> space explosion and resulting complexity.<br /> <br /> Possible approaches already discussed include:<br /> <br /> - SELinux RBAC or IBAC mechanisms.<br /> <br /> - MCS labels. This has the possible advantage of not<br /> requiring any policy changes for simple isolation: just<br /> have a general policy which applies to all MCS labels, and<br /> possibly customize behavior via the type.<br /> <br /> e.g.<br /> <br /> system_u:object_r:virt_image_t:c1<br /> ^ ^<br /> type mcs label<br /> <br /> <br /> <br /> 'c0' = isolated inactive VM image/device.<br /> <br /> 'cN' = dynamically assigned MCS label for active VM, bound<br /> to the UUID, and translated via MCS translation<br /> file. i.e. a user running ls -Z or ps -Z will see<br /> the UUID instead of cN.<br /> <br /> <br /> 'virt_image_t' = standard VM which is also isolated if an<br /> MCS label is present.<br /> <br /> 'virt_image_nonet_t' = VM with no network access at all.<br /> <br /> etc.<br /> <br /> So, MCS is used to enforce VM isolation, Type is used to<br /> enforce general security behavior. We can then provide a<br /> high-level GUI interface for selecting this behavior<br /> without the admin knowing anything about SELinux.<br /> <br /> Note: proof of concept testing has been performed using<br /> MCS labels, which appears to be workable at this stage.<br /> <br /> - Utilize the new hierarchical types being proposed upstream by<br /> NEC. (No analysis done yet).<br /> <br /> <br /> 4.8 Accessing images via shared storage will present challenges as<br /> we do not yet have labeling for networked filesystems.<br /> <br /> 4.9 We must ensure that any MAC support integrated into libvirt is<br /> readily debuggable. e.g. hook into auditsp to actively<br /> process policy violations and handle them via the virt<br /> toolchain; also develop good setroubleshoot plugins.<br /> <br /> 4.10 {lib}semanage needs performance optimization work to reduce<br /> impact on the virt toolchain.<br /> <br /> &lt;/pre&gt;</div> JamesMorris