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

On Sun, 10 Aug 2008, Casey Schaufler wrote: >> 1.1 Rationale >> >> With increased use of virtualization, one security benefit of >> physically separated systems -- strong isolation -- is reduced, >> > This issue can always be readily resolved by going back to physically > separated hardware. The strength of isolation of a virtual machine > mechanism is one of the important characteristics that should be > considered when it is chosen over a hardware isolation scheme, but > the systems available today appear to do a pretty good job on this, > so I would like to see some evidence of this claim before accepting > it as a primary premise. > 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.

... > You are not going to solve any problems of misconfiguration this way, > you are just going to make the environment more complicated and prone > to misconfiguration. > I don't think this is valid as an absolute statement.

... >> >> > I can see where someone who is not familiar with VMs might think > this is plausible, but looking at the interfaces and separation provided > by VMs makes it pretty clear that this isn't even a belts and braces > level of extra protection. > 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 ?

>> o Increased protection of VM guests from each other in the event >> of host flaws or misconfiguration. Some protection may also be >> provided against a compromised host. >> >> > Flaws and misconfiguration will not be helped by this. > 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.

... > OK, I get the picture. You really want to run VMs under SELinux. > Go wild, but I think you are significantly overstating the value > and creating a project where a a little bit of policy work ought > to handle all but the most extreme cases. > 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.

> DAC, MAC, Containers, VMs, and separate hardware are all mechanisms > for providing (in ascending order) measures of isolation. It makes > sense to tighten a DAC system by adding MAC, or running a MAC system > under a VM, but to each the sort of isolation it is good at. > 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.