https://bugzilla.novell.com/show_bug.cgi?id=429725
User lnussel@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=429725#c27
Ludwig Nussel
Hmm and what about shipping an older (< 2.0.0) working version of virtualbox which doesn't need the hardening?
IIRC an audit was aborted because previous versions already had grave security problems with the kernel interface. So shipping an old version doesn't improve anything. (In reply to comment #25 from Martin Kudlvasr)
As far as I have read the code, virtualbox uses the suid root ONLY to open /dev/vboxdrv. Right after that, setresuid is used to set privileges of the process to uid (and gid) of the user. The process is very well commented (surprisingly well) in the source files.
Good to hear. An Audit will hopefully confirm that it's indeed safe.
Please consider these arguments when making the decision: - Users had access to the kernel module until now through group vboxusers In the suid version, they still have access to it, but only through virtualbox binary. The suid version is actually reducing access to the kernel module.
You mean you are going to drop the vboxusers group? I'd keep that even with the setuid programs.
- Running virtualbox as root is much less secure that either of the suid or vboxusers versions.
That's a misconception. A kernel interface that allows you to change arbitrary things in kernel space as user is is almost equivalent to root access with the exception that you don't know it (which makes it even worse). So in this situation it is only honest to require authentication as root.
So far I see 3 options
Choice 1 (lnussels, if I understood correctly): - do not add virtualbox permissions to permissions package - document, that virtualbox can be run only as root. - mention the documentation in the error message, so that users won't be completely puzzled.
Choice 2: - do not add virtualbox permissions to permissions package - document, how users can add permissions to /etc/permissions and set virtualbox suid by hand (and SUSE/security will deny responsibility for the risk) - mention the documentation in the error message, so that users won't be completely puzzled.
Choice 3: - add virtualbox permissions to permissions package. - imho most secure.
My order of preference: Choice 3, Choice 2, Choice 1
I ask the security team for the final decision, whatever will that be.
I'll bring this issue up again in our team meeting on Monday to increase the priority of the audit. Until the Audit is done my suggestion is 1+2 as you always have the choice to add your binaries to permissions.local or to run virtualbox via su/sudo. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.