http://selinuxproject.org/w/?title=Svirt_requirements_v1.0&limit=50&action=history&feed=atomSvirt requirements v1.0 - Revision history2024-03-19T08:33:20ZRevision history for this page on the wikiMediaWiki 1.23.13http://selinuxproject.org/w/?title=Svirt_requirements_v1.0&diff=267&oldid=prevJamesMorris: 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: <pre> 11 Aug 2008 sVirt: Integration of SELinux and Linux-based Virtualization Requirements and Design ...</p>
<p><b>New page</b></p><div><pre><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 "Chinese wall" 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 "just work" 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 />
"isolated", 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 />
</pre></div>JamesMorris