virtualbox: enable hardening

[ryandesign (Ryan Carsten Schmidt)]

When building virtualbox, this appears in the log:

:info:configure 
:info:configure   +++ WARNING +++ WARNING +++ WARNING +++ WARNING +++ WARNING +++ WARNING +++
:info:configure   Hardening is disabled. Please do NOT build packages for distribution with
:info:configure   disabled hardening!
:info:configure   +++ WARNING +++ WARNING +++ WARNING +++ WARNING +++ WARNING +++ WARNING +++
:info:configure 

So since MacPorts is distributing binary packages of ports, I guess we should enable hardening, whatever that means.

[cp@…]

Hi,

I am one of the VirtualBox developer. Ryan told us about the new VirtualBox port. We like it to have it supported by MacPorts, but not enabling hardening is a no go. As the warning says, such packages should not used in production environments and also not provided to users for security reasons. To help you with that, I checked what have to be done in the OSE version to create a version with hardening enabled. The following are only minimal changes to your current config, so I hope you will integrate them soon.

1. Remove the --disable-hardening configure switch

2. Add the following to the LocalConfig.kmk you create with the patches

     VBOX_PATH_APP_PRIVATE="/Applications/MacPorts/VirtualBox.app/Contents/MacOS"
     VBOX_PATH_APP_PRIVATE_ARCH="/Applications/MacPorts/VirtualBox.app/Contents/MacOS"
     VBOX_PATH_SHARED_LIBS="/Applications/MacPorts/VirtualBox.app/Contents/MacOS"
     VBOX_PATH_APP_DOCS="/Applications/MacPorts/VirtualBox.app/Contents/MacOS"
     # Disable the building of any test apps
     VBOX_WITH_TESTSUITE=
     VBOX_WITH_TESTCASES=
     # Disable the build and splitting of the debug symbols
     kBuildGlobalDefaults_LD_DEBUG=
   

3. Build VirtualBox

4. Install VirtualBox to /Applications/MacPorts/

5. Execute the following to meet the VirtualBox path requirements

   sudo chown -R root:admin /Applications/MacPorts/VirtualBox.app/
   sudo chmod u+s /Applications/MacPorts/VirtualBox.app/Contents/MacOS/VirtualBox
   sudo chmod u+s /Applications/MacPorts/VirtualBox.app/Contents/MacOS/VirtualBoxVM
   sudo chmod u+s /Applications/MacPorts/VirtualBox.app/Contents/MacOS/VBoxHeadless
   sudo chmod u+s /Applications/MacPorts/VirtualBox.app/Contents/MacOS/VBoxNetAdpCtl
   sudo chmod u+s /Applications/MacPorts/VirtualBox.app/Contents/MacOS/VBoxNetDHCP
   

6. Make sure that all directories parts within /Applications/MacPorts/ are owned by root and there is no part which is writable by 'world' (for /Applications/MacPorts/ this seems to be the case already)

After that the hardening version of VBox should be working.

If you have any other questions, please ask.

Chris

[cp@…]

Cc Me!

[pixilla (Bradley Giesbrecht)]

Cc Me!

[rmstonecipher@…]

Chris,
I have followed your instructions up to the point of 'chmod u+s'.
Is there a numeric equivalent (eg 755 or 600) for 'u+s'?
The folder's ownership appeared to already be correct in the destroot, so I want to see if the files' permissions are as well.

Cheers,
Ryan Stonecipher

[pixilla (Bradley Giesbrecht)]

Replying to rmstonecipher@…:

Chris,
I have followed your instructions up to the point of 'chmod u+s'.
Is there a numeric equivalent (eg 755 or 600) for 'u+s'?

Using your example, I believe 4755 or 4600 would do it.
From man chmod:

• 4000 (the set-user-ID-on-execution bit) Executable files with this bit set will run with effective uid set to the uid of the file owner. Directories with the set-user-id bit set will force all files and sub-directories created in them to be owned by the directory owner and not by the uid of the creating process, if the underlying file system supports this feature: see chmod(2) and the suiddir option to mount(8).
• 2000 (the set-group-ID-on-execution bit) Executable files with this bit set will run with effective gid set to the gid of the file owner.

I am building with these instructions as well. I made separate patches for each file and planned on posting them here. I'm still compiling.

[carsomyr@…]

The build patch patch.

[carsomyr@…]

How about the attached patches?

-Roy

[carsomyr@…]

The Portfile patch.

[carsomyr@…]

Please ignore "patch-Portfile.diff" and use "patch-Portfile.2.diff" instead.

[pixilla (Bradley Giesbrecht)]

