LWN: Comments on "LinuxCon: Secure virtualization with sVirt"

LinuxCon: Secure virtualization with sVirt

vonbrand — 2009-10-12T02:04:41+00:00

On the other hand, path-based approaches like AppArmor are very easy to use. But they had not gained any traction within the security community. Probably, because it's too easy to use.

In Unix, the same object can be accessed by wildly different paths (think links) or can move around, so this won't give much security. That it is easy to use makes no difference if it is easy to bypass.

You also misrepresent the security community: A mechanism that is hard to understand and use won't be secure in practice, and they do know that very well; so they are looking for simple to use mechanisms.

All VMs run as the same user...

danpb — 2009-09-28T17:35:30+00:00

The ability to run KVM as non-root is already in libvirt. In Fedora 12 all 'qemu:///system' connections run VMs under a dedicated 'qemu' user account, while 'qemu:///session' connections run VMs under the UID of the user using that connection.

Also in Fedora 12, /dev/kvm has mode 0666 out of the box, allowing qemu:///session uses to use KVM acceleration.

The libvirt security architecture that deals with sVirt is modular allowing arbitrary security plugins. The Ubuntu devs have got an impl using AppArmour. It would also be possible to write an impl that ran each VM as a unique user ID.

All VMs run as the same user...

nix — 2009-09-27T10:22:03+00:00

That would be extremely interesting, thanks. (I didn't realise the
namespaces stuff was at a usable state yet, but I haven't been paying much
attention to it.)

All VMs run as the same user...

rwmj — 2009-09-26T10:17:13+00:00

There you have it. Thanks Avi :-)

All VMs run as the same user...

avik — 2009-09-26T09:04:10+00:00

It's safe. Access to /dev/kvm doesn't give any access to other virtual machines.

Of course, if a process has access to another process (via kill(2) or ptrace(2)) it can affect or access data belonging to that process. So if you run all virtual machines as the same user, you need to further isolate them. I believe sVirt does that with its random selinux contexts. but I'm no selinux expert.

All VMs run as the same user...

rwmj — 2009-09-26T07:19:51+00:00

It's a good question. I talked to Gleb and Avi about this a few months back, and I came away with
the impression that it was safe. _However_ rereading their responses this morning, I'm now not so
sure it provides isolation between users who have VMs on the same system, so I guess I'm going to
have to dig into the code and check it myself.

Rich.

All VMs run as the same user...

Cato — 2009-09-26T06:22:05+00:00

Worse than that, presumably anyone wanting to write to kernel data structures can just write to /dev/kvm.

All VMs run as the same user...

smoogen — 2009-09-25T20:19:33+00:00

Would not those permissions still allow for any process to look at another one through the device?

All VMs run as the same user...

lutchann — 2009-09-25T20:10:18+00:00

In addition to using one UID per KVM instance, use the new native container features in Linux to put each KVM into its own container. With an extremely limited view of the filesystem, namespaced process tables and IPC, an empty capabilities bounding set and appropriate iptables OUTPUT rules, breaking out of the VM into the KVM process does an attacker no good. No SELinux necessary.

With such a setup, the only thing you have to pray for is that there are no vulnerabilities that allow a guest VM to break into the host's ring 0. Unfortunately, such bugs have already been discovered in Xen.

(I can share my C wrapper for containerizing KVM if anybody's interested. Post a followup to this comment and I'll tar it up and post it somewhere.)

All VMs run as the same user...

rwmj — 2009-09-25T11:29:16+00:00

You can chmod 0666 /dev/kvm if you want to run KVM as non-root with hardware acceleration. (I
run it like this all the time).

The ability to run KVM processes as non-root is something that is to be added to libvirt in the near
future.

All VMs run as the same user...

smoogen — 2009-09-24T17:44:32+00:00

I believe (and this is a weak belief from too little research) that most VM's have to run with root priveledges at some place in their structure (this is to get use of the hypervisor CPU accelerations). Most of the people I know who are researching 'escapes' usually find the way out of the VM cage is in those areas.. thus the breakout has root access already.

The aim is with any of the security mechanisms is to limit what that root can do.

All VMs run as the same user...

epa — 2009-09-24T11:00:33+00:00

If, as the article notes, all virtual machines run as the same user on the host system, wouldn't it make more sense to fix that by running each VM as a separate user and using classical Unix permissions?

LinuxCon: Secure virtualization with sVirt

danpb — 2009-09-24T09:41:54+00:00

If you look at the Xen vulnerabilities there has been a good split between flaws in the hypervisor/host kernel, and flaws in the QEMU device model. sVirt doesn't claim to protect the kernel, but it does offer valuable protection against QEMU device model flaws.

LinuxCon: Secure virtualization with sVirt

Cyberax — 2009-09-24T09:28:13+00:00

"As they learned from the Xen compromise, leaving the labeling up to administrators does not work"

Yeah, have they _seen_ the complexity of SELinux policies? It's no wonder that most administrators dare not touch SELinux. Personally, I usually just pray that it works.

On the other hand, path-based approaches like AppArmor are very easy to use. But they had not gained any traction within the security community. Probably, because it's too easy to use.

LinuxCon: Secure virtualization with sVirt

djm — 2009-09-24T08:42:28+00:00

Let me get this straight: an attacker has gained access to a VM, escalated
privilege, escaped the (probably-hardware assisted) VM containment and they
think that more OS-level controls will prevent the same thing happening in
the host OS? IMO it is more likely that they escaped the VM by exploiting
bugs in the host OS kernel to begin with so sVirt couldn't help anyway...