Vérifiez la signature et la notarisation de n'importe quelle application Mac à partir du terminal

Gatekeeper exécute cette vérification automatiquement la première fois que vous ouvrez une application téléchargée, et la plupart du temps, vous ne voyez jamais les détails : une boîte de dialogue apparaît, vous cliquez dessus, c'est fait. Cet atelier vise à voir ce que Gatekeeper a vu : quel développeur a signé l'application, si cette signature est intacte, si le service notarial d'Apple l'a vérifiée et ce qu'il est autorisé à faire une fois qu'elle est exécutée. Chaque commande ici est livrée avec les outils de ligne de commande de Xcode (xcode-select --install si vous ne les avez pas encore), et chacune d'elles est en lecture seule - vous inspectez et ne modifiez pas l'application.

La signature elle-même : codedesign -dvvv

codedesign est l’outil d’Apple pour créer et inspecter les signatures de code. L'indicateur -d affiche des informations sur le code signé au niveau d'un chemin, et selon sa page de manuel, "L'augmentation des niveaux de verbosité produit plus de sortie" - donc -dvvv (affichage, trois niveaux de verbeux) vous donne une image complète en une seule commande :

Terminal — détails complets de la signature

$ codesign -dvvv /Applications/Example.app
# example output, trimmed to the fields that matter
Executable=/Applications/Example.app/Contents/MacOS/Example
Identifier=com.example.app
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=... flags=0x10000(runtime) hashes=...
Signature size=4741
Authority=Developer ID Application: Example Software LLC (ABCDE12345)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Team Identifier=ABCDE12345
Runtime Version=14.0.0

