Signatur und Notarisierung jeder Mac-App im Terminal prüfen

Gatekeeper führt diese Prüfung automatisch aus, sobald Sie eine heruntergeladene App zum ersten Mal öffnen, und meist sehen Sie die Details nie — ein Dialog erscheint, Sie klicken sich durch, fertig. In diesem Lab geht es darum, zu sehen, was Gatekeeper gesehen hat: welcher Entwickler die App signiert hat, ob diese Signatur intakt ist, ob Apples Notariatsdienst sie geprüft hat, und was sie tun darf, sobald sie läuft. Jeder Befehl hier gehört zu Xcodes Kommandozeilen-Tools (xcode-select --install, falls Sie sie noch nicht haben), und jeder davon ist rein lesend — Sie untersuchen die App, verändern sie aber nicht.

Die Signatur selbst: codesign -dvvv

codesign ist Apples Werkzeug zum Erstellen und Untersuchen von Code-Signaturen. Die Option -d zeigt Informationen über den signierten Code an einem Pfad an, und laut Manpage „erzeugen steigende Stufen von Ausführlichkeit mehr Ausgabe“ — -dvvv (display, drei Stufen verbose) liefert Ihnen also mit einem Befehl das vollständige Bild:

$ 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

Vier Felder, die Sie jedes Mal lesen sollten. Authority ist die Zertifikatskette: Eine normale, externe App sollte über die Developer ID Certification Authority in der Apple Root CA enden, wobei die oberste Zeile den Entwickler nennt. Team Identifier ist Apples zehnstellige ID für das Entwicklerkonto — der Wert, den Sie über Apps hinweg vergleichen, von denen Sie annehmen, dass sie vom selben Unternehmen stammen, da er sich zwischen deren Releases nicht ändert. flags=0x10000(runtime) bedeutet, dass die Hardened Runtime aktiviert ist, eine Reihe zusätzlicher Einschränkungen (etwa Widerstand gegen Code-Injektion in den Prozess), die Apple für die Notarisierung verlangt. Und das völlige Fehlen einer Authority-Zeile — nur Signature=adhoc — bedeutet, dass die App unsigniert ist oder selbstsigniert, ohne jede Kette zu Apple.

Stimmt die Signatur noch mit den Dateien überein: --verify --deep --strict

Eine Signatur ist ein Versprechen über eine bestimmte Menge an Bytes zum Zeitpunkt der Signierung. --verify prüft, ob dieses Versprechen noch gilt — laut Manpage bestätigt es, „dass der Code an diesen Pfaden signiert ist, dass die Signatur gültig ist und dass alle versiegelten Komponenten unverändert sind“. Zwei zusätzliche Optionen zählen bei einem App-Bundle, das ein Verzeichnis voller verschachtelter Ressourcen, Frameworks und Hilfsprogramme ist, keine einzelne Datei:

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

--deep zählt, weil die Überprüfung verschachtelter Inhalte laut Manpage standardmäßig „auf eine oberflächliche Untersuchung beschränkt ist, die Änderungen am verschachtelten Code möglicherweise nicht erkennt“ — der Deep-Modus prüft rekursiv jedes eingebettete Framework und Hilfsprogramm, nicht nur das äußere Bundle. --strict fügt zusätzliche Prüfungen hinzu, die Apple für wichtig genug hält, um sie nicht standardmäßig zu aktivieren, darunter, dass jeder Symlink im Bundle „auf versiegelte Dateien innerhalb seines Bundles zeigt“, und lehnt einen ab, der außerhalb der App oder auf etwas Unversiegeltes zeigt — ein bekannter Trick, um eine unsignierte Payload in ein ansonsten legitim signiertes Bundle zu schmuggeln. Schlägt eine der Prüfungen fehl, sehen Sie code failed to satisfy specified code requirement oder einen Hinweis, der genau benennt, welches verschachtelte Element nicht mit dem übereinstimmt, was ursprünglich versiegelt wurde — lesen Sie diese Zeile, sie nennt die Datei.

Die Entitlements lesen

Entitlements sind die konkreten Berechtigungen, die die Signatur einer App ihr gewährt — Kamerazugriff, die Fähigkeit, das Netzwerk unsandboxed zu erreichen, das Deaktivieren der Bibliotheksvalidierung und so weiter. codesign -d --entitlements - extrahiert sie; laut Manpage „werden eingebettete Entitlement-Daten ebenso extrahiert und geschrieben nach“ dem angegebenen Pfad, und - bedeutet Standardausgabe:

