[libvirt] Re: [ANNOUNCE][RFC] sVirt: Integrating SELinux and Linux-based virtualization

On Sun, 10 Aug 2008, Casey Schaufler wrote: I suspect you misunderstood an important aspect of this in that we are targeting Linux-based virtualization, where the VMs are running inside Linux processes. In this case, the isolation depends on DAC in the host, and the idea behind sVirt is to apply MAC security to these VMs and their resources. Currently, all such VMs run with the same security label, and all of the resources accessed (e.g. disk images) have the same labels. We are simply proposing a mechanism to allow distinct security labels to be applied to these entities, which in the simplest case, will allow MAC policy to enforce isolation between them. I'm not sure how you come to the conclusion that the MAC system must be inadequate, but this scheme does attempt to improve the robustness of isolation between Linux-based VMs. We're applying the idea of containing applications in the face of potential flaws and misconfiguration to the case of applications which happen to be VMs. In this sense, it is not different to containing any other form of application (e.g. a flaw in the VM might be exploited by malicious code). I don't think this is valid as an absolute statement. e.g. by adding distinct labels to VMs and their resources at the toolchain level, the admin will not be involved beyond specifying that the VM is to be created as an "isolated" instance. The VMs will simply be running with different labels and bound to their own resources with those labels, enforced by MAC policy. If an admin manually launches a VM and accidentally specifies an incorrect disk image, MAC policy will prevent the VM from accessing the image. There is nothing characteristically different between this and the general rationale for MAC in the OS, e.g. to ensure that a web server can only serve appropriately labeled content. The risk that the MAC system itself could be misconfigured does not change with sVirt, although in the proposed scheme, VM labeling will be automated. Again, keep in mind that we're talking about Linux-based virtualization, where the VM is literally just another application running in the host OS. I don't understand what needs to be backed here. Currently, MAC is not used to separate different Linux-based VMs, and by integrating MAC support, people will be able to further utilize MAC. Please be specific: in what way is it not rational? I disagree. VMs are software, and all software has bugs. If you can break out of the VM in Linux-based virtualization, you can probably get to all of the other VMs on the system (they are running in the same DAC and MAC contexts). Applying distinct labels allows MAC policy to be enforced by the host kernel so that such breaches are contained within the isolated host VM process. Or are you saying that you don't think hypervisors can be broken out of ? I don't see why not. With MAC containment, if, say, a web server on the host was compromised, an attacker may be prevented from interfering with the VMs running on the system. This is already true to some extent with coarse-grained MAC. Again, it's important to understand that these VMs are merely Linux processes and are only currently afforded the same level of isolation as standard DAC. DAC is of course considered inadequate as a means to protect against a range of common threats including software flaws. Please refer to: http://www.nsa.gov/selinux/papers/inevitability/ (I know you know this, but not everyone reading this thread is familiar with the case for MAC). When they progress to walking. Yes, but these are use-cases. They are condensed into requirements further on. It means going beyond simple isolation and specifying security goals which are then mapped to policy. So, you can design a system in the security problem domain, rather, than say, the security model domain (e.g. BLP). Note that this is a logical extension of the system aimed at advanced users. In the default case, VMs will simply be isolated from each other via MAC. That's not my experience, but I guess anything can happen. There is no explicit support for doing this, and in fact, that is one of the things that sVirt will address. In SELinux, an MLS label is simply part of the overall security context. The proof of concept code is indeed simple policy/labeling changes, although we want to ensure that we fully understand the requirements, and implement a flexible and generally useful scheme. Support for this also needs to be built directly into the virt toolchain so that the user is provided with a complete solution, rather than a collection of pieces. So, in the case of a Linux-based VM running as a process in a DAC context, we are indeed tightening a DAC system by adding MAC. - James -- James Morris <jmorris(a)namei.org&gt;