Quatre champs à lire à chaque fois. Authority est la chaîne de certificats : une application externe normale doit se terminer par Apple Root CA via Developer ID Certification Authority, la ligne supérieure nommant le développeur. Team Identifier est l'identifiant à dix caractères d'Apple pour le compte développeur - la valeur à comparer entre les applications qui, selon vous, proviennent de la même entreprise, car elle ne change pas entre leurs versions. flags=0x10000(runtime) signifie que le runtime renforcé est activé, un ensemble de restrictions supplémentaires (comme résister à l'injection de code dans le processus) dont Apple a besoin pour la notarisation. Et l'absence de toute ligne Authority - juste Signature=adhoc - signifie que l'application n'est pas signée ou auto-signée sans aucune chaîne avec Apple.

La signature correspond-elle toujours aux fichiers : --verify --deep --strict

Une signature est une promesse concernant un ensemble spécifique d'octets au moment de la signature. --verify vérifie si cette promesse est toujours valable — selon la page de manuel, il confirme "que le code de ces chemins est signé, que la signature est valide et que tous les composants scellés ne sont pas modifiés". Deux indicateurs supplémentaires sont importants pour un app bundle, qui est un répertoire rempli de ressources imbriquées, de frameworks et d'exécutables d'assistance, et non d'un seul fichier :

Terminal – vérification approfondie et stricte

$ codesign --verify --deep --strict --verbose=2 /Applications/Example.app
/Applications/Example.app: valid on disk
/Applications/Example.app: satisfies its Designated Requirement

--deep est important car, selon la page de manuel, la vérification du contenu imbriqué est par défaut "limitée à une enquête superficielle qui peut ne pas détecter les modifications apportées au code imbriqué" - le mode approfondi vérifie de manière récursive chaque framework intégré et outil d'assistance, pas seulement le bundle externe. --strict ajoute des contrôles supplémentaires qu'Apple considère comme suffisamment importants pour ne pas être activés par défaut, notamment le fait que tout lien symbolique à l'intérieur du bundle "pointe vers des fichiers scellés à l'intérieur de son bundle", rejetant celui qui pointe vers l'extérieur de l'application ou vers quelque chose de non scellé - une astuce connue pour introduire clandestinement une charge utile non signée dans un bundle par ailleurs légitimement signé. Si l'une ou l'autre des vérifications échoue, vous verrez code failed to satisfy specified code requirement ou une note nommant exactement quel élément imbriqué ne correspond pas à ce qui a été initialement scellé – lisez cette ligne, elle nomme le fichier.

Lecture des droits

Les droits sont les autorisations spécifiques que la signature d'une application lui accorde : accès à la caméra, possibilité d'accéder au réseau sans bac à sable, désactivation de la validation de la bibliothèque, etc. codesign -d --entitlements - les extrait ; selon la page de manuel, « Les données de droits intégrées seront également extraites et écrites dans » le chemin indiqué, et - signifie sortie standard :

Terminal – les droits déclarés d'une application

$ codesign -d --entitlements - /Applications/Example.app
# example output, trimmed
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
<key>com.apple.security.network.client</key>
<true/>
<key>com.apple.security.device.camera</key>
<true/>

La plupart des droits sont banals et correspondent à ce dont l'application a évidemment besoin : une application d'appel vidéo demandant l'accès à la caméra n'est pas une découverte. Celui sur lequel il convient de s'arrêter est disable-library-validation : cela signifie que l'application chargera le code depuis l'extérieur de son propre bundle signé, ce qui est un besoin normal pour certains logiciels basés sur des plugins et une porte plus large que celle requise par la plupart des applications. C’est un détail à noter, pas un signal d’alarme automatique, et c’est exactement le genre de détail que vous ne pouvez pas voir sans le demander.

Le service notarial d'Apple l'a-t-il réellement vérifié : spctl et agrafeuse

Une signature valide prouve uniquement qu’une application n’a pas été modifiée depuis qu’un développeur l’a signée – elle ne dit rien si Apple l’a examinée. C'est ce qu'ajoute la notarisation. La propre documentation d'Apple décrit le service de notaire automatisé comme analysant « votre logiciel à la recherche de composants malveillants, vérifiant les problèmes de signature de code et vous renvoyant rapidement les résultats ». Lorsqu'il réussit, "le service notarial génère un ticket que vous pouvez agrafer à votre logiciel ; le service notarial publie également ce ticket en ligne où Gatekeeper peut le trouver".

spctl --assess est le moyen pratique de demander son verdict au moteur de politique de Gatekeeper plutôt que de le déduire vous-même. Selon sa page de manuel, --assess "effectuer[s] une évaluation sur les fichiers fournis", et -v / --verbose, répété pour plus de détails, est simplement décrit comme demandant une "sortie plus détaillée" :

Terminal – Propre évaluation du Gatekeeper

$ spctl --assess -vv /Applications/Example.app
/Applications/Example.app: accepted
source=Notarized Developer ID

source=Notarized Developer ID est le résultat que vous souhaitez voir — cela signifie que Gatekeeper a trouvé une signature d'ID de développeur valide et un ticket de notarisation, que ce ticket soit agrafé à l'application ou ait été trouvé en ligne. Un résultat de source=Unnotarized Developer ID signifie que l'application est signée mais qu'Apple ne l'a pas (ou pas encore) notariée, et un plat rejected signifie que Gatekeeper l'empêcherait de se lancer dans sa configuration par défaut.

Pour vérifier spécifiquement l'agrafe, xcrun stapler validate recherche le ticket physiquement attaché à l'application plutôt que de demander à Gatekeeper de le rechercher en ligne – utile pour confirmer qu'une application sera toujours évaluée correctement sans aucune connexion Internet :

Terminal — vérification du ticket agrafé

$ xcrun stapler validate /Applications/Example.app
Processing: /Applications/Example.app
The validate action worked!

Le drapeau de quarantaine : d’où vient le contrôle de première passe

Le guide de sécurité de la plate-forme d'Apple explique que "Gatekeeper suit également la provenance des fichiers écrits par les logiciels téléchargés" et "demande l'approbation de l'utilisateur avant d'ouvrir le logiciel téléchargé pour la première fois". Le mécanisme derrière cela est un attribut étendu, com.apple.quarantine, que Safari, Mail et d'autres applications attachent à tout ce qu'elles enregistrent sur le réseau. xattr -l le répertorie, et selon la page de manuel, cette option « provoque l'affichage des noms d'attribut et des valeurs correspondantes » :

Terminal : vérifier si un fichier est toujours marqué comme téléchargé

$ xattr -l ~/Downloads/Example.dmg
com.apple.quarantine: 0081;65e1a2b3;Safari;

Aucune sortie signifie que le fichier ne porte aucun indicateur de quarantaine - soit il a été créé localement, est arrivé par un chemin qui ne définit pas l'attribut (certains outils d'archives et gestionnaires de packages l'ignorent), soit l'indicateur a été supprimé manuellement avec xattr -d com.apple.quarantine. Ce dernier cas mérite d'être connu pour une raison différente : il s'agit d'une manière documentée par laquelle les gens contournent complètement la vérification de première exécution de Gatekeeper, sur les fichiers auxquels ils font confiance ou pensent faire confiance, et cela vaut la peine d'être réfléchi plutôt que de coller un ensemble d'instructions de terminal inconnu.

Une comparaison réussie : deux applications revendiquant le même développeur

Une manière concrète d’utiliser tout cela ensemble : disons que vous disposez de deux copies d’une application qui prétendent toutes deux provenir de la même entreprise, l’une provenant du propre site du développeur et l’autre provenant d’un lien que quelqu’un vous a envoyé. Exécutez codesign -dvvv sur les deux et comparez la ligne Team Identifier - il s'agit d'une chaîne de dix caractères liée à un compte de développeur Apple spécifique, et contrairement à un nom d'affichage ou à un identifiant de bundle, ce n'est pas quelque chose qu'une seconde partie peut reproduire avec désinvolture sans accès au certificat de signature de ce compte. Si les deux copies affichent des identifiants d'équipe différents, vous ne regardez pas deux versions de la même application ; vous regardez deux signataires différents, dont l'un n'est pas celui revendiqué par le téléchargement. Suivez cela avec spctl --assess -vv sur la copie suspecte – une source notariée incompatible ou absente sur la copie qui prétend être identique à un original notarié est la confirmation, pas seulement un indice.

Lire l’ensemble du tableau et les véritables signaux d’alarme

Aucune chaîne Authority, ou une chaîne qui ne se termine pas par Apple Root CA – l'application n'a aucune identité de développeur responsable derrière elle.
codesign --verify échoue, en particulier avec un message nommant un fichier imbriqué spécifique – quelque chose à l'intérieur du bundle a changé après sa signature.
spctl --assess renvoie rejected, ou l'identifiant d'équipe dans codesign -dvvv ne correspond pas au développeur que vous attendez pour ce produit.
Un indicateur de quarantaine qui a été clairement supprimé sur un fichier que vous n'avez pas téléchargé vous-même ou qui est arrivé via un canal inhabituel (un script, une pièce jointe d'e-mail renommée pour ressembler à autre chose).
Des droits largement ouverts – accès complet au disque, validation de bibliothèque désactivée, accès réseau illimité – sur une application dont l’objectif déclaré n’en a évidemment pas besoin.