$ 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/>

Die meisten Entitlements sind unauffällig und entsprechen dem, was die App offensichtlich braucht — dass eine Videotelefonie-App Kamerazugriff anfordert, ist kein Befund. Das eine, bei dem es sich innezuhalten lohnt, ist disable-library-validation: Es bedeutet, dass die App Code von außerhalb ihres eigenen signierten Bundles lädt, was für manche Plugin-basierte Software ein normales Bedürfnis ist und eine weitere Tür öffnet, als die meisten Apps brauchen. Es ist ein Detail, das man sich merkt, kein automatisches Warnsignal, und genau die Art von Detail, das man nicht sieht, ohne danach zu fragen.

Hat Apples Notariatsdienst sie tatsächlich geprüft: spctl und stapler

Eine gültige Signatur beweist nur, dass eine App seit der Signierung durch einen Entwickler nicht verändert wurde — sie sagt nichts darüber aus, ob Apple sie sich angesehen hat. Genau das fügt die Notarisierung hinzu. Apples eigene Dokumentation beschreibt den automatisierten Notariatsdienst so, dass er „Ihre Software auf schädliche Komponenten scannt, auf Probleme bei der Code-Signatur prüft und Ihnen die Ergebnisse zügig zurückgibt“. Wenn die Prüfung besteht, „erzeugt der Notariatsdienst ein Ticket, das Sie an Ihre Software heften; der Notariatsdienst veröffentlicht dieses Ticket außerdem online, wo Gatekeeper es finden kann“.

spctl --assess ist der praktische Weg, Gatekeepers eigene Richtlinien-Engine direkt nach ihrem Urteil zu fragen, statt es selbst zu erschließen. Laut Manpage „führt“ --assess „eine Bewertung der angegebenen Dateien durch“, und -v / --verbose, wiederholt für mehr Detail, wird schlicht als Anfrage nach „ausführlicherer Ausgabe“ beschrieben:

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

source=Notarized Developer ID ist das Ergebnis, das Sie sehen möchten — es bedeutet, dass Gatekeeper eine gültige Developer-ID-Signatur und ein Notarisierungs-Ticket gefunden hat, egal ob dieses Ticket an die App geheftet ist oder online gefunden wurde. Ein Ergebnis von source=Unnotarized Developer ID bedeutet, dass die App signiert ist, Apple sie aber (noch) nicht notarisiert hat, und ein schlichtes rejected bedeutet, dass Gatekeeper den Start in seiner Standardkonfiguration blockieren würde.

Um gezielt die Heftung zu prüfen, sucht xcrun stapler validate nach dem physisch an die App angehefteten Ticket, statt Gatekeeper zu bitten, es online nachzuschlagen — nützlich, um zu bestätigen, dass eine App auch ganz ohne Internetverbindung noch korrekt bewertet wird:

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

Das Quarantäne-Flag: woher die Erststart-Prüfung kommt

Apples Leitfaden zur Plattformsicherheit erklärt, dass „Gatekeeper außerdem die Herkunft von Dateien nachverfolgt, die von heruntergeladener Software geschrieben werden“ und „vor dem erstmaligen Öffnen heruntergeladener Software um Zustimmung des Nutzers bittet“. Der Mechanismus dahinter ist ein erweitertes Attribut, com.apple.quarantine, das Safari, Mail und andere Apps an alles anhängen, was sie aus dem Netzwerk speichern. xattr -l listet es auf, und laut Manpage „bewirkt“ diese Option, „dass sowohl die Attributnamen als auch die zugehörigen Werte angezeigt werden“:

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

Gar keine Ausgabe bedeutet, dass die Datei kein Quarantäne-Flag trägt — entweder wurde sie lokal erstellt, kam über einen Weg an, der das Attribut nicht setzt (manche Archivierungswerkzeuge und Paketmanager überspringen es), oder das Flag wurde manuell mit xattr -d com.apple.quarantine entfernt. Dieser letzte Fall lohnt sich aus einem anderen Grund zu kennen: Es ist ein dokumentierter Weg, wie Menschen Gatekeepers Erststart-Prüfung bei Dateien, denen sie vertrauen oder zu vertrauen glauben, vollständig umgehen — und es lohnt sich, das bewusst zu tun, statt es aus einer unbekannten Anleitung im Terminal einzufügen.

