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

KVM, QEMU, and kernel project management

Posted Mar 26, 2010 21:47 UTC (Fri) by dlang (guest, #313)
In reply to: KVM, QEMU, and kernel project management by rahvin
Parent article: KVM, QEMU, and kernel project management

in many cases you don't trust the people who have admin access inside the guest. As such you don't want this to involve anything that they could tinker with. This rules out any guest assisted schemes.

to post comments

KVM, QEMU, and kernel project management

Posted Mar 27, 2010 1:57 UTC (Sat) by rahvin (guest, #16953) [Link] (7 responses)

That's what I meant to say with the security reasons comment. If that's not what I said your comment is an adequate clarification.

Basically you can't trust the guests and the guests can't trust the host as well. Contracted hosting is an interesting situation because neither group can realistically trust the other with their data because they don't screen each other's employees. Maybe there are hosting companies that offer to assign management screened by the contractee but it would seem easier to just put your own server in their rack and manage the whole thing yourself, otherwise you have to deal with a situation where no one can trust each other. So Emperor Mingo's comment that perf needs to be runnable without guest client access (or guest host access) is the reality of data center VM.

KVM, QEMU, and kernel project management

Posted Mar 27, 2010 2:12 UTC (Sat) by dlang (guest, #313) [Link] (6 responses)

I disagree with you a bit.

I see it that the host does not want to trust the guest, but to a large extent the guest has no choice but to trust the host. There are just too many things that the host can do to the guest.

Remember the host has control of your cpu, your ram, and all your I/O

If the host really wants to it can search through the physical ram looking for 'interesting' data in the guest. the guest can try to keep things encrypted, but it has to store the encryption key somewhere, and wherever it is stored the host can get at it.

you can try to lock down the host to prevent it from getting at part of it's own resources (this is the type of thing that SELinux is designed for), but doing this completely is a very hard task, if it's even possible.

KVM, QEMU, and kernel project management

Posted Mar 29, 2010 19:07 UTC (Mon) by jeremiah (subscriber, #1221) [Link] (5 responses)

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.

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*.