Vbox error

English Virtualization
1

Vbox had been working a day or two ago, then after an update through yast last night and another this morning, I received a dialog box when starting Vbox stating:


 Effective UID is not root (euid=1000 egid=100 uid=1000 gid=100) (rc=-10)
Please try reinstalling VirtualBox.
where: SUPR3HardenedMain what: 2 VERR_PERMISSION_DENIED (-10) - Permission denied.

I tried to run /etc/init.d/vboxdrv setup, but it didn’t exist.

So through zypper I removed virturalbox and installed the latest RPM from vbox’s site. During the yast install I receive this dialog box:


Error: INVALID:VirtualBox-5.0-5.0.20_106931_openSUSE132-1.x86_64 (file-a8f48320): Signature verification failed [4-Signatures public key is not available]
     Header V4 DSA/SHA1 Signature, key ID 98ab5139: NOKEY
     Header SHA1 digest: OK (18ec161fe6666a57469057eaa98727619a512491)
     MD5 digest: OK (6a4dbdeef5c4b5082f7bd9a9b1c62514)
     V4 DSA/SHA1 Signature, key ID 98ab5139: NOKEY

When I install through the terminal


$ sudo zypper in virtualbox
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 2 NEW packages are going to be installed:
  virtualbox virtualbox-qt

The following recommended package was automatically selected:
  virtualbox-qt

2 new packages to install.
Overall download size: 16.7 MiB. Already cached: 0 B. After the operation,
additional 52.5 MiB will be used.
Continue? [y/n/? shows all options] (y): 
Retrieving package virtualbox-5.0.18-16.1.x86_64
                                           (1/2),  10.5 MiB ( 30.0 MiB unpacked)
Retrieving: virtualbox-5.0.18-16.1.x86_64.rpm ................[done (2.3 MiB/s)]
Retrieving package virtualbox-qt-5.0.18-16.1.x86_64
                                           (2/2),   6.2 MiB ( 22.5 MiB unpacked)
Retrieving: virtualbox-qt-5.0.18-16.1.x86_64.rpm .............[done (1.5 MiB/s)]
Checking for file conflicts: .............................................[done]
(1/2) Installing: virtualbox-5.0.18-16.1.x86_64 ..........................[done]
Additional rpm output:
/sbin/ldconfig: /usr/lib/libbrscandec.so.1 is not a symbolic link

/sbin/ldconfig: /usr/lib/libbrcolm.so.1 is not a symbolic link

/usr/lib/virtualbox/VBoxNetDHCP: will not give away s-bits on an insecure path
ERROR: not all operations were successful.
setting /usr/lib/virtualbox/VBoxNetDHCP to root:vboxusers 4750. (wrong permissions 0750)
/usr/lib/virtualbox/VBoxNetAdpCtl: will not give away s-bits on an insecure path
ERROR: not all operations were successful.
setting /usr/lib/virtualbox/VBoxNetAdpCtl to root:vboxusers 4750. (wrong permissions 0750)
/usr/lib/virtualbox/VBoxHeadless: will not give away s-bits on an insecure path
ERROR: not all operations were successful.
setting /usr/lib/virtualbox/VBoxHeadless to root:vboxusers 4750. (wrong permissions 0750)
/usr/lib/virtualbox/VBoxSDL: will not give away s-bits on an insecure path
ERROR: not all operations were successful.
setting /usr/lib/virtualbox/VBoxSDL to root:vboxusers 4750. (wrong permissions 0750)
warning: %post(virtualbox-5.0.18-16.1.x86_64) scriptlet failed, exit status 1


(2/2) Installing: virtualbox-qt-5.0.18-16.1.x86_64 .......................[done]
Additional rpm output:
/usr/lib/virtualbox/VirtualBox: will not give away s-bits on an insecure path
ERROR: not all operations were successful.
setting /usr/lib/virtualbox/VirtualBox to root:vboxusers 4750. (wrong permissions 0750)
warning: %post(virtualbox-qt-5.0.18-16.1.x86_64) scriptlet failed, exit status 1

Any ideas how to proceed?
Thanks

2

Yes, and it’s not necessary either because openSUSE’s packages contain a precompiled kernel module.

It wouldn’t have helped with your permission problem anyway.

/usr/lib/virtualbox/VirtualBox: will not give away s-bits on an insecure path

Any ideas how to proceed?

Run “sudo chkstat --system” and post the output.

