KVM, QEMU, and kernel project management [LWN.net]

KVM, QEMU, and kernel project management

Posted Mar 29, 2010 19:07 UTC (Mon) by jeremiah (subscriber, #1221)
In reply to: KVM, QEMU, and kernel project management by dlang
Parent article: KVM, QEMU, and kernel project management

We run into this problem as well. We'd really like to offload some of our credit card processing but
we can't trust the hosts, much less the some of the other guests on the same host. My
understanding, is that guest to guest security has gotten better due to 'on chip' virtualization techs,
but I think the next place I'd like to see the KVM folks go is protecting the guest from the host as
much as possible.

As far as perf is concerned though, could this just be a parameter in the guest os that could disable
the feature. That way the guest could trust that it has disabled the host from spying or whatever on
it.

to post comments

KVM, QEMU, and kernel project management

Posted Mar 29, 2010 21:03 UTC (Mon) by dlang (guest, #313) [Link] (4 responses)

in many ways this is the same problem as a multi-user machine.

In theory SELinux can protect you, but you really have to trust both it's implementation and it's configuration. This requires placing a large amount of trust the the System Administrator team that you are trying to be protected from.

To some extent you either trust your system administrators or you don't.

If you don't how can you trust that they properly configured SELinux?

If you do, do you really need SELinux to be configured?

things do get a bit messier when you talk about multiple guests on one box and you want to make sure that you don't get attacked from the other guests, but there you can go a long way by simply having each guest run as a different user that has no permissions to anything else on the system (which does take careful auditing of the system, modern linux systems are not put together with multi-user security in mind)

but in my opinion, right now the real answer is that you really don't want to use virtualization as a security critical barrier between hostile parties and their targets.

KVM, QEMU, and kernel project management

Posted Mar 30, 2010 1:30 UTC (Tue) by jeremiah (subscriber, #1221) [Link] (3 responses)

And this is why we don't currently do it, or recommend it to others. I just think it would be nice for
a guest to be able to insure that the host couldn't access it in anyway. I don't think you could do
this in a non linux environment, but maybe though the sys api and have the guest kernel enforce it.
Who knows, but it sure would be nice.

KVM, QEMU, and kernel project management

Posted Mar 30, 2010 3:28 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)

given that the guest doesn't really control it's own ram, but the host OS does, there is no way that the guest can prevent the host OS from examining or changing the ram in the guest, there is no way for the guest to protect itself from the host if the host is malicious.

what is possible in theory is that the host could prevent one guest from escaping then using the host privileges to attack another guest. However this is the same theory that says that one user on a system can be prevented from attacking another user on the same system. That hasn't worked in real life, and I doubt if the protecting one guest form another will work much better.

KVM, QEMU, and kernel project management

Posted Mar 30, 2010 11:21 UTC (Tue) by jeremiah (subscriber, #1221) [Link] (1 responses)

I was thinking the the guest could encrypt or remap it's ram in a fashion that was known only to it.

KVM, QEMU, and kernel project management

Posted Mar 30, 2010 19:57 UTC (Tue) by nix (subscriber, #2304) [Link]

Sure it can. But the host can observe the guest's RAM, so can easily
acquire any necessary encryption keys and do the decryption itself. Even
if it got the key off the network, the host could spy on the network and
capture the key, or spy on the guest and watch the key come in, and then
capture it.

It is simply not possible to protect a VM guest from root on its host. The
host controls *everything*.