carsomeyr: Why is this the result I get when I apply your patch-patch-*.diff.diff files?

$ patch < patch-patch-build.diff.diff
patch-patch-build.diff.diff 
patch unexpectedly ends in middle of line
patch: **** Only garbage was found in the patch input.

Can you upload patch-build.diff?

[pixilla (Bradley Giesbrecht)]

carsomeyr: Never mind. I used the wrong download string and had a garbage diff. I should have checked it first.

[pixilla (Bradley Giesbrecht)]

carsomeyr: After building with your two patches; when I launch virtualbox and try to start an existing VM or create a new one; and click start I get this error:

Failed to load VMMR0.r0 (VERR_SUPLIB_OWNER_NOT_ROOT).

Are you able to use virtualbox with your patches?

[pixilla (Bradley Giesbrecht)]

Interesting. My prefix for this virtualbox install is /opt/macports-test. I have the two patches from carsomeyr applied. With my user as the owner of /opt I could not start a VM:

$ ls -l -d /opt
drwxr-xr-x  9 brad  admin  306 Aug 25 06:05 /opt

but with root owning /opt my virtualbox VM starts fine:

$ ls -l -d /opt
drwxr-xr-x  9 root  admin  306 Aug 25 06:05 /opt

[pixilla (Bradley Giesbrecht)]

My ${applications_dir} is /opt/macports-test/Applications/MacPorts.
Is it correct that with virtualbox hardening the entire path to VirtualBox.app must be owned by root?

[pixilla (Bradley Giesbrecht)]

carsomyr: Your patch-patch-build.diff.diff and patch-Portfile.2.diff patches worked fine for me.

[carsomyr@…]

They work for me, too, after rebuilding to be sure.

-Roy

Replying to pixilla@…:

carsomyr: Your patch-patch-build.diff.diff and patch-Portfile.2.diff patches worked fine for me.

[carsomyr@…]

Chris,

Would you be so kind as to try rebuilding with the patches? You are the VirtualBox expert.

-Roy

[rmstonecipher@…]

Roy,
We should increment the revision variable in the Portfile to ensure current users have an easy upgrade path to the hardened version.
As soon as Chris approves the changes I will commit them.

Cheers,
Ryan Stonecipher

[cp@…]

Hi,

I tried the port with your patches and it worked for me. I also would support increasing the revision of the portfile to make sure users get the updated version.

Thanks Chris

[ecronin (Eric Cronin)]

Replying to pixilla@…:

My ${applications_dir} is /opt/macports-test/Applications/MacPorts.
Is it correct that with virtualbox hardening the entire path to VirtualBox.app must be owned by root?

From comment 1:

6. Make sure that all directories parts within /Applications/MacPorts/ are owned by root and there is no part which is writable by 'world' (for /Applications/MacPorts/ this seems to be the case already)

It's probably worth doing the ownership check in post-activate and warn (but not chmod on the user) if ownership is incorrect

[carsomyr@…]

I can confirm that all the directories have correct privileges. Ryan, can you check in the changes?

-Roy

[ecronin (Eric Cronin)]

My suggestion wasn't really intended to help the people cc:'d on this ticket or people with fresh default installs of macports. But people with non-standard install locations/permissions/ownership like pixilla had at first or where something has gone and changed owner/permissions on a default /opt (looking at you poorly built .pkgs) are just going to get the very non-descriptive Failed to load VMMR0.r0 (VERR_SUPLIB_OWNER_NOT_ROOT). error when they go to run vbox the first time. If instead pre-activate checks the ownership and permissions and gives a useful human-understandable error message and dies you prevent some future tickets being filed.

[carsomyr@…]

Chris,

Can you confirm that VirtualBox is going to fail if the permissions of any directory in ${prefix} (default is /Applications/MacPorts) isn't owned by root:admin?

-Roy

[carsomyr@…]

I've reattached patch-Portfile.diff, which should now have checks for "/Applications/MacPorts" (namely, that it and parent directories have root:admin ownership).

-Roy

Replying to ecronin@…:

My suggestion wasn't really intended to help the people cc:'d on this ticket or people with fresh default installs of macports. But people with non-standard install locations/permissions/ownership like pixilla had at first or where something has gone and changed owner/permissions on a default /opt (looking at you poorly built .pkgs) are just going to get the very non-descriptive Failed to load VMMR0.r0 (VERR_SUPLIB_OWNER_NOT_ROOT). error when they go to run vbox the first time. If instead pre-activate checks the ownership and permissions and gives a useful human-understandable error message and dies you prevent some future tickets being filed.

[ryandesign (Ryan Carsten Schmidt)]

I assume this means the port will not work for users who have elected to install MacPorts as a user other than root.

