Startet man ein Programm im modernen macOS, überprüfen unterschiedliche Subroutinen, ob es die von macOS aufgestellten Anforderungen und Erwartungen erfüllt. Dank aktueller leistungsfähiger Prozessoren merken Anwender nur in den seltensten Fällen etwas davon – etwa, wenn die Tests scheitern. Die „Launch Constraints“, zu Deutsch Startbeschränkungen, kamen mit macOS 13 hinzu. Sie definieren, von wo aus eine App starten darf; zudem regeln sie, welche Bibliotheken und Frameworks ausgeführt werden dürfen.


Alte Mac-Hasen sind es gewohnt, ein Programm frei ablegen zu können. Zu klassischen Mac-OS-Zeiten galt: Ob eine Applikation im Programme-Ordner liegt, auf dem Schreibtisch oder auf einer RAM-Disk, war weitgehend unwichtig. Wer das Gleiche mit macOS 13 oder neuer versucht und beispielsweise die DVD-Player-App in den Filme-Ordner kopiert, erlebt bei vielen Programmen eine Überraschung: Eine Fehlermeldung warnt vor einem beschädigten Programm, das am besten gelöscht gehört – trotz identischer Kopie. Zudem erscheint ein Crash Report, was die Dringlichkeit der Warnung unterstreicht. Denn alle von macOS vorinstallierten Programme haben klare Startbeschränkungen. Die meisten dürfen nur von ihrem ursprünglichen Ort aus starten. Das kann beispielsweise der Ordner „Programme“ sein, dessen Unterordner „Dienstprogramme“ oder auch „/System/Library/CoreServices/Applications“.

"Launch Constraints“ definieren Bedingungen
Die Startbeschränkungen in Sonoma kennen 20 Kategorien, die wiederum jeweils eine Kombination aus verschiedenen Regeln definieren. Csaba Fitzl hat sie in einem Dokument versammelt. Viele setzen beispielsweise voraus, dass sich die App von einem autorisierten APFS-Volume oder vom System-Volume befindet. Launch Constraints sind dabei nicht Teil des Programms. Stattdessen verwalte sie der „Trust Cache“, dessen Einträge seien an den Code Directory Hash (cdhash) gekoppelt, erklärt Mac-Veteran Howard Oakley in einem Blog-Beitrag. So werde beim Auslesen der Startbeschränkungen zugleich überprüft, ob die jeweilige App unverändert sei. Außer im Crash Log und in den Fehlermeldungen in der Konsole können Anwender mit dem Notarisierungsinspektor Apparency herausfinden, welche Regel für eine ausgewählte App gilt. Externe Entwickler dürfen ihren Apps ebenfalls Startbeschränkungen auferlegen – dafür gibt es Tipps in der Entwicklerdokumentation.


Deaktivieren nur über SIP
Wer sich nicht vom System nicht vorschreiben lassen will, wo Programme lagern, muss zu groben Mitteln greifen und System Integrity Protection (SIP) deaktivieren. Allerdings bedeutet das bei Weitem keine absolute Regelfreiheit für Apps: Die im TCC-System festgelegten Beschränkungen für Daten- und Ordnerzugriffe gelten ebenso wie die von GateKeeper sowie XProtect vorgenommenen Notarisierungsüberprüfungen beim ersten Start.