Ein durchgerechneter Vergleich: zwei Apps, die denselben Entwickler behaupten

Eine konkrete Art, all das zusammen zu nutzen: Angenommen, Sie haben zwei Kopien einer App, die beide behaupten, vom selben Unternehmen zu stammen — eine von der eigenen Seite des Entwicklers, eine von einem Link, den Ihnen jemand geschickt hat. Führen Sie codesign -dvvv auf beiden aus und vergleichen Sie die Team Identifier-Zeile — sie ist eine zehnstellige Zeichenkette, gebunden an ein bestimmtes Apple-Entwicklerkonto, und anders als ein Anzeigename oder eine Bundle-ID kann sie eine dritte Partei nicht einfach so reproduzieren, ohne Zugriff auf das Signaturzertifikat dieses Kontos. Zeigen die beiden Kopien unterschiedliche Team Identifier, sehen Sie keine zwei Builds derselben App; Sie sehen zwei verschiedene Signierende, von denen einer nicht der ist, für den sich der Download ausgab. Führen Sie danach spctl --assess -vv auf der verdächtigen Kopie aus — eine abweichende oder fehlende Notarisierungsquelle bei der Kopie, die vorgibt, mit einem notarisierten Original identisch zu sein, ist die Bestätigung, nicht nur ein Hinweis.

Das ganze Bild lesen — und die echten Warnsignale

• Überhaupt keine Authority-Kette, oder eine Kette, die nicht in der Apple Root CA endet — hinter der App steht keine zurechenbare Entwickleridentität.
• codesign --verify schlägt fehl, besonders mit einer Meldung, die eine konkrete verschachtelte Datei nennt — etwas im Bundle hat sich nach der Signierung verändert.
• spctl --assess liefert rejected, oder der Team Identifier in codesign -dvvv stimmt nicht mit dem Entwickler überein, den Sie für dieses Produkt erwarten.
• Ein Quarantäne-Flag, das erkennbar entfernt wurde, bei einer Datei, die Sie nicht selbst heruntergeladen haben, oder die über einen ungewöhnlichen Kanal ankam (ein Skript, ein E-Mail-Anhang, der umbenannt wurde, um wie etwas anderes auszusehen).
• Weit offene Entitlements — vollständiger Festplattenzugriff, deaktivierte Bibliotheksvalidierung, uneingeschränkter Netzwerkzugriff — bei einer App, deren angegebener Zweck sie offensichtlich nicht braucht.

Keine dieser Prüfungen betrachtet, was die App tatsächlich tut, sobald sie läuft und mit dem Netzwerk verbunden ist — das ist eine andere Art von Frage, beantwortet durch das Beobachten ihres Datenverkehrs, nicht ihrer Signatur. Eine saubere Signatur und ein gültiges Notarisierungs-Ticket sind eine echte, bedeutsame Grundlage: Sie sagen aus, dass Apple genau diesen Satz von Bytes gesehen und zum Zeitpunkt der Prüfung keine Probleme bei der Code-Signatur gefunden hat. Sie sind der Anfang, einer App zu vertrauen, nicht das Ende davon.

Wo FireAI und HisnLabs ins Spiel kommen

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 ist das eigene Produkt von HisnLabs: eine KI-Firewall für den Mac, die direkt auf dem Gerät läuft. Sie zeigt jede Verbindung Ihrer Apps in verständlicher Sprache und lässt Sie entscheiden, was Ihren Mac verlässt — die KI arbeitet lokal, Ihr Datenverkehr wird also nie an uns oder irgendjemand anderen gesendet. Das Sicherheitsforschungsteam von HisnLabs sorgt dafür, dass diese Entscheidungen verlässlich bleiben: Es katalogisiert, welche Domains gewöhnliche Telemetrie und welche ein echter Dienst sind, verfolgt Land und Netzwerk hinter einer Verbindung und trainiert das lokale Modell (die Autopilot-Funktion) mit echten Verkehrsmustern — ohne dass irgendetwas davon Ihren Mac verlässt.

Die technischen Entscheidungen dahinter können Sie nachlesen — oder FireAI 17 Tage lang ausprobieren — unter FireAI, von HisnLabs.