[cp@…]

Replying to carsomyr@…:

Chris,

Can you confirm that VirtualBox is going to fail if the permissions of any directory in ${prefix} (default is /Applications/MacPorts) isn't owned by root:admin?

-Roy

Yes, as I wrote in the first comment this is the case. Sorry, we are a little bit paranoid in this area.

As the average user is doing the default install, I don't see any problems with that. For the others a warning is a good indicator that something can goes wrong.

Chris

[carsomyr@…]

Ryan,

The Portfile patch

[carsomyr@…]

Ryan,

The Portfile patches are ready for check in. I've bumped the revision number and made some cosmetic changes.

-Roy

Replying to carsomyr@…:

Ryan,

The Portfile patch

[rmstonecipher@…]

Committed in r83671.

[ecronin (Eric Cronin)]

D'oh forgot about this ticket until I saw the commit go across this morning... Two nits about the check block:

• Doing the check in pre-extract is nice from a fail-early standpoint, but since it's easily fixable (not a "this will never work on your computer and you just wasted hours building things" errir) I think it belongs as pre-activate to handle the permissions changing between the check and when you finally activate, either because you did 'port deactivate' or because you installed from an archive which never ran the check on your machine to begin with

• You also need to check that no part of the path is a+w like comment 1 part 6 says.

[ecronin (Eric Cronin)]

That's o+w not a+w of course...

[carsomyr@…]

• You also need to check that no part of the path is a+w like comment 1 part 6 says.

Does this warrant action? The correct permissions for MacPorts VirtualBox just are; they're a consequence of the build process, and I've verified that none of them are a+w.

-Roy

[ecronin (Eric Cronin)]

Replying to carsomyr@…:

• You also need to check that no part of the path is a+w like comment 1 part 6 says.

Does this warrant action? The correct permissions for MacPorts VirtualBox just are; they're a consequence of the build process, and I've verified that none of them are a+w.

-Roy

The build process changes the permissions of /Applications or /Users/username if they've been made o+w for some reason? What MacPorts installs into its directories is correct, but it has no control over what is before it in the hierarchy and VirtualBox cares about that. Don't count on users always knowing what they're doing, e.g. ​http://stackoverflow.com/questions/663089/unable-to-make-applications-folder-writeable-in-mac (from personal experience, OS 9 transplants used to love doing this to make it more familiar; they'd throw the -R flag in too for good measure. Plenty of bad advice on how to "fix" things exists in Google still)

[carsomyr@…]

Replying to ecronin@…:

Replying to carsomyr@…:

• You also need to check that no part of the path is a+w like comment 1 part 6 says.

Does this warrant action? The correct permissions for MacPorts VirtualBox just are; they're a consequence of the build process, and I've verified that none of them are a+w.

-Roy

The build process changes the permissions of /Applications or /Users/username if they've been made o+w for some reason? What MacPorts installs into its directories is correct, but it has no control over what is before it in the hierarchy and VirtualBox cares about that. Don't count on users always knowing what they're doing, e.g. ​http://stackoverflow.com/questions/663089/unable-to-make-applications-folder-writeable-in-mac (from personal experience, OS 9 transplants used to love doing this to make it more familiar; they'd throw the -R flag in too for good measure. Plenty of bad advice on how to "fix" things exists in Google still)

Ah, I see, we are talking past each other. I was questioning the necessity of permissions checking inside the VirtualBox hierarchy and not its parent directories. Still, I wonder why making higher level directories writeable could possibly allow other users to affect anything within /Applications/MacPorts/VirtualBox. Still going to put in the change, though.

-Roy

[carsomyr@…]

The Portfile patch (revision 4).

[carsomyr@…]

I've reattached the Portfile patch as revision 4 with the suggested changes.

-Roy

[ecronin (Eric Cronin)]

Replying to carsomyr@…:

Ah, I see, we are talking past each other. I was questioning the necessity of permissions checking inside the VirtualBox hierarchy and not its parent directories. Still, I wonder why making higher level directories writeable could possibly allow other users to affect anything within /Applications/MacPorts/VirtualBox. Still going to put in the change, though.

Not sure the exact risk of the top of my head, but given the capabilities of VBox (bunch of setuid root bins talking to kernel extensions with APIs for raw disk and network access etc) they're obviously very paranoid about the environment it executes in to prevent being used for priv escalation...

And actually I'd been misreading item 6 in comment 1 this entire time, it just talks about things from .../MacPorts and deeper. But I remembered from when I played with the VirtualBox OSE builds back in the Sun days that it was the entire path that mattered and was just assuming that's what it actually said.

Patch looks good to me