Group "vboxuser" grants too many rights

[mampf]

Hello every1,

joining the vboxusers-group on a linux host grants too many rights to the user. You can see this by running any usb-polling program, as your devices might get disconnected.

In particular, please see this bug on launchpad: ​https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/555408 vboxusers-group makes tools like Shotwell (and others) unusable. Also, an user noticed, this is most probably a security problem. This does not occur with VB OSE.

Please fix asap, as this is a show stopper for either VirtualBox or Shotwell. Thanks.

[Technologov]

hmmm... but VBox OSE doesn't have the extra USB functionality.

I am not permissions expert, but I presume that those extra permissions are required for vbox users to be able to plug/unplug USB devices to their VMs. Perhaps others know more.

-Technologov

[Klaus Espenlaub]

I really love those "collect the bug report yourself" type of tickets. Thanks for wasting someone else's time.

To state the obvious: no, this is NOT a security issue since we require explicit administrator decision whether he wants some user to have low-level USB access or not. The administrator should know what he's doing. If those permissions would be handed out to any user just by installing VirtualBox it could be interpreted as a genuine security issue.

Back to "vboxusers". The story about this group is quite simple: VirtualBox installs a medium priority udev rule which puts the "raw" USB devices in this group (normally would be root). This kind of access is needed in the current implementation for forwarding random USB devices to a VM.

From what I read into the sparse information in the bug ticket it looks like libgphoto2 is buggy - it interferes with devices which are anything but usable by it. I could understand that it looks at MSD and some other device types used by cameras, but why would it want to open a USB HID device?

Since no one made any statement that this bug only happens with VirtualBox running (in this case VirtualBox would poll the usb devices too, but in a way which doesn't involve blindly opening random USB devices - we're not crazy) I think this can't be considered a VirtualBox bug.

You could deactivate the udev rule and poke udev to reset the permissions according to the new rule base - and at the same time everyone in the vboxusers group would lose the ability in VirtualBox to forward any USB device to a VM.

I'll leave this ticket open for a bit, but with the current information this is not our bug.

[mampf]

Hi klaus,

I'm sorry you had to collect so much information yourself. I thought all necessary things have been said in launchpad's bug tracker.

I agree with you partly about the security thing. The idea is just: Grant it all or nothing at all (put users in vboxusers or not). Anyway, that's not the matter here.

Yes, gphoto wouldn't need to scan for all devices. But scanning shouldn't disconnect a device, should it?

And well, it only happens when the user is in the vboxusers-group. No need to have VirtualBox running at all. This is what I find interesting. And also, this is not happening in VirtualBox-OSE, of cause.

I'll also file a bug to gphoto2 then, but still I wouldn't except that using any software or having root rights may cause this behaviour. So this might even be a kernel bug? Doesn't the kernel provide some interface to "just scan" for devices?

Thanks for your information, then.

[Klaus Espenlaub]

Have thought about the issue a bit more, and I really think it's a gphoto bug. It has no business whatsoever to talk to random raw usb devices. Don't know what it's doing, but triggering a device reload for everything it can get hold of is plain silly. I can only call gphoto a misbehaving app if it depends on the OS security to prevent messing with stuff it shouldn't have any interest in. Getting a list of USB devices including all sorts of detail doesn't inherently cause such weirdness, see the "lsusb" utility.

[Michael Thayer]

For your information, we have changed the way we handle host USB device access in the current development code (see #7759 for details), and with the new code this issue should not occur. My personal opinion is also that it is a bug in gphoto - there can be perfectly legitimate reasons why a given raw USB device might be accessible to a user, and gphoto should not assume that it can blindly poke any accessible device, or at least not as hard as it clearly does. On the other hand, I don't think our handling of raw USB access, which was what triggered the gphoto bug, was particularly clean, and the changes improve on that.