Aucune de ces vérifications ne porte sur ce que fait réellement l’application une fois qu’elle est exécutée et connectée au réseau – c’est un autre type de question, à laquelle on répond en surveillant son trafic plutôt que sa signature. Une signature propre et un ticket d'authentification valide constituent un véritable fondement significatif : ils disent qu'Apple a vu cet ensemble exact d'octets et n'a trouvé aucun problème de signature de code au moment de la vérification. C’est le début de la confiance dans une application, pas la fin.

Le rôle de FireAI et de HisnLabs

A clean signature and a stapled ticket say an app hasn’t been tampered with since Apple checked it — they say nothing about what it connects to afterward, which is the question FireAI’s per-app rules and on-device review are built to keep answering, signature by signature, connection by connection.

FireAI est le produit de HisnLabs : un pare-feu IA embarqué pour Mac. Il montre en langage clair chaque connexion faite par vos applications et vous laisse décider ce qui sort de votre Mac — son IA fonctionne en local, votre trafic ne nous est jamais envoyé, ni à personne d’autre. L’équipe de recherche en sécurité de HisnLabs est celle qui garde ces décisions fiables : elle recense les domaines de simple télémétrie face à ceux d’un vrai service, suit le pays et le réseau derrière une connexion, et entraîne le modèle embarqué (la fonction Autopilot) sur du trafic réel, sans que rien ne quitte votre Mac.

Vous pouvez lire les choix techniques qui s’y trouvent, ou essayer FireAI pendant 17 jours, sur FireAI, par HisnLabs.