10.10.2013 22:31, Richard W.M. Jones пишет:
On Thu, Oct 10, 2013 at 10:18:53PM +0400, Michael Tokarev wrote:
10.10.2013 17:44, Richard W.M. Jones wrote:
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.
This is plain wrong. Here's a very recent example:
http://www.openwall.com/lists/oss-security/2013/08/26/3
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).
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.
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.
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
Rich.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
