Blockierte CI-Werkzeuge auf einem Cloud Mac sicher prüfen und freigeben

Ein Build-Job läuft im interaktiven Terminal problemlos, meldet auf einem unbeaufsichtigten Runner jedoch, dass eine Datei nicht geöffnet werden könne oder der Vorgang nicht erlaubt sei. Mitunter beendet sich der Prozess auch unmittelbar nach dem Start. Häufig wird dann zuerst chmod +x ausgeführt. Besitzt die Datei aber bereits Ausführungsrechte, wird sie meist von Gatekeeper, der Codesignaturprüfung oder einem Quarantäneattribut blockiert, das eine heruntergeladene Datei mitbringt. Typische Auslöser sind Werkzeuge, die über einen Browser heruntergeladen wurden, aus anderen Sitzungen kopierte Artefakte oder aus einem Archiv wiederhergestellte Caches, in dem erweiterte Attribute erhalten blieben.

Zuerst vier Arten von Ausführungsfehlern unterscheiden

Löschen Sie nicht sofort Attribute, nur weil sich eine Datei nicht ausführen lässt. Erfassen Sie zunächst Dateityp, Berechtigungen, Architektur und erweiterte Attribute. Diese vier Ergebnisse reichen aus, um die meisten Fehldiagnosen auszuschließen.

TOOL="/opt/build-tools/example-tool"

ls -leO@ "$TOOL"
file "$TOOL"
uname -m
xattr -l "$TOOL"

Mit ls prüfen Sie den Eigentümer und die Ausführungsbits. file muss eine ausführbare Architektur anzeigen, die zum Knoten passt. Erscheint bei xattr der Eintrag com.apple.quarantine, belegt das lediglich, dass die Datei eine Quarantäneprüfung durchlaufen hat. Es ist kein unmittelbarer Nachweis dafür, dass die Datei sicher ist. Bei Permission denied sollten Sie zuerst prüfen, ob die übergeordneten Verzeichnisse durchlaufen werden dürfen und ob für den Mountpoint Ausführungsbeschränkungen gelten. Bei Bad CPU type in executable benötigen Sie ein Artefakt für die richtige Architektur, statt das Quarantäneattribut zu bearbeiten.

Das Quarantäneattribut ist ein Hinweis auf die Herkunft und nicht der Fehler selbst. Weisen Sie zuerst nach, dass Sie die erwartete Datei vorliegen haben, und entscheiden Sie erst danach über die Freigabe.

Eindeutige Gatekeeper-Bewertung auslesen

Einzelne Binärdatei oder App bewerten

Prüfen Sie bei einem Kommandozeilenwerkzeug zuerst die Signatur und lassen Sie anschließend die Systemrichtlinie eine Bewertung abgeben. Für ein App-Bundle ersetzen Sie TOOL durch den Pfad der entsprechenden .app.

codesign --display --verbose=4 "$TOOL"
codesign --verify --deep --strict --verbose=2 "$TOOL"
spctl --assess --type execute --verbose=4 "$TOOL"

Ein nicht signiertes internes Werkzeug ist nicht zwangsläufig problematisch. Es muss jedoch aus einem kontrollierten Build-Prozess stammen, während eine Hash-Prüfung seine Integrität belegt. Schlägt die Verifizierung eines vorkompilierten Drittanbieterwerkzeugs fehl, das als signiert angeboten wird, dürfen Sie es nicht weiterverwenden. Beschaffen Sie stattdessen ein vertrauenswürdiges Artefakt neu. Eine veränderte Signatur darf nicht durch das Löschen des Quarantäneattributs verdeckt werden.

Richtlinienprotokoll auslesen

Dialogfenster und die Standardfehlerausgabe des Runners lassen die eigentliche Ursache häufig weg. Lesen Sie direkt nach dem Reproduzieren des Fehlers die neuesten Einträge der Sicherheitsrichtlinie aus. So erkennen Sie den tatsächlich bewerteten Pfad und vermeiden, Cache A zu untersuchen, obwohl in Wirklichkeit Cache B ausgeführt wurde.

log show --last 10m \
  --predicate 'subsystem == "com.apple.security.syspolicy"' \
  --style compact

Vergleichen Sie den protokollierten Pfad einzeln mit command -v, der Runner-Konfiguration und den Skriptvariablen. Besonders symbolische Links führen leicht zu Abweichungen: Der Einstiegspunkt liegt im Werkzeugverzeichnis, während die endgültige Datei aus einem alten Cache stammt.