And I would recommend to uninstall VirtualBox-5.0 from Oracle again and use openSUSE’s version instead.
With Oracle’s package you have to run
But that’s your own choice.

3

Thanks for responding!


$ sudo chkstat --system
root's password:
Checking permissions and ownerships - using the permissions files
    /etc/permissions
    /etc/permissions.easy
    /etc/permissions.d/postfix
    /etc/permissions.d/texlive
    /etc/permissions.local
setting / to root:root 0755. (wrong permissions 0775)
setting /usr/ to root:root 0755. (wrong permissions 0775)

I actually did have OpenSUSE’s rpm installed first when it was running without issue. Through zypper I removed it and installed it again, but still had the same error. While searching on the web for a fix, I came across this SDB
which I thought was odd to refer the source of the rpm to Oracle and not the repos. Both rpms result in the same error.

4

Usually that means that you’re invoking using your normal User account.

How are you invoking your Virtualbox, from a console or a menu item?

Regardless, try invoking Virtualbox from a root console to verify my suspicion is correct.
Or, use “sudo” when invoking.

TSU

5

I open the VBox manager from the xfce menu, the errors occurs when I start the VBox manager. Ie, the manager is not open and the errors occur when I start a VM.

From the CLI


$ virtualbox
If 'virtualbox' is not a typo you can use command-not-found to lookup the package that contains it, like this:
    cnf virtualbox
$ sudo virtualbox
root's password:
sudo: virtualbox: command not found

I have removed Vbox and installed the package from the result of a virtualbox package search

Once installed I can start the VBox Manager from the menu and I get a similar error that I would see in Debian after a kernel upgrade:


Kernel driver not installed (rc=-1908)
The VirtualBox Linux kernel driver (vboxdrv) is either not loaded or there is a permission problem with /dev/vboxdrv. Please reinstall the kernel module by executing
'/sbin/rcvboxdrv setup'
as root. If it is available in your distribution, you should install the DKMS package first. This package keeps track of Linux kernel changes and recompiles the vboxdrv kernel module if necessary.
where: suplibOsInit what: 3 VERR_VM_DRIVER_NOT_INSTALLED (-1908) - The support driver is not installed. On linux, open returned ENOENT. 
The virtual machine 'Windows XP' has terminated unexpectedly during startup with exit code 1 (0x1).

| Result Code: | NS_ERROR_FAILURE (0x80004005)
|---|
|
| Component: 
| MachineWrap|
| Interface: | IMachine {f30138d4-e5ea-4b3a-8858-a059de4c93fd}
|

I did not execute sudo /sbin/rcvboxdrv setup.

DKMS wasn’t installed so I installed it and rebooted. A little later I received a prompt from YaST about 4 VirtualBox updates and installed them. I can now open my VMs without error. Hopefully this is solved. One thing that I have noticed since I installed Leap 42.1 a couple months ago is a very small dialog box that is briefly shown as xfce starts, something about a virtualbox client is not running, so stopping.

If all my VMs open without error, I’ll mark this as solved.

6

So as I expected, / and /usr/ had wrong permissions.
This has been fixed by chkstat so it should work now if you reinstall the virtualbox packages.

Of course. How else would you invoke it?
As long as the user is in the group “vboxusers”, it should work when run as user (if not, you would get a different error message though).

Regardless, try invoking Virtualbox from a root console to verify my suspicion is correct.
Or, use “sudo” when invoking.

Please, don’t advise such nonsense.
First, you should not run VirtualBox as root.
Second, running it with “sudo” won’t work at all anyway. You cannot use sudo to run graphical applications in openSUSE.

The command is “VirtualBox”, with 2 uppercase letters.

I have removed Vbox and installed the package from the result of a virtualbox package search

Please, don’t install random packages, and maybe even a mixture of different versions.

I did not execute sudo /sbin/rcvboxdrv setup.

As I wrote, you only have to do that if installing Oracle’s package.

DKMS wasn’t installed so I installed it and rebooted.

DKMS is useless too, if you use openSUSE’s packages.
It would help with Oracle’s package though, you wouldn’t have to run “vboxdrv setup” manually after each kernel update.

A little later I received a prompt from YaST about 4 VirtualBox updates and installed them. I can now open my VMs without error. Hopefully this is solved.

Yeah, the reinstallation probably fixed the file permissions now and/or installed the correct kernel module package.

Just in case, please post the list of installed packages now:

