Package: qemu-kvm
Version: 0.14.1+dfsg-4
Severity: wishlist

Hi,

It would be nice if /dev/kvm were world-accessible, so that unprivileged
users could use hardware virtualization features without needing to be
added to the kvm group in advance by a system administrator.

Currently the following rule is in place:

geofft@leveret:/lib/udev/rules.d$ cat 60-qemu-kvm.rules
KERNEL=="kvm", GROUP="kvm", MODE="0660"

I'd like that to be changed to mode 0666. Fedora has decided that this is
okay in terms of security, and that this is a useful change to be made. On
my Fedora 15 box, the following rule is in place:

busy-beaver:/etc/udev/rules.d geofft$ less 80-kvm.rules
KERNEL=="kvm", GROUP="kvm", MODE="0666"

(I don't understand why it's in /etc, but it is in fact packaged in
qemu-system-x86-0.14.0-7.)

See also "We have already reserved a group called 'kvm' in the setup
package, so no need for yet another called 'vm'. The /dev/kvm should be
chgrp kvm by default. That said I agree with Mark that it'd be desirable
to also make it possible to just any normal user access to /dev/kvm out of
the box, so libvirt's per-user qemu:///session connection can be used"
from https://bugzilla.redhat.com/show_bug.cgi?id=481260 .

I'm working on a software package that would benefit from unprivileged
remote users being able to access kvm, so this change would be beneficial
to me. It sounds from the above text that this would also make using
libvirt easier.

Thanks,

tags 640328 + wontfix
thanks

With the amount of past security issues with in-kernel kvm module
this wont happen in a reasonable future.  This has been discussed
previously, mode 0666 has been proposed initially but given up
later.

You can surely override this conffile locally on any machine you
set up.

[]

I think maybe in squeeze+1 we can think about it more, that time
in qemu package (since qemu-kvm most likely wont be present in
wheezy being merged into qemu proper fully).

/mjt

In Fedora we have had /dev/kvm mode 0666 for years.  It was changed
that way in July 2009.

There has never been a security problem attributable to this.

There is no problem with having any user create a VM.  Virtual
machines are regular processes, subject to all the usual ulimits.
They use regular malloc'd memory.

Furthermore small appliances are useful for security: for sandboxing
single tasks, and for securely accessing filesystems.

Rich.

10.10.2013 17:44, Richard W.M. Jones wrote:

This is plain wrong.  Here's a very recent example:

http://www.openwall.com/lists/oss-security/2013/08/26/3

That's righ, except that /dev/kvm is also kvm.ko with their own set
of controls and bugs like the above.  And this is what the whole
thing is about, -- additional security holes due to access to /dev/kvm.

/mjt

This causes [on ARM only] the program running the bad ioctl to oops.
(I see no evidence of this causing "host OS crash" -- just an oops in
the calling process).

Obviously you fix kernel bugs, and you would have to fix this one
anyway.

Now compare this to the large number of filesystem bugs around, which
can be prevented by only mounting filesystems in appliances.

Rich.

10.10.2013 22:31, Richard W.M. Jones пишет:

Yes, I just took some more or less recent example.  There were others,
much more serious (with access to kernel memory).

The point is to be possible to give access to the device in question
to users "only", not to, say, network-facing daemons who will be able
to root the system at the end using another /dev/kvm hole.

It is a principle of least privilege, at its good side.

You know this user needs to run qemu/kvm, so give access to /dev/kvm
to him/her.  Don't give extra privileges to users/subsystems which
don't need them.  That's nothing more than that.

Sure, and filesystem bugs may lead to very serious issues too.
But I never said running such appliances is a bad thing or that we
must restrict access to /dev/kvm for them.  Maybe it is a good idea
to give "console" user access to /dev/kvm so [s]he can run appliances,
or [s]he may as well just use libvirt.

Note that this last point basically makes whole topic more or less
moot: there's no good need to give access to /dev/kvm to "strangers".
Those users who run qemu/kvm manually are pretty much capable of adding
themselves to kvm group.  THe rest are using some management layer
like libvirt, which takes care of this using other means.

Thanks,

/mjt