• Could it be possible to explain how this is supposed to bring additional security considering that:
- kernel extensions installed prior to upgrading to High Sierrra won't be filtered.
- by not loading the kernel extensions, this feature can decrease the security/safety level expected by users who purchased a solution whose purpose is to provide additional security/safety levels.
Basically, it's already required to:
- codesign the kernel extension with Developer ID Certificates specific for kernel extensions and which are apparently quite hard to obtain these days.
- productsign the installation packages when using Apple standard installation packages
- request administrative privileges from the user installing (or dynamically loading) the kernel extensions.
• Wouldn't it be just easier to require to use an Apple standard installation package to install any kernel extension so that some Apple code:
- can check the contents of the payload for any kernel extension and the related certificate.
- allows only a specific Apple process (shove?) to install a kernel extension (to avoid the issue with components being installed during the pre or post installation scripts or via a privilege helper tool for instance for Drag and Drop install).
- notifies the user before the installation begins (if there is still any sense to do so considering the previous checks) and requests what to do prior to installing the files. See the last bullet for an additional useful feature.
This way, you don't:
- break the installation workflow in 3 steps: install, discover it does not work as expected, fix the issue.
- have the user figuring out which solution installed the kernel extension (the Subject Common Name may not be always easy to link with the name of the product (even more if the product is distributed as a white-label).
- need for the user to guess that it needs to go to the Security & Privacy pane to make the solution run as expected
- require additional work from 3rd party developer to deal with their kernel extension not being loaded by High Sierra for a new unexpected reason.
- make the end user the Directly Responsible Individual that should ensure that the kernel extension is safe to be used.
• It would also be welcome that the Technical Note lists what can be done to be informed that the kernel extension has been finally loaded after an admin user trusted the developer ID. Intuitively, I would go with kernel events but maybe there are more appropriate ways to deal with this new asynchronism.
• And finally, there's something missing when you compare this feature with the privacy feature to access AddressBook contents for instance:
There are apparently no ways at this point for the 3rd party developer to explain why the product needs to use a kernel extension or what the kernel extension will do.
Basically, this new mechanism currently makes all kernel extensions look evil.