rpm -qa | grep -i virtualbox

One thing that I have noticed since I installed Leap 42.1 a couple months ago is a very small dialog box that is briefly shown as xfce starts, something about a virtualbox client is not running, so stopping.

Hm, never seen anything like this.
Can you please post the exact message?

7 

$ rpm -qa | grep -i virtualbox
virtualbox-guest-tools-5.0.18-16.1.x86_64
virtualbox-guest-x11-5.0.18-16.1.x86_64
virtualbox-qt-5.0.18-16.1.x86_64
virtualbox-5.0.18-16.1.x86_64
virtualbox-guest-kmp-default-5.0.18_k4.1.21_14-16.1.x86_64
virtualbox-host-kmp-default-5.0.18_k4.1.21_14-16.1.x86_64

I didn’t see the small pop-up at start up. The re-install fixed what had been missing I guess. But if it does appear, I will post the contents.

The VirtualBox Manager and alll my VMs open correctly, without error so I’m marking this solved. Thanks for the help!!!

8

Looks ok.
You could uninstall virtualbox-guest-x11 and virtualbox-guest-tools though if you want, they are not needed on the host.

Btw, these are the standard versions shipped in Leap 42.1, you could have just installed them with YaST or zypper too.
No need for the package search page… :wink:

The VirtualBox Manager and alll my VMs open correctly, without error so I’m marking this solved. Thanks for the help!!!

Nice to hear.

9

So, you’re one of “those” people who believe that virtualization services in general should be accessible by a normal User? It’s a convenience acceptable only because of the weight of User wishes, and is not grounded in fundamental secure concepts which suggests that any normal User access to the very dangerous functions to create, modif and delete anything that has almost unlimited power on your machine and in your network is worrisome at best.

In general though, I think you and I are on the same track that the upgrade likely modified permissions in an unexpected way. My recommendation at least tests for what happened, and if a User wants to leave security at the higher level would then understand how to manage the situation. On the other hand, if the User wants to invoke VBox as a normal User, then as you’ve described the User and the file permissions should be modified to belong to the vboxusers group.

And, IMO there is hardly any difference between using sudo (or similar) or possibly a root console to invoke VBox. There may be a difference in what the Vbox application itself might be permitted to do, but IMO there is no difference at all in restricting who can invoke Guests and what any Guest can do. This is why most enterprise management of virtualization don’t mess around with groups like vboxusers, they require root access.

TSU

10

Wolf,

The original install was via zypper and this install was the one in which that I had these errors. I installed the package from my “package search” result just to insure that I was installing an “official” rpm and non OpenSUSE rpm.

Again, thanks for the help and input!

11

No, I never wrote that.
And VirtualBox is not accessible by a normal user, you need to be part of the “vboxusers” group.

The point was that you should not run the VirtualBox GUI as root, and you cannot even do that with sudo anyway.

Again, in the default openSUSE setup, sudo is not able to run GUI applications at all.

In general though, I think you and I are on the same track that the upgrade likely modified permissions in an unexpected way. My recommendation at least tests for what happened, and if a User wants to leave security at the higher level would then understand how to manage the situation. On the other hand, if the User wants to invoke VBox as a normal User, then as you’ve described the User and the file permissions should be modified to belong to the vboxusers group.

Yes. The package uses chkstat to modify the file permissions after the installation (to enable users of the group “vboxusers” to start it), but that just bails out if the permissions for / or /usr are wrong (i.e. insecure).

And, IMO there is hardly any difference between using sudo (or similar) or possibly a root console to invoke VBox.

There is a difference: it won’t work with sudo… :wink:

And I repeat, you should not run the GUI as root anyway.

12

I know.
But as long as you don’t add 3rd party repos, YaST and zypper can only install the “official” packages anyway…

Again, thanks for the help and input!

You’re welcome.

13

VBoxClient: the VirtualBox kernel service is not running. Exiting.

This prompt appears at login as the WM starts. I thought it had stopped but I must have missed the prompt yesterday. After some searching last night and assuming that client = guest I;


$ sudo zypper remove virtualbox-guest-tools-5.0.18-16.1.x86_64 virtualbox-guest-x11-5.0.18-16.1.x86_64 virtualbox-guest-kmp-default-5.0.18_k4.1.21_14-16.1.x86_64

The prompt has not since displayed.

14

In the vein of a friendly discussion on what I generally consider a topic I consider mostly based on chauvinism (no criticism, just my opinion of the topic’s backers on each side don’t often base their opinion on solid principles),

