MacOS High Sierra KEXT Loading - Are there any ways to cancel user approval?

Question

As some kinds of MacOS developers know, Apple implemented Secure Kernel Extension Loading .

Users can approve third party KEXT by clicking Approve button in Security and Privacy. However, once the KEXT is approved, are there any methods for cancelling the approval?

Imagine, the case of testing the app with KEXT loading, etc.

If there are no way but the clean install, it's very difficult to test apps.

Huppert

The easiest way I've found is to set up a fresh VM with macOS 10.13 and take a snapshot. Test what you need to, including approving the kext, then roll back to the snapshot when done. Unfortunately, this doesn't help for drivers of devices that can't be passed through to the VM. – Shuman

Oops, Hackintosh! Unfortunately indeed, my KEXT works with USB devices... – Huppert

I'm not sure what this has to do with Hackintoshes? VMWare Fusion can pass many USB devices through from the host Mac to the guest VM. It doesn't work for all types of hardware, but it does for some. – Shuman

Time Machine can recover permission status of the KEXTs. – Huppert

@Huppert did you end up finding a way that worked ? The accepted answer does not work – Stormystorting

At least when I tried the method, it worked. However, this is a kind of dirty hacks (undocumented, not officially open), and also MacOS has been updated into Mojave, Apple might changed the kext management method. – Huppert

I added a new answer that seems to work. The key seems to be resetting the PRAM. – Intrusion

Answer 1

The information about approvals is stored in sqlite3 database:

/var/db/SystemPolicyConfiguration/KextPolicy

The tables you're interested in are: kext_policy and kext_load_history_v3. E.g. here is how you can view the data and the table schema:

sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy

sqlite> select * from kext_policy;
54GTJ2AU36|com.joshuawise.kexts.HoRNDIS|1|Joshua Wise|1

sqlite> .schema kext_policy
CREATE TABLE kext_policy ( team_id TEXT, bundle_id TEXT, allowed BOOLEAN, developer_name TEXT, flags INTEGER, PRIMARY KEY (team_id, bundle_id) );

Removing the approval is tricker, since the System Integrity Protection does not allow you to modify the database. So, you'd need to reboot into a recovery partition, or a different MacOS installation, then cd into the root of your volume, and run the commands like these (replace with your team_id, or use other criteria):

usr/bin/sqlite3 var/db/SystemPolicyConfiguration/KextPolicy
delete from kext_load_history_v3 where team_id='54GTJ2AU36';
delete from kext_policy where team_id='54GTJ2AU36';
.quit 

Wherever

Good answer, except that most people won't know what a "team ID" is. Perhaps a list of the columns shown by the select * from kext_policy query (which aren't output with the query)? Thanks! – Betook

Oh, and welcome to Stack Overflow. Two of your three answers to date have been useful to me; pretty good in one day. Keep it up! – Betook

Thanks! Now I'm in charge with the job does not depend on MacOS ;-p However this know-how will be useful someday. Above all your trick is quite interesting; it can save much time in comparison with Time-Machine case. – Huppert

On my 10.13.6, the extensions still load after performing the described procedure. There is an additional table named kext_policy_mdm, but deleting relevant records from there didn't help either -- except that they stopped being written to kext_load_history_v3. But they still load, and are listed by kextstat. There is also old_platform_cache which hints about some kind of migration. I wasn't able to guess how its records relate to extensions. The hint about migration is reinforced by table named 'settings' with the single record 'migrationPerformed|YES'. – Batista

Some of my user approved kexts are not even listed in this db. It must exist elsewhere – Stormystorting

@DanielGriscom Have you tried the answer ? It doesn't actually work – Stormystorting

@Stormystorting Extensions, that were already installed prior to updating to 10.13 or 10.14 don't require user approval. The system may remember somewhere if that was the case for an extension. Also I think there exists a white list of extensions that Apple knows about and that don't require user approval either. Further I know that a MDM profile can approve KEXTs which then won't require user approval either. Other than these exception, I followed the answer and it worked as described for me. After re-enabling SIP again, I was prompted again for a previously approved KEXT. – Alejoa

I added a new answer that seems to work. The key seems to be resetting the PRAM. – Intrusion

Answer 2

To echo what people are saying in the comments, I found that the accepted solution did not work. I also had to reset the PRAM.

Working steps:

1. Create the following script somewhere on your filesystem (you will be running this from recovery mode, so you won't be able to copy and paste in that mode). You will need to replace TEAMID1234 with the team ID of the kext(s) you want to revoke consent for. Note that the full paths to /Volumes/Macintosh\ HD are required in recovery mode.

   I called my script /Users/me/revoke_kext_consent.sh, and ran chmod +x /Users/me/revoke_kext_consent.sh.

#!/bin/sh -e
/Volumes/Macintosh\ HD/usr/bin/sqlite3 /Volumes/Macintosh\ HD/var/db/SystemPolicyConfiguration/KextPolicy 'delete from kext_policy where team_id="TEAMID1234";'
/Volumes/Macintosh\ HD/usr/bin/sqlite3 /Volumes/Macintosh\ HD/var/db/SystemPolicyConfiguration/KextPolicy 'delete from kext_load_history_v3 where team_id="TEAMID1234";'

2. Reboot into recovery mode (boot with Cmd-R)

3. Open Terminal, and run the above script (/Volumes/Macintosh\ HD/Users/me/revoke_kext_consent.sh).

4. Reboot and reset the PRAM (boot with Cmd-Opt-P-R)

Intrusion