Identität des Artefakts vor der Freigabe prüfen

Am zuverlässigsten ist es, wenn der Herausgeber des Werkzeugs oder der interne Artefaktprozess einen SHA-256-Hash bereitstellt und die Hash-Datei gemeinsam mit der Werkzeugversion in die Repository-Konfiguration aufgenommen wird. Berechnen Sie nicht erst aus dem Download einen Hash, um anschließend dieselbe Datei damit zu prüfen. Das würde lediglich belegen, dass sich die Datei zwischen den Lesevorgängen nicht verändert hat, nicht aber ihre korrekte Herkunft.

cd /opt/build-tools
shasum -a 256 -c example-tool.sha256
codesign --verify --deep --strict --verbose=2 example-tool

Intern kompilierte Werkzeuge können ohne Signatur für die externe Verteilung auskommen. Mindestens festgehalten werden sollten jedoch die Commit-Version, die Version des Build-Skripts und der erwartete Hash. Wird das Werkzeug als Archiv bereitgestellt, prüfen Sie zuerst das Archiv, entpacken es dann in ein temporäres Verzeichnis und kontrollieren dort die endgültige ausführbare Datei. Ersetzen Sie erst danach den regulären Pfad atomar. So kann der Runner während einer Aktualisierung keine unvollständige Datei einlesen.

Nur das Quarantäneattribut des Ziels entfernen

Nachdem Hash, Version und Signatur den Erwartungen entsprechen, bearbeiten Sie ausschließlich das verifizierte Ziel. Lesen Sie zunächst den ursprünglichen Wert aus und schreiben Sie ihn in das Jobprotokoll. Löschen Sie anschließend nur das angegebene Attribut.

TOOL="/opt/build-tools/example-tool"

xattr -p com.apple.quarantine "$TOOL" 2>/dev/null || true
if xattr -p com.apple.quarantine "$TOOL" >/dev/null 2>&1; then
  xattr -d com.apple.quarantine "$TOOL"
fi

spctl --assess --type execute --verbose=4 "$TOOL"
"$TOOL" --version

Führen Sie im Workspace nicht xattr -cr . aus. Dadurch würden gleichzeitig verschiedene erweiterte Attribute des Repositorys, der Abhängigkeiten, der Skripte und der temporären Artefakte entfernt. Das vergrößert nicht nur den Freigabebereich, sondern vernichtet auch Herkunftsnachweise für spätere Untersuchungen. Bei einem App-Bundle kann es tatsächlich nötig sein, vererbte Attribute innerhalb des Bundles zu bearbeiten. Der Umfang muss dennoch auf das einzelne verifizierte Bundle begrenzt bleiben und darf nicht auf das gesamte Cache-Stammverzeichnis des Runners ausgeweitet werden.

Prüfungen als Installations-Gate verankern

Eine stabile Cloud-Mac-CI sollte Berechtigungen nicht pro Build-Job behelfsmäßig korrigieren. Lagern Sie die Werkzeugvorbereitung in eine eigene Installationsphase aus: Download in ein temporäres Verzeichnis, Hash-Abgleich, Architekturprüfung, Signaturverifizierung, Auslesen des Quarantänestatus, gezielte Freigabe und Versionsselbsttest. Erst danach wird das Werkzeug in das gemeinsam genutzte Werkzeugverzeichnis geschrieben.

Der Cache-Schlüssel muss mindestens den Werkzeugnamen, die Version, die CPU-Architektur und den Hash enthalten. Auch bei einem Cache-Treffer ist eine einfache Prüfung erforderlich, da der Cache manuell überschrieben worden sein könnte. Beim Start des Runners können id -un, uname -m, der aufgelöste Werkzeugpfad und die Version protokolliert werden. Zugangsdaten oder sämtliche Umgebungsvariablen dürfen dabei nicht ausgegeben werden.

Halten Sie abschließend drei Grundsätze für Fehlerfälle fest: Bei einem abweichenden Hash sofort abbrechen; ein Artefakt neu beschaffen, wenn eine erwartete Signatur nicht verifiziert werden kann; das Attribut nur dann am konkreten Ziel löschen, wenn ausschließlich die Quarantänebewertung das bereits verifizierte Artefakt blockiert. Das erfordert einige Befehle mehr als ein globales Abschalten der Prüfungen, macht aber die Herkunft des Werkzeugs, den Freigabevorgang und die tatsächlich ausgeführte Version vollständig auditierbar.

Häufig gestellte Fragen