Adding a User to the vboxuser’s group does not change the fact that the logged in User is a normally unprivileged account, but by creating a vboxuser’s group and adding the continually logged in User is tantamount to running with root permissions all the time. The diff obviously is that a member of the vboxuser’s group can’t directly and immediately compromise the running system like root can, but is handed the potential to compromise the local network, Workgroup security and files (yes, I’m looking at all of you who set up no-password network shares), all leading also to a <possible> indirect compromise of the local system eventually.

This might not be that big a deal if the User is diligent in recognizing the risk and taking extra precautions to protect the logged in User’s account and disabling the virtualization app and services when not in use, but I don’t think very many people who run virtualization think about this. This has all been thoroughly discussed historically, and enterprise management apps generally address this but I see hardly any mention on individual systems, so if you are responsible for more than just yourself… be aware of what you are doing.

NOTE that this has <nothing> to do with whether the vbox application “server” part of the application is running under whatever security context, it’s the User Tools (eg The Virtualbox Manager and command line line vboxmanage) although the server-side should always be running in a non-interactive account context (never something like vboxusers or anything else, maybe not even root).

As for sudo, it was just thrown out there to be tried.
Yes, most graphical apps don’t run with sudo (you have to su if you want elevated permissions) but some do launch.

TSU

15

No, it is not.

It allows that specific user to run VirtualBox, but does not allow him to run anything with root permissions.
And it makes it unnecessary to run the VirtualBox GUI as root.

And root is the only one that can allow to become a user member of the group vboxusers anyway.

Another point is that running VirtualBox, the GUI, as root will not allow you to use your user’s VM’s anyway, as they are stored in the user’s home directory by default.
But that’s a different story…

As for sudo, it was just thrown out there to be tried.
Yes, most graphical apps don’t run with sudo (you have to su if you want elevated permissions) but some do launch.

No, none will launch with sudo in a standard openSUSE setup.
They won’t find the user’s X session to open a window in.

If you want to run graphical applications as root, you have to use kdesu, gnomesu, or xdg-su (which in turn will use one of the former, or “su -”, depending on what desktop you use).

16

I think you are completely mis-understanding the point I make that the the permissions granted by being a member of the vboxusers group is extensive and potentially damaging (not necessarily picking on VBox. Anyone who sets up similar security for any virtualization suffers the same, which is one of the points I recommended should be changed in the openSUSE community docs for other virtualization).

If an exploiter who has compromised the running User account can create and/or run a virtual machine, that is all the Exploiter has <full> root permissions in any Guest he is able to run including installing and running any application he wishes.(unlike on the original HostOS). The kinds of things that can be done is virtually limitless and would severely test security on the HostOS (The Guest can start attacking the Host) and any other machine it can find on the LAN.

In other words, although the exploiter using the compromised User account might not have immediate root access, it’s very nearly the same.

So, then the next question is if you really, really believe that no one should log in as root.
If you don’t believe that Users should log in as root, then you should agree that the normal, unprivileged User account should be <clearly> unprivileged, unable to create and run things that are nearly capable as root.

I firmly believe that anything installable or installed should always be <secure by default>. If the User wants to compromise security, then it should be by their own action (can be as easy as simply clicking a button).

TSU

17

Sorry, I don’t understand your point at all.

Actually I think you are completely misunderstanding the implications of making some user a member of the group “vboxusers”.

If an exploiter who has compromised the running User account can create and/or run a virtual machine, that is all the Exploiter needs to gain tremendous information about the network, installing and running any application one wishes in that Guest which is of course not restricted from installing and running any application (unlike on the original HostOS). The kinds of things that can be done is virtually limitless and would severely test security on the HostOS (The Guest can start attacking the Host) and any other machine it can find on the LAN.

If you want to avoid that, just don’t make any user member of the group “vboxusers”.

But how is running VirtualBox as root any better in this regard?
Then even the VirtualBox GUI can be exploited to do everything on the host.

And if the root account is compromised, you have the same (and even worse) problems anyway…

In other words, although the exploiter using the compromised User account might not have immediate root access, it’s very nearly the same.

Again, it’s not.

A member of the group “vboxusers” does not have root access at all on the host.

That’s the point of having a special group for this.

The guest is a different story though, of course anybody who can run a guest has all privileges in the guest.
But that’s also one point of using Virtualization, to differentiate between the guest and the host, particularly regarding to permissions.
I hope you agree there at least.

