VB 7.0.0 adds a macOS profile

[scottgus1]

kapitainsky, yes, Chas4's original question, why there is a profile, is a good question. I regret I'm not sure where to ask it, though. The devs don't come to the forum often, except maybe for now, because of the new version and the bugs that will need to be fixed. Maybe a Bugtracker post? Or the Beta forum? viewforum.php?f=15 7.0.0 came out of Beta recently enough that the devs may still look there for questions. A dev might weigh in here, too.

I don't own a Mac, so I don't know the implication of using a profile. However, Chas4's continued objection that Virtualbox doesn't need a profile simply because Parallels doesn't ostensibly need one is not a valid logical path.

I reckon I'll leave the topic open even if Chas4 doesn't answer the question about what problem they're having over the profile, as long as "Parallels-doesn't-need-it" chatter doesn't continue. (We mods have to keep checking on new posts, and continued bell-ringing gets annoying after a while... )

[kapitainsky]

Ta for clarification.

And yes Chas4 reasoning is wrong (to say the least) - I ignore it entirely. But question what VB needs profile for is IMHO reasonable as on macOS it potentially have security implication.

I will try to ask on bugtracker

[scottgus1]

Sounds good. If you get a response, please copy it over here. Thanks!

[kapitainsky]

For future reference:

https://www.virtualbox.org/ticket/21164

[klaus]

The install of the provisioning profile is intentional action of the VirtualBox 7 installer. It wouldn't be required for running VMs in the usual GUI (since Apple has defined a mechanism for placing such profiles into an .app bundle), but for command line tools (running VMs headless, i.e. VBoxHeadless) there is no such mechanism, leaving just the install of the profile in the appropriate directory of the macOS system.

If anyone knows a better solution please let us know. The documentation is sparse, especially for command line tools.

[kapitainsky]

Thank you very much for clarification. One issue less with VB 7.0.0

[chas4]

Hi @scottgus1,

You are 100% right but would be nice if these concerns filter to release team and are addressed in the next release notes - quick note that we use macOS profiles for XYZ reason. It is indeed very unusual to use profiles by any applications - does not mean that there is anything wrong with it.

That is what I asked about since it was not in the release notes at all and looks very strange for an app to add a profile and not ask you about it, I knew they were experimenting for Arm Macs but not for Intel Macs.

Did not see the other content that had been added that has some more info on what the profiles are for, and not sure what is with the rudeness from others.

[scottgus1]

Thanks, Klaus, for the info!

[boxernotreally]

I've read this thread: viewtopic.php?p=525803#p525803
Unfortunately that's locked however.
Klaus has mentioned the Provisioning Profile is only necessary for the command-line tools. However, removing it from System-Preferences/Profiles prohibits GUI's functionality dead in its tracks as well even with the simplest configs.
Since during the installation, one can skip installing command-line tools, shouldn't installing the Provisioning Profile be optional and bound to that decision as well? On that note, wouldn't asking for admin password become unnecessary too if one doesn't require command-line tools?

For those not very familiar with Provisioning Profiles, it's worth mentioning that a lot of other apps have them in their bundles as well, and it doesn't get automatically added to the System-Preferences/Profiles, e.g. Chrome.

It may be convenient for the devs to justify it by saying that the GUI calls command-line tools; however, entitlements are inherited and if the GUI has the right entitlements, the command-line tools wouldn't need to have them separately.

So... What's the deal here?!

P.S. This is not to accuse VB's dev of any intentional wrongdoing, but to focus on security best practices, and not giving privileges unnecessarily.

[scottgus1]

boxernotreally, I unlocked the topic and merged your post to it.

***************************

during the installation, one can skip installing command-line tools

I've never heard of this before, this option is not given on Windows installations that I know of. Can you please post a screenshot of where you are given such an option for a Virtualbox installation? See the Attachments tab to post the screenshot.

*****************************
Regarding the question of why the profile is there, one answer I have asked for above, at least once, is:

What is the problem with having it?

And if the answer to that question is "security problems", then what security problems, exactly?

[fth0]

I cannot speak for Klaus, but I can give my two cents:

Klaus has mentioned the Provisioning Profile is only necessary for the command-line tools. However, removing it from System-Preferences/Profiles prohibits GUI's functionality dead in its tracks as well even with the simplest configs.

No, Klaus mentioned that the provisioning profile must be placed outside the VirtualBox.app bundle for the CLI tools to be usable, not that it isn't needed for the GUI tools (note the second word "install" in his post ). You seem to have discovered that yourself.

