How to handle new KEXT policy in installer?

"I installed High Sierra Beta 3 on a new partition and installed our driver package. It said it installed successfully and I do see the files in /Library/Extensions. I checked the Security Panel and didn't see any notification to approve a developer id.


I then ran

sudo kextload Myri10GE.kext

/Library/Extensions/Myri10GE.kext failed to load - (libkern/kext) system policy prevents loading; check the system/kernel logs for errors or try kextutil(8).


I then saw the popup "System Extension Blocked" and clicked OK to dismiss it. I then went back to the Security Panel and saw the "Allow" button. I clicked it and the our driver was loaded. ifconfig shows the ports attached.


I was thinking of modifying the postinstall script to run the kextutil command to load the driver as it seems to have not triggered the popup/"Allow" button.


Any other ideas on what others are doing to handle the new policy?


Do you get the popup/Allow button on a new Installation or do you have to run kextload/kextutil explicitly?

See my other note. This is shaping up to be a disaster. We cannot change the 100K units of hardware we have in the field, so we need our KEXT.


In my experiemnt on VMware, the vmware extension was blocked! But after clicking ok on the dailog it never showed in the Secuirty Panel! There is no command to retrigger or clear the database.

Thanks for the note. I'll have to figure out a way to display a popup or run a kextutil cmd to trigger the block.


I'll also spin up a VM and take a snapshot to make rolling back to a clear database easier.

I decided to wipe out the beta3 partition and install beta4.


I repeated our driver pkg install and it installed successfully again. No popup or msg in Security pane. I then rebooted. Upon login, I do see the popup and a msg in the Security pane.

I have provided some input to Apple. Hopefully they will change some of their UI or rhe policy altogether. In my mind, it provides negligible security improvement for all the user pain it will create.


Meanwhile I am experimenting with my postinstall script. We have always done a kextload plus permissions cleanup (in 1 in a thousand cases, the installer does not make the ownership and permissions stick correctly.) Now I check for the documented error 27. The nice part is that the script can be used for all systems 10.9 and up. 10.7 and 10.8 have different KEXT locations and signing conventions, so they are treated special in the installer.


If error 27 is detected, it opens up the Security & Privacy Preferences for the user and pops an AppleScripted dialog for the user going into more detail. We will have to do some user testing to see, whether we actually need to follow up and nag until we get no error, since the user only has 30 min. before they are down a rat hole.


I also might go even uglier and pop a detailed document Window with graphics. We know that users do not read the Installer text panes, so it needs to be something obvious and clear.


The end of elegance on Mac... I really hate what this looks like.

😢

Do you always get error 27? I thought about triggering some action in case of the kextload failing with error 27 aswell, but the error I encounter is 71. The dialog about approving the kext at preferences/security appears as expected though. Does anyone know what this exit code means?

How to handle new KEXT policy in installer?
 
 
Q