web-dev-qa-db-fra.com

macOS Kext avec signature valide rejetée après la 2e installation (High Sierra)

Sur une machine sur laquelle mon produit a été installé auparavant, une deuxième installation échoue en raison du rejet de la signature kext. 

J'ai constaté à certains endroits la même erreur, par exemple ici: https://support.eset.com/kb6570 , cependant, même après avoir effacé la table kext_policy en mode de récupération et approuvé manuellement le kext dans les paramètres > sécurité au prochain démarrage, le kext semble toujours être non approuvé.

Par exemple, l'exécution de kextutil fournit les éléments suivants:

Kalyan:~ KalyanPentakota$ Sudo kextutil /Library/Extensions/mycompanyAT.kext/
Password:
Kext rejected due to insecure location: <OSKext 0x7f8e9ff02e20 [0x7fffa11c8af0]> { URL = "file:///Library/StagedExtensions/Library/Extensions/mycompanyAT.kext/", ID = "com.mycompany.at" }
Kext rejected due to insecure location: <OSKext 0x7f8e9ff02e20 [0x7fffa11c8af0]> { URL = "file:///Library/StagedExtensions/Library/Extensions/mycompanyAT.kext/", ID = "com.mycompany.at" }
Diagnostics for /Library/Extensions/mycompanyAT.kext:

etat d'approbation de kext dans la base de données:

sqlite> select * from kext_policy;
XE2XNRRXZ5|jp.co.Canon.bj.print.BJUSBLoad|1|Canon Inc.|8
KBVSJ83SS9|com.citrix.kext.gusb|1|Citrix Systems, Inc.|8
MK9BR98H51|com.mycompany.at|1|My Company Ltd|1

Validation du certificat Kext:

Kalyan:~ KalyanPentakota$ codesign -dvv /Library/Extensions/mycompanyAT.kext/
Executable=/Library/Extensions/mycompanyAT.kext/Contents/MacOS/mycompanyAT
Identifier=com.mycompany.at
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=8179 flags=0x0(none) hashes=250+3 location=embedded
Signature size=4651
Authority=Developer ID Application: My Company Ltd (MK9BR98H51)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Signed Time=Jun 5, 2018 at 6:05:21 AM
Info.plist entries=22
TeamIdentifier=MK9BR98H51
Sealed Resources version=2 rules=13 files=1
Internal requirements count=1 size=212

J'ai également essayé de supprimer / Library/StagedExtensions/Library/, mais cela n'a rien changé non plus.

macosmacos-high-sierrakernel-extension
7
IdoT

Cette solution de contournement résout actuellement tous les cas rencontrés en production: 

Vous devez charger en mode de récupération, désactiver sip, redémarrer, invalider le cache kext, redémarrer à nouveau, puis réactiver sip.

Étapes détaillées:

  1. Dans le menu Apple, sélectionnez Redémarrer.
  2. Lorsque votre Mac redémarre, maintenez les touches Commande (⌘) + R enfoncées dès que vous entendez le carillon de démarrage. Maintenez les touches jusqu'à ce que le logo Apple apparaisse pour que l'ordinateur soit en mode de récupération. 
  3. L'ordinateur est maintenant en mode de récupération. Dans le menu Pomme, sélectionnez Utilitaires -> Terminal.
  4. Exécutez la commande: csrutil disable
  5. Dans le menu Apple, sélectionnez Redémarrer. 
  6. Une fois le macOS chargé, ouvrez le terminal et tapez: Sudo kextcache -invalidate/
  7. si votre kext se trouve dans un emplacement non standard, ajoutez le chemin d'accès kext personnalisé, par exemple:
    Sudo kextcache -invalidate /Library/MyApp/MyApp.kext
  8. Dans le menu Apple, sélectionnez Redémarrer. 
  9. Lorsque votre Mac redémarre, maintenez enfoncées les touches Commande () + R Immédiatement après avoir entendu le carillon de démarrage. Maintenez les touches jusqu'à ce que le logo Apple apparaisse pour que l'ordinateur soit en mode de récupération.
  10. L'ordinateur est maintenant en mode de récupération. Dans le menu Pomme, sélectionnez Utilitaires -> Terminal
  11. Exécutez la commande: csrutil enable
  12. Dans le menu Apple, sélectionnez Redémarrer.
  13. Maintenant, votre kext devrait fonctionner .. 