It may be convenient for the devs to justify it by saying that the GUI calls command-line tools; however, entitlements are inherited and if the GUI has the right entitlements, the command-line tools wouldn't need to have them separately.

You seem to be missing that I "as a user" can use the CLI tools without the GUI (especially VBoxManage).

For those not very familiar with Provisioning Profiles

Since this seems to imply that you're more familiar with provisioning profiles than me (no objection from my side at all ):

Is it allowed to place the same provisioning profile in both locations? If so, does it make sense to do that from your POV?

[boxernotreally]

Thank you, scottgus1, for unlock & merging; and sorry for my late reply. I was expecting to get an email in case of an update, which I didn't. I've attached the screenshot for your information.

"what security problems, exactly?"

I've just started reading tn3125-inside-code-signing-provisioning-profiles and tn3126-inside-code-signing-hashes of Apple.
I'd insert a link but I got an error due to the forum external link policy. They are very long documents to go through so I'm not sure if I'll ever fully understand them.
However, the simple question that I'm determined to find the answer for is: "How does the Provisioning Profile in system-preferences (not app bundle) specifically give the required entitlements only to select binaries and nothing else?" I believe I should find the answer in tn3126.

"You seem to be missing that I "as a user" can use the CLI tools without the GUI (especially VBoxManage)."

I did not miss that point. I was suggesting that if one doesn't need CLI tools standalone, there should not be a need for a Provisioning Profile in system-preferences.


I'll discuss my findings once I read those dox and try a few experiments.


Ideally, I hope to find out that the Provisioning Profile contains hashes of VBox binaries in an auditable manner. Because if it doesn't, it could imply that basically any executable on my system can now benefit from the entitlements in that profile.


 　

[scottgus1]

Thanks for the screenshot, boxernotreally! That's an interesting option. It doesn't come up on Windows hosts:

7.0.12 install options.png (24.02 KiB) Viewed 5079 times

I wonder if it was there on 6.1 & earlier Mac OS Virtualbox installers?

Though I'd never understand it myself, it would be curious to see if there is an answer to how the profile supports only the command line exe's?

As I read Klaus's statement above, the .app bundle for the GUI-based Virtualbox already has its own provisioning profile. But there isn't a way to provide a provisioning profile inside the command line exe's so the profile has to come separately.

Here's a theory, untested by me who does not have a Mac to test on, and only possibly holding water if the GUI-only vs GUI+CLI option shown in your screenshot was not there back in 6.1 & earlier:

Apple's changes have included a requirement that CLI apps can't be under a GUI app umbrella. So a CLI app needs its own separate provisioning profile, which has to come separately, because the CLI app can't have it built-in.

FWIW on a Windows host, Virtualbox has VboxSVC.exe running all the time, which launches more VirtualboxVM.exe's for normal start VMs, or VboxHeadless.exe's for detachable/headless VMs, and another VirtualboxVM.exe for showing the detachable/headless VM's window. Vboxmanage.exe doesn't appear to be used running a VM through the GUI.

[fth0]

FWIW, here are the links for interested readers:

TN3125: Inside Code Signing: Provisioning Profiles
TN3126: Inside Code Signing: Hashes
TN3127: Inside Code Signing: Requirements


AFAIU the technical notes, provisioning profiles contain at least the developer certificate (or a hash of it), so their use should be restricted to files signed by the same developer, even if they don't contain an application identifier.

[klaus]

Right, I didn't mean to imply that the 'global' provisioning profile is installed only with the VirtualBox CLI utilities.

A VirtualBox install always puts two (identical) copies of the provisioning profile onto the user's system: the one inside the VirtualBox app bundle and the one installed 'globally' in the system.

The one inside the app bundle is used purely by the GUI app (which fth0 pointed out that it depends on executables running in the background which are unavoidably CLI utilities), and the global one by everything else.

Provisioning profiles are bolted to code signed by the same developer ID (and also code with a specific App ID). This ensures that the profile's privileges can't be used by random other applications (remember that this kind of provisioning profile must be signed by Apple, containing the public signing key limiting who can create apps relying on it). For the profile we're talking about the developer ID is "VB5E2TV963" (a team ID) which corresponds to "Oracle America, Inc.", limiting the trust to subsets of this entity. As mentioned the App ID also plays a role: just applications containing the same App ID can use the privileges. An app bundle can specify only one App ID, which means that other apps by Oracle can't just magically use the privileges for VirtualBox.

I already expressed my unhappiness about Apple's GUI tools for showing the content of provisioning profiles. It hides key information, which would proactively answer your valid concerns related to the big power which provisioning profiles can have - and some kinds don't have to be signed by Apple.