So, then the next question is if you really, really believe that no one should log in as root.
If you don’t believe that Users should log in as root, then you should agree that the User account should be <clearly> unprivileged, unable to create and run things that are nearly capable as root.

The point is that the user account is still <clearly> unprivileged in every other regard on the host, except for running VirtualBox.

18

That’s what is puzzling me in Tsu’s answer. Running as user, regardless of belonging to a special group or not, can’t be as vulnerable as running as root, correct? Else everything I read about security in the last decades is wrong! :open_mouth:

19

But ultimately only what the user, as owner of the VM process, have access to would be compromised, right?
OTOH, if the VM is run as root, all that the root has access would then be compromised, i.e., the whole system, and not only the user files.

I’m not stating categorically - I’ve learned long ago that “hard truths” usually have nuances. I’m just trying to understand how running as root could ever be better than not running as root.

20

Let’s see if I can describe the issue as uncomplicated as possible…

And, I remind anyone reading this that what I’m describing here is not in any way new, these kinds of things were discussed to death about 10 years ago until everyone stopped probably due to exhaustion. But, IMO it’s sometimes useful to re-visit a topic years later when advances in technology might cause some to re-evaluate because advances in technology make exploits more likely.

Forget for a moment that we’re talking about virtualization, and let’s consider an old-school physical scenario which is still very much possible today (see my Bloomberg article reference below).

If some anonymous person in the dead of night mysteriously sneaked into your building and did 2 things…

  1. Gained root access to not your machine, but some other machine on your network, re-configured and installed stuff you know not what, and then left quietly. Maybe hecause he has root access he even took the time to remove any indication he was present (like deleting or modifying the logs).

  2. He brought a machine with him, hid it somewhere on the premises attached to your network behind your Internet firewall running whatever he wants. BTW - If you have time and interested in reading about a real world example how this happened not long ago in Amsterdam’s shipping offices, Bloomberg published this story
    http://www.bloomberg.com/graphics/2015-mob-technology-consultants-help-drug-traffickers/

Now, consider that the above two scenarios exploiting a network using real, physical devices can be easily accomplished virtually with a compromised User account on a machine which has immediate access to full virtualization management. NOTE I’m using Virtualbox references <only> because it creates the vboxusers group and by default makes the logged in User a member of that account without asking the User whether to do so. Granting a User full virtualization management permissions is not unique to vbox and entirely applies to any other virtualization if an ordinary User account is given immediate access to virtualization management tools.

The following can be accomplished of course whether you have access to a graphical Desktop or not… It’s also all scriptable for execution from the command line.

The first scenario can be replicated in an existing virtual machine by the following steps (more or less)

  • “Run” an existing virtualbox Guest machine if it’s not already running.
  • Try a few password guesses if necessary to log into the Guest machine, but don’t try too hard. If no guess works, then break in using a modified grub boot or set the Windows password to null. If the machine is Windows then because the OS does not support multi-user, it’s a bit different but still not hard to overcome. You might have to initiate a shutdown/reboot since Windows is not multi-user, but I doubt many/most Admins are going to notice this if you can eventually leave the machine appearing as you found it. If Network security (ie AD/LDAP or similar) then it’s a bit more complicated, again.
  • Do whatever you wish once you have broken in. Hide your actions if necessry.
  • Logout if the machine isn’t already running so when the User logs in, he won’t be suspicious.

The second scenario introducing a new, hidden machine can be replicated by the following steps (more or less)

  • Determine Workgroup/Domain of the HostOS
  • Determine if DHCP is running and what type of networking is appropriate for a new machine to operate on the same network
  • Determine available install resources from how the HostOS is installed and reading saved VBox machine install sources (The saved virtualcdrom config list).
  • Create a new virtual machine. Be sneaky, if you think your machine won’t be noticed, then store it with other machines. If you think your machine would be noticed, store it elsewhere.
  • Whether you have access to a graphical desktop or not, invoke the virtual machine from the command line so that the logged in User won’t see the virtual machine listed in Virtualbox Manager. This takes advantage of the fact that you can launch multiple instances of Virtualbox Manager (or from a command line) without causing a conflict.
  • When done,lLeave the machine appearing as you found it.

The bottom line is that these kinds of scenarios can be prevented by simply requiring elevated permissions to access virtualization management tools.

TSU