Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#30992 closed enhancement (fixed)

virtualbox: enable hardening

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: rmstonecipher@…
Priority: Normal Milestone:
Component: ports Version: 2.0.1
Keywords: Cc: cp@…, carsomyr@…, rmstonecipher@…, pixilla (Bradley Giesbrecht)
Port: virtualbox

Description

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.

Attachments (3)

patch-patch-build.diff.diff (950 bytes) - added by carsomyr@… 13 years ago.
The build patch patch.
patch-Portfile.2.diff (1.4 KB) - added by carsomyr@… 13 years ago.
The Portfile patch.
patch-Portfile.diff (1.3 KB) - added by carsomyr@… 13 years ago.
The Portfile patch (revision 4).

Download all attachments as: .zip

Change History (38)

comment:1 Changed 13 years ago by 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
  1. 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=
    
  2. Build VirtualBox
  1. Install VirtualBox to /Applications/MacPorts/
  1. 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
    
  2. 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

comment:2 Changed 13 years ago by cp@…

Cc: cp@… added

Cc Me!

comment:3 Changed 13 years ago by rmstonecipher@…

Cc: carsomyr@… rmstonecipher@… added
Owner: changed from macports-tickets@… to rmstonecipher@…
Status: newassigned

comment:4 Changed 13 years ago by pixilla (Bradley Giesbrecht)

Cc: pixilla@… added

Cc Me!

comment:5 Changed 13 years ago by 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

comment:6 in reply to:  5 Changed 13 years ago by 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.

Changed 13 years ago by carsomyr@…

Attachment: patch-patch-build.diff.diff added

The build patch patch.

comment:7 Changed 13 years ago by carsomyr@…

How about the attached patches?

-Roy

Changed 13 years ago by carsomyr@…

Attachment: patch-Portfile.2.diff added

The Portfile patch.

comment:8 Changed 13 years ago by carsomyr@…

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

comment:9 Changed 13 years ago by 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?

comment:10 Changed 13 years ago by pixilla (Bradley Giesbrecht)

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

comment:11 Changed 13 years ago by 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?

comment:12 Changed 13 years ago by 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

comment:13 Changed 13 years ago by 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?

comment:14 Changed 13 years ago by pixilla (Bradley Giesbrecht)

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

comment:15 in reply to:  14 Changed 13 years ago by 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.

comment:16 Changed 13 years ago by carsomyr@…

Chris,

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

-Roy

comment:17 Changed 13 years ago by 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

comment:18 Changed 13 years ago by 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

comment:19 in reply to:  13 Changed 13 years ago by 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:

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

comment:20 Changed 13 years ago by carsomyr@…

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

-Roy

comment:21 Changed 13 years ago by 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.

comment:22 in reply to:  21 ; Changed 13 years ago by 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

comment:23 in reply to:  21 Changed 13 years ago by 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.

comment:24 Changed 13 years ago by 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.

comment:25 in reply to:  22 Changed 13 years ago by 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

comment:26 Changed 13 years ago by carsomyr@…

Ryan,

The Portfile patch

comment:27 in reply to:  26 Changed 13 years ago by 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

comment:28 Changed 13 years ago by rmstonecipher@…

Resolution: fixed
Status: assignedclosed

Committed in r83671.

comment:29 Changed 13 years ago by 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.

comment:30 Changed 13 years ago by ecronin (Eric Cronin)

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

comment:31 in reply to:  29 ; Changed 13 years ago by 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

comment:32 in reply to:  31 ; Changed 13 years ago by 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)

comment:33 in reply to:  32 ; Changed 13 years ago by 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

Changed 13 years ago by carsomyr@…

Attachment: patch-Portfile.diff added

The Portfile patch (revision 4).

comment:34 Changed 13 years ago by carsomyr@…

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

-Roy

comment:35 in reply to:  33 Changed 13 years ago by 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

Note: See TracTickets for help on using tickets.