0
IdoT

J'ai eu le même problème.

Le drapeau de/Library/StagedExtensions doit être "restreint":

ls -laO /Library/StagedExtensions/

drwxr-xr-x @ 4 roues motrices restreintes 128 15 novembre 2017 StagedExtensions

Sinon, essayez ci-dessous cmd à partir du mode de récupération:

chflags -R restricted /V*/*/Library/StagedExtensions

Redémarrez et essayez d'installer le kext.

4
7aadi

Kext rejected due to insecure location n'est pas un rejet de signature IMHO. Où dit-il quelque chose à propos de la signature? Quand la signature est le problème, le littéraire le dit. Pour moi, ce message indique que l'emplacement n'est pas sécurisé.

Avez-vous vérifié les autorisations d'accès de /Library/Extensions? Si les autorisations sont trop ouvertes, le système refusera de charger les extensions de noyau avec kextload ou kextutil. Le dossier /Library/Extension doit appartenir à root:wheel et personne, à l'exception de root, ne peut écrire dans ce dossier.

Il en va de même pour les autorisations d'accès des extensions, qui sont des ensembles (.kext) et donc des répertoires. Ils doivent appartenir à root:wheel et seule la variable root peut être autorisée en écriture.

Si vous regardez le code source de macOS (oui, macOS est largement OpenSource, les gens ont tendance à l'oublier), vous voyez que cette erreur est renvoyée à un seul endroit:

if (authOptions->requireSecureLocation) {
    if (!kextIsInSecureLocation(theKext)) {
        OSKextLogCFString(NULL,
                          kOSKextLogErrorLevel | kOSKextLogValidationFlag,
                          CFSTR("Kext rejected due to insecure location: %@"),
                          theKext);
        result = false;
        goto finish;
    }
}

Maintenant, kextIsInSecureLocation() est très simple:

Boolean
kextIsInSecureLocation(OSKextRef theKext)
{
    NSURL *url = (__bridge NSURL *)OSKextGetURL(theKext);
    if (!url) {
        return false;
    }
    return pathIsSecure(url.path);
}

Et ainsi est pathIsSecure():

Boolean
pathIsSecure(NSString *path) {
    Boolean is_secure = false;
    BOOL is_protected_volume = rootless_protected_volume(path.UTF8String) ? YES : NO;
    BOOL is_trusted_path = rootless_check_trusted_class(path.UTF8String, "KernelExtensionManagement") == 0 ? YES : NO;

    if (isSIPDisabled()) {
        // SIP is disabled so everything is considered secure.
        is_secure = true;
    } else if (!is_protected_volume) {
        // SIP is enabled and the volume is not protected, so it's insecure.
        is_secure = false;
    } else {
        // SIP is enabled and it is a protected volume, so it's only secure if it's trusted.
        is_secure = is_trusted_path;
    }
    return is_secure;
}

Donc, avec SIP désactivé, tout chemin est sécurisé, avec SIP activé, les volumes sans support SIP ne sont jamais sécurisés, sinon il semble y avoir une liste de chemins sécurisés et je sais pour Assurez-vous que /Library/Extensions est un tel chemin de confiance, mais uniquement si son autorisation est définie correctement.

Pour vérifier si votre volume prend en charge SIP, ouvrez l'application Disk Utility, sélectionnez votre volume de démarrage et appuyez sur CMD+I. Une fenêtre s'ouvre qui répertorie tous les types de propriétés et parmi celles-ci, une devrait être:

System Integrity Protection supported : Yes

Si la réponse est non, vous auriez certainement un problème, mais je ne sais pas lequel, car aucun moyen d’en activer/désactiver SIP pour des volumes individuels est connu, j’imagine seulement que certains systèmes de fichiers ou certains volumes montés sur le système réseau peut ne pas être en mesure de prendre en charge SIP.

Mise à jour (2018-07-31)

Contactant Apple à ce sujet, ils m'ont donné le conseil suivant:

De plus, au cas où cela serait utile, Sudo kextcache --clear-staging permet à un utilisateur d'effacer le dossier /Library/StagedExtensions sans démarrer dans la récupération.

Je ne sais pas si cela résout le problème dans des cas similaires, il suffit de partager cette information avec vous ici.

0
Mecki