Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23

Thread: Vbox error

  1. #11

    Default Re: Vbox error

    Quote Originally Posted by tsu2 View Post
    So, you're one of "those" people who believe that virtualization services in general should be accessible by a normal User?
    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...

    And I repeat, you should not run the GUI as root anyway.
    Last edited by wolfi323; 03-Jun-2016 at 09:23.

  2. #12

    Default Re: Vbox error

    Quote Originally Posted by ramack View Post
    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.
    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.

  3. #13

    Default Re: Vbox error

    Quote Originally Posted by wolfi323 View Post
    Hm, never seen anything like this.
    Can you please post the exact message?
    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;
    Code:
    $ 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.

  4. #14
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    13,295
    Blog Entries
    2

    Default Re: Vbox error

    Quote Originally Posted by wolfi323 View Post
    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.


    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).


    There is a difference: it won't work with sudo...

    And I repeat, you should not run the GUI as root anyway.
    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
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  5. #15

    Default Re: Vbox error

    Quote Originally Posted by tsu2 View Post
    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.
    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).
    Last edited by wolfi323; 04-Jun-2016 at 14:35.

  6. #16
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    13,295
    Blog Entries
    2

    Default Re: Vbox error

    Quote Originally Posted by wolfi323 View Post
    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...
    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
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  7. #17

    Default Re: Vbox error

    Quote Originally Posted by tsu2 View Post
    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).
    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.
    Last edited by wolfi323; 04-Jun-2016 at 16:29.

  8. #18
    Join Date
    Aug 2008
    Location
    Brazil
    Posts
    3,278

    Default Re: Vbox error

    Quote Originally Posted by wolfi323 View Post
    But how is running VirtualBox as root any better in this regard?
    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!

  9. #19
    Join Date
    Aug 2008
    Location
    Brazil
    Posts
    3,278

    Default Re: Vbox error

    Quote Originally Posted by tsu2 View Post
    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.
    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.

  10. #20
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    13,295
    Blog Entries
    2

    Default Re: Vbox error

    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/20...g-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












    -
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

Page 2 of 3 FirstFirst 123 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •