High Sierra blocking kernel extensions?

I should have added: yes, my kext is properly signed (I think!!) such that El Capitan and Sierra are both happy with it.

I'm seeing the same thing. Also, the whitelisting seems to be on a per-kext basis, not a per-developer basis, such that I have to do this for each of our drivers. Not only will this be painful for our customers (they'll have to go to the Security preferences and click "Accept" for each driver in our install), but it will likely cause problems for our automated testing as well.

I've already hit an issue where the prompt to Accept in Security preferences vanished on its own. And there seems to be no way to get it back.

ncdeboni wrote:

Is this something new applying to all kernel extensions …?

Correct. I can’t go into this in too much detail in this context — we should have some official info on this topic published soon — but it’s safe to say that this was a deliberate security policy change.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

This is a good change. Any way to help us out in the short run by giving us a way to get the Security preferences to re-prompt for authorizaton?

Great to know that there will be official word about this change coming. Will you reply to this thread with a link when it is available?

Will there be a tool similar to the user-mode Gatekeeper's spctl to allow us to programatically manage the whitelist?

Any way to help us out in the short run by giving us a way to get the Security preferences to re-prompt for authorizaton?

I just tried this here in my office:

1. I attempted to load my KEXT using

   kextload

   .

2. It failed with the expected error:

   $ sudo kextload /Library/Extensions/KauthORama.kext
   /Library/Extensions/KauthORama.kext failed to load - (libkern/kext) not loadable (reason unspecified); check the system/kernel logs for errors or try kextutil(8).

   .

3. In System Preferences > Security & Privacy > General, I saw a message “System software from developer *** was blocked from loading.” with an Allow button.

4. I ignored my Mac for an hour (I think the threshold here is 30 minutes).

5. The message from step 3 disappeared.

6. I repeated step 2.

7. The message from step 3 re-appeared.

I was testing this with macOS 10.13 beta 1 running in a VM.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I've tried this a few times (with more than 30 min delay between attempts) and haven't been able to get the prompt to come back up. I was hoping there was some explicit way to reset the prompt, but if not, I can just file a Radar

I've tried this a few times (with more than 30 min delay between attempts) and haven't been able to get the prompt to come back up.

Weird. That definitely worked for me (I tried it before I posted).

I was hoping there was some explicit way to reset the prompt

AFAIK there is not.

if not, I can just file a Radar

Absolutely. Maybe even two (one for a developer-focused mechanism to trigger the prompt, one for the fact that it’s not coming back automatically on your machine).

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

There is a new technote out that covers this new macOS High Sierra feature:

Technical Note TN2459

Secure Kernel Extension Loading

https://developer.apple.com/library/content/technotes/TN2459/_index.html#//apple_ref/doc/uid/DTS40017658

--gc

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

tartempion thank you for this detailed question.
I hope Apple will give a detailed answer,

our app faces a similar situation.

In term of UX it's very hard to create a coherent user scenario with a red error button in the middle.

Thank you for your help.

Hi,

shouldn't those changes be announced by mail to every agent that has access to a certificate which can be used to sign Kernel Extensions?

As far as I can see we did not receive an E-Mail regarding those changes. We were lucky to stumble across this forum topic early.

Best Regards

Timo

Addendum:

According to the Technote, Kernel Extensions should be put in either /Library/Application Support (manually loading) or /Library/Extensions (automatic loading) to automatize the "approval" of other kext from the same vendors once one kext has been "approved".

I have one problem and question about using /Library/Application Support. This directory has not always been root:wheel (e.g. (Mac) OS X 10.7).

So is there any guarantee that it will be root:wheel on (Mac) OS X 10.8 and later on all deployed OS X systems whatever the migration/update path was?

Is the Technical Note going to be revised soon?

Because what the technote states is completely different from what seed 3 is implying with the quite incompleted "Allow…" dialog sheet in System Preferences > Security & Privacy > General pane?

Also this would allow to confirm that the expected return code is 27 when the loading of the kext is blocked due to "system policy".

Problem ID 33236899