Selon TN2459
Les KEXT approuvés sont suivis dans une base de données de politiques à l'échelle du système grâce à l'identifiant de l'équipe dans la signature du code du KEXT et à l'identifiant du paquet dans le fichier Info.plist du KEXT, de sorte que la mise à jour d'un KEXT qui a déjà été approuvé ne déclenchera pas une nouvelle demande d'approbation.
Cette base de données (au moins jusqu'à Mojave) est /var/db/SystemPolicyConfiguration/KextPolicy et vous pouvez le mettre à jour avec sqlite3 après désactivation de SIP .
A1398% csrutil status
System Integrity Protection status: disabled.
A1398% sudo sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy
SQLite version 3.24.0 2018-06-04 14:10:15
Enter ".help" for usage hints.
sqlite> .schema
CREATE TABLE settings ( name TEXT, value TEXT, PRIMARY KEY (name) );
CREATE TABLE kext_load_history_v3 ( path TEXT PRIMARY KEY, team_id TEXT, bundle_id TEXT, boot_uuid TEXT, created_at TEXT, last_seen TEXT, flags INTEGER , cdhash TEXT);
CREATE TABLE kext_policy ( team_id TEXT, bundle_id TEXT, allowed BOOLEAN, developer_name TEXT, flags INTEGER, PRIMARY KEY (team_id, bundle_id) );
CREATE TABLE kext_policy_mdm ( team_id TEXT, bundle_id TEXT, allowed BOOLEAN, payload_uuid TEXT, PRIMARY KEY (team_id, bundle_id) );
sqlite>
Il contient 4 tableaux dont seulement politique_de_kext y kext_load_history_v3 sont intéressants (sauf si vous utilisez vraisemblablement mdm). Par exemple, voici mes kext autorisés :
sqlite> select * from kext_policy;
VBG97UB4TA|com.objective-see.lulu|1|Objective-See, LLC|1
Z3L495V9L4|com.intel.driver.EnergyDriver|1|Intel Corporation Apps|1
|com.rugarciap.DisableTurboBoost|1|Legacy Developer: Rugarciap|1
MLZF7K7B5R|at.obdev.nke.LittleSnitch|1|Objective Development Software GmbH|1
54GTJ2AU36|com.joshuawise.kexts.HoRNDIS|1|Joshua Wise|1
6HB5Y2QTA3|com.hp.kext.io.enabler.compound|1|HP Inc.|0
sqlite>
Si vous vouliez les supprimer tous, vous pourriez utiliser delete from kext_policy;
puis d'être ordonné delete from kext_load_history_v3;
Vous pouvez également supprimer un élément spécifique en comparant l'un des champs affichés par l'icône .schema
commande. Par exemple, pour supprimer LittleSnitch sur la base du deuxième champ numéro de lot ;
sqlite> delete from kext_policy where bundle_id = "at.obdev.nke.LittleSnitch";
sqlite> delete from kext_load_history_v3 where bundle_id = "at.obdev.nke.LittleSnitch";
sqlite> select * from kext_policy;
VBG97UB4TA|com.objective-see.lulu|1|Objective-See, LLC|1
Z3L495V9L4|com.intel.driver.EnergyDriver|1|Intel Corporation Apps|1
|com.rugarciap.DisableTurboBoost|1|Legacy Developer: Rugarciap|1
54GTJ2AU36|com.joshuawise.kexts.HoRNDIS|1|Joshua Wise|1
6HB5Y2QTA3|com.hp.kext.io.enabler.compound|1|HP Inc.|0
sqlite> .quit
Je remarque que cette réponse sur stackoverflow suggère qu'il peut être nécessaire de réinitialiser la PRAM. La réinitialisation de la PRAM réactive automatiquement le SIP et comme c'est plus facile que de démarrer en mode récupération, cela vaut la peine de le faire.
Il est possible de le faire à l'aide d'une interface graphique si vous préférez. Après avoir désactivé SIP :
- Télécharger et installer DB Browser for SQLite
- Lancer à partir du terminal avec
sudo /Applications/DB\ Browser\ for\ SQLite.app/Contents/MacOS/DB\ Browser\ for\ SQLite
- Base de données ouverte /var/db/SystemPolicyConfiguration/KextPolicy (presse . pour afficher les fichiers cachés).
- Sur Parcourir les données onglet dans politique_de_kext cliquez avec le bouton droit de la souris et supprimez la ou les lignes contenant les kexts indésirables. Ici, je supprime le kext de LuLu pare-feu.
- Changer le tableau en kext_load_history_v3 et supprimer les lignes correspondantes.
- Cliquez sur Changements d'écriture
- Redémarrer et réinitialiser la PRAM ( - - P - R ) qui réactive automatiquement le SIP sans qu'il soit nécessaire de redémarrer en mode de récupération.
- Après le redémarrage, un Extension du système bloquée est reçu pour le kext dont les enregistrements ont été supprimés :
- Autoriser les logiciels du développeur dans Préférences du système met à jour les Politique de Kext de la base de données et ensuite d'autres redémarrages sont de retour à la normale.