On 11/06/2011 10:40 PM, Sasha Levin wrote: > Hi all, > > I'm planning on doing a small fork of the KVM tool to turn it into a > 'Secure KVM' enabled hypervisor. Now you probably ask yourself, Huh? Actually, no. > The idea was discussed briefly couple of months ago, but never got off > the ground - which is a shame IMO. > > It's easy to explain the problem: If an attacker finds a security hole > in any of the devices which are exposed to the guest, the attacker would > be able to either crash the guest, or possibly run code on the host > itself. Crashing the guest is fine (not 100% - you can have unprivileged code managing a device, in which case we allow unprivileged code to crash the entire guest - but that's rare). Running code on the host is also fine; we have a permissions system in place to prevent damage; see libvirt's sVirt code, which uses selinux to disallow an exploited guest from touching other guests or host data. It should be able to protect host-only networks as well (not sure if it does that). The real risk is that the exploited hypervisor turns around and exploits yet another hole in the system, like a privileged daemon that the hypervisor is allowed to be in contact with, or the kernel itself, via a vulnerability in the kernel interfaces. > The solution is also simple to explain: Split the devices into different > processes and use seccomp to sandbox each device into the exact set of > resources it needs to operate, nothing more and nothing less. One thing to beware of is memory hotplug. If the memory map is static, then a fork() once everything is set up (with MAP_SHARED) alllows all processes to access guest memory. However, if memory hotplug is supported (or planned to be supported), then you can't do that, as seccomp doesn't allow you to run mmap() in confined processes. This means they have to use RPC to the main process in order to access memory, which is going to slow them down significantly. > Since I'll be basing it on the KVM tool, which doesn't really emulate > that many legacy devices, I'll focus first on the virtio family for the > sake of simplicity (and covering 90% of the options). Since virtio is so performance sensitive, my feeling is that it is better to audit it, and rely on sandboxing for the non performance sensitive parts of the device model. Of course for a POC it's fine to start with it. > This is my basic overview of how I'm planning on implementing the > initial POC: <snip plan> > Thats all I have for now, comments are *very* welcome. This plan is quite similar to the equivalent plans for qemu. However, as kvm-tool is much smaller than qemu, you're likely to have much easier time and make much faster progress. This is really a great use of kvm-tool, to explore new ideas rather than catching up; and I'm sure your experience will prove useful for qemu as well. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
