How dangerous is it in allowing kernel extensions from CalDigit and Rogue Amoeba by Reducing Security?

[bogdanw]

In my opinion, the function of the profile is poorly explained on that forum. It’s not needed by the CLI tools (/usr/local/bin/VirtualBox and the rest), but by the binaries inside the VirtualBox.app, that is validly signed & notarized

https://objective-see.org/products/whatsyoursign.html

 

[Unknownnnn]

1- Imagine there was no GUI or app bundle. Could the CLI tools bring up a VM using hypervisor without a such Provisioning Profile?
2- Now that they've decided to add this Provisioning Profile, how does MacOS decide where (for which executables) it's applicable?

 

[bogdanw]

1- Imagine there was no GUI or app bundle. Could the CLI tools bring up a VM using hypervisor without a such Provisioning Profile?

The binaries from /usr/local/bin/ can’t do anything by themselves. If you open /usr/local/bin/VirtualBox in TextEdit you will find just:
#!/bin/bash
exec /Applications/VirtualBox.app/Contents/MacOS/VirtualBox "$@"

2- Now that they've decided to add this Provisioning Profile, how does MacOS decide where (for which executables) it's applicable?

It’s applicable for the binaries inside the app. The profile ensures that you will not be asked to give permission for every one. The permission is inherited from the app.

You could remove the profile and start giving Input Monitoring and Accessibility permissions to every binary inside VirtualBox.app until it works.

 

[Unknownnnn]

You're amazing. Thanks so much!
I never thought that those executables could simply be bash scripts. That clears it all up!
The `otool` works on the bundled binaries, but I don't know if it can show signatures. Anyway, used jtool2 from newosxbook.com (it's not open-source, so use it at your own risk) and it did show the Oracle signature. (`./jtool2 --sig /Applications/VirtualBox.app/Contents/MacOS/VBoxManage`)

One last question (I promise): Does MacOS automatically add the Provisioning Profile to System Preferences when copying an app bundle to Applications with a profile that has restricted entitlements, or do app installers have to deliberately install such a profile for their non-GUI binaries to work?

 

[throAU]

If you trust the developer and the kernel extension is properly written without any vulnerabilities, it's not dangerous at all.

I'll caveat that with this:

if malicious software can mess with the extension and get it to execute arbitrary code, such malicious software can abuse said extension to gain system privileges.

Now this is also true for core OS components, but apple try to minimise what runs in kernel space.

That said, some things NEED kernel access to do their job. As above if it is from a reputable vendor, all good. Just make sure to keep an eye on, and perform software updates for the extension as a priority in case they plug security holes as discovered, as you've basically made your mac security reliant on the security of the kernel extension(s) you have installed.

 

[bogdanw]

One last question (I promise): Does MacOS automatically add the Provisioning Profile to System Preferences when copying an app bundle to Applications with a profile that has restricted entitlements, or do app installers have to deliberately install such a profile for their non-GUI binaries to work?

No, it doesn’t.
In the case of VirtualBox, the profile is installed by the postflight script from the VirtualBox.pkg

# Install provisioning profile if present, needed by VBoxHeadless.
if [ -f /Applications/VirtualBox.app/Contents/embedded.provisionprofile ]; then
    profiles -i -F /Applications/VirtualBox.app/Contents/embedded.provisionprofile
fi

Seen with Suspicious Package https://www.mothersruin.com/software/SuspiciousPackage/

 

[Unknownnnn]

Holy smokes! That's awesome! Now I know how to reinstall that profile w/o reinstalling the whole package!

Since I'm a man of my word, I'll just say that I'd have loved to know definitively whether entitlements are inherited from the caller app (like the case of TCC) or not; rendering an external/explicit provisioning profile unnecessary (as you hinted before) if an executable -in need of restricted entitlements- is called from a GUI/bundle with the right entitlements in its embedded profile. (It does not seem to be the case since removing that profile stops GUI from working, but thought maybe there's something more elaborate involved.)

Hats off to you. #MadRespects