Bug 429725

I guess you talk about the build service packages.

It seems that your system security setting doesn't allow suid binaries. Is it possible that "PERMISSION_SECURITY" in /etc/sysconfig/security is set to something different than "easy"?
Can you show me the output of "ls -la /usr/lib/virtualbox/VirtualBox"?

Yes I'm talking about the on in the build service, I did not change any of the PERMISSION_SECURITY options and they are still default, I never see the need to change it on any of my systems.  I'm not at the system with 2.0.2, won't be until tomorrow, but on my system with 1.6.2 here is the output (same version on SUSE, different DE this has KDE4 and the machine 2.0.2 is running Gnome)

vendion@SE-03:~> ls -la /usr/lib/virtualbox/VirtualBox
-rwxr-xr-x 1 root root 3300686 2008-06-22 20:46 /usr/lib/virtualbox/VirtualBox

Here is the result of the machine running VirtualBox 2.0.2 

-rwxr-xr-x 1 root root 46004 2008-09-24 03:03 virtualbox/VirtualBox

The permissions are wrong it should be 4711 (in case you want to execute it as
a normal user). But this should be happen automatically if you install the rpm
(as long as your system security level is set to "easy").

(In reply to comment #5 from Marcus Hüwe)
> The permissions are wrong it should be 4711 (in case you want to execute it 
> as a normal user). But this should be happen automatically if you install the 
> rpm (as long as your system security level is set to "easy").

According to
http://forums.virtualbox.org/viewtopic.php?t=9804&sid=2321407d329894a8a9dec5b8adf8c9cf
there is a configure switch --disable-hardening which would avoid the need for the suid bit on several files.

I'm somewhat undecided if giving an application root permissions (via suid bit) really helps to improve security :-/ - even if the configure switch implies something else...

Did you ask the security team about setting the suid bits? If so, what is their opinion?

I have the same problem.
Install via KDE4-Live-CD Beta3 update from the factory reposotory.
The file permission is easy.

the ls -la /usr/lib/virtualbox/VirtualBox output is the same.

*** Bug 441927 has been marked as a duplicate of this bug. ***

What happens if you execute "SuSEconfig -module permissions" after the installation? This should set the correct permissions for the binaries in /usr/lib(64)/virtualbox

This did not help. No permissions of virtualbox changed.

(In reply to comment #10 from Johann-Nikolaus Andreae)
> This did not help. No permissions of virtualbox changed.
> 
What's the output of "grep PERMISSION_SECURITY /etc/sysconfig/security"?

PERMISSION_SECURITY="easy local"

CC'ing the security team. Short summary: VirtualBox requires to be suid-root to do some hardening (at least the configure switch says so, see also comment #6).
Is this OK or would you prefer the --disable-hardening switch?

Editing /etc/permissions.local can be used to make the binary setuid on your system.
We will not make it setuid by default to keep our default installation as secure/unprivileged as possible.

I guess this means VirtualBox should be compiled with --disable-hardening? Else, we just have a non-working VirtualBox by default...

I was just to report the same, this really needs a solution for 11.1:
fm@macbook:~> rpm -qf `which VirtualBox`
virtualbox-ose-2.0.4-4.4

The solution at this point in time is documentation about how to adjust permissions. The security team was not informed about those new requirements in time and we can't audit virtualbox over night. Therefore please turn on all hardening measurements offered by upstream and ship the package without additional permissions. An audit will have to confirm that shipping VirtualBox with setuid permissions indeed doesn't impose an unbearable risk.

If you really want it this way (I don't like it - it will for sure annoy lots of users and cause lots of questions in mailinglists, forums etc.), please

a) add a better error message. The current one is:

       Effective UID is not root (euid=500 egid=100 uid=500 gid=100) (rc=-10)
       It may help to reinstall VirtualBox.

   I'm sure that most people won't understand this - and reinstalling won't 
   help for sure here.

b) add something to the release notes (CC'ing Karl)

But: IMHO the better solution would be to disable the hardening option.

BTW: What will happen if you find out that VirtualBox has a security bug in the to-be-suid-root files? Will you release an update for 11.1 or will you say "hey, we didn't ship it suid-root, so what?"

(moving the bug to 11.1 - not many people will search for it in opensuse.org/3rd party software...

(In reply to comment #18 from Christian Boltz)
> BTW: What will happen if you find out that VirtualBox has a security bug in the
> to-be-suid-root files? Will you release an update for 11.1 or will you say
> "hey, we didn't ship it suid-root, so what?"

Depends on the bug. If the system is broken by design it could very
well happen that a privilege escalation bug is not fixable. We need
the audit to also estimate that risk.

(In reply to comment #19 from Ludwig Nussel)
> (In reply to comment #18 from Christian Boltz)
> > BTW: What will happen if you find out that VirtualBox has a security bug in > > the to-be-suid-root files? Will you release an update for 11.1 or will you 
> > say "hey, we didn't ship it suid-root, so what?"
> 
> Depends on the bug. If the system is broken by design it could very
> well happen that a privilege escalation bug is not fixable. 

Sounds like another argument to disable the hardening for now, which means the suid bit isn't required...

I'd recommend to use --disable-hardening for 11.1 for two reasons:
- it will save users lots of problems (because VirtualBox with hardening will 
  fail to run by default)
- it is more secure than a potential privilege escalation ;-) - and you can be 
  sure that everybody who needs VirtualBox will set the suid bit.
  No, wait - some people might just start it as root...

Well in the setup I was deploying VirtualBox in running it or the system as root is out of the question, having a public system running as root == bad.

setting the setuid bit on a app that was not made for it might be equivalent to running it as root in the first place.

allowing users access to kernel devices that were not made for that might be equivalent to root access.

Just a question are we talking now about the official factory packages or the ones in the Virtualization:VirtualBox repo? Which rpms aren't working?


(In reply to comment #17 from Ludwig Nussel)
> Therefore please turn on all hardening measurements offered by upstream and ship > the package without additional permissions.

Hmm and what about shipping an older (< 2.0.0) working version of virtualbox which doesn't need the hardening?

we are talking about the official factory package:

$ rpm -qif `which VirtualBox`
Name        : virtualbox-ose               Relocations: (not relocatable)
Version     : 2.0.4                             Vendor: openSUSE
Release     : 4.4                           Build Date: Di 11 Nov 2008 23:19:59 CET
Install Date: So 16 Nov 2008 15:23:58 CET      Build Host: build11
Group       : System/Emulators/PC           Source RPM: virtualbox-ose-2.0.4-4.4.src.rpm
Size        : 18244577                         License: GPL v2 or later
Signature   : RSA/8, Di 11 Nov 2008 23:18:40 CET, Key ID b88b2fd43dbdc284
URL         : http://www.virtualbox.org/
Summary     : VirtualBox OSE is an Emulator
Description :
VirtualBox OSE is an extremely feature rich, high performance product
for enterprise customers, it is also the only professional solution
that is freely available as Open Source Software under the terms of the
GNU Public License (GPL).



Authors:
--------
    innotek GmbH <info@innotek.de>
Distribution: openSUSE:Factory

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.
The source file location:
VirtualBox-2.0.4/src/VBox/HostDrivers/Support/SUPR3HardenedMain.cpp

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.
- Running virtualbox as root is much less secure that either of the suid or vboxusers versions.

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.

Choice 4:
 - add virtualbox permissions to permissions package, but comment them out.
 - document the risk connected to uncommenting the lines
 - mention the documentation in the error message, so that users won't be
completely puzzled.

My order of preference: Choice 3, Choice 4, Choice 2, Choice 1

(In reply to comment #23 from Marcus Hüwe)
> 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.

(In reply to comment #26 from Martin Kudlvasr)
> Choice 4:
>  - add virtualbox permissions to permissions package, but comment them out.

Doesn't work. The admin is supposed to only touch permissions.local. The other files are overwritten on update.

> You mean you are going to drop the vboxusers group? I'd keep that
> even with the setuid programs.
I'd keep that too. With permissions of VirtualBox set to rwsr-sr-- (root.vboxusers)

I meant, that in previous versions, vboxusers could access /dev/vboxdrv (kernel interface) directly, with their custom (haxor) tools.
In the current suid version, users can access /dev/vboxdrv only through VirtualBox binary (/dev/vboxdrv can have 0600 permissions). We can harden it even more by allowing only vboxusers to execute VirtualBox binary.

> I'll bring this issue up again in our team meeting on Monday to
> increase the priority of the audit.

Thanks

> Doesn't work. The admin is supposed to only touch permissions.local. The other
> files are overwritten on update.

Ok, so he won't uncomment them, but will copy them to permissions.local. The goal is to have the lines ready for the admin somewhere.

One more option:

Choice 5:
 - add virtualbox suid permissions to permissions.iknowwhatido (or similar name). This way the user will be well informed, that there is a potential security risk.
 - document the risk connected to adding "iknowwhatido" to PERMISSION_SECURITY
 - mention the documentation in the error message, so that users won't be
completely puzzled.
 - adding a single permission category just to solve this one case is not very systematic.

My current order of preference: Choice 3, Choice 5, Choice 4, Choice 2, Choice 1

*** Bug 448046 has been marked as a duplicate of this bug. ***

I have this issue with 11.1 beta5

I won't ship a broken virtualbox-ose - either we find a solution or we take the package out of 11.1, the build service repo doesn't have that audit restriction.

So VB users will go to the online repo and make the whole security audit process pointless ;(

VirtualBox never worked out of the box. One always had to at least add users to the vboxusers group.

After discussion in the team we still don't like adding setuid bits to stuff that did not receive an audit. However given that VirtualBox was considered unsafe before already (/dev/vboxdrv didn't pass an audit) the situation probably cannot get worse as long as we use the vboxusers group. Therefore we would get over the following setup:
- /dev/vboxdrv root:root 0600
- the vbox binaries root:vboxusers 4750

But one always got an useful error when starting VirtualBox. The solution sounds ok to me, at least it's clear what's left to do for the (advanced) user.

This and a README.SUSE in the virtualbox-ose package should do IMO.

as discussed with Ludwig, the README is already part of the package, so the adoption of permissions.easy should be the only change left to fix ala #33

Some changes to virtualbox where needed. I've submitted the package
with the fixes to speed the process up. Most notably
/usr/lib/virtualbox is used always intead of /usr/lib64/virtualbox
to avoid having to list everything twice. That directory contains
only binaries (and their helper libs) so doesn't belong to lib64 anyways.

*** Bug 445405 has been marked as a duplicate of this bug. ***

*** Bug 442723 has been marked as a duplicate of this bug. ***

*** Bug 442810 has been marked as a duplicate of this bug. ***

Coolo, are you going to pull the new virtualbox-ose with the file location changes into 11.1?  The current version in 11.1 doesn't work with x86_64 because permissions.easy just looks in /lib as per #36.

if you'd check factory you'll see that /lib is fine

*** Bug 458113 has been marked as a duplicate of this bug. ***

This is an autogenerated message for OBS integration:
This bug (429725) was mentioned in
https://build.opensuse.org/request/show/89843 Tumbleweed / permissions

This is an autogenerated message for OBS integration:
This bug (429725) was mentioned in
https://build.opensuse.org/request/show/10058 Factory / virtualbox-ose