Sicherheitsrichtlinie „Startup Disk“ bei Mac-Computern mit Apple Chips

Übersicht

Im Gegensatz zu einem Intel-basierten Mac werden bei einem Mac mit Apple Chips die Sicherheitsrichtlinien auf der Ebene einzelner Betriebssysteme festgelegt. Das bedeutet, dass auf demselben Mac mehrere installierte Instanzen von macOS mit unterschiedlichen Versionen und Sicherheitsrichtlinien unterstützt werden. Aus diesem Grund wurde das Startsicherheitsdienstprogramm um eine Option zur Auswahl des gewünschten Betriebssystems ergänzt.

Auf einem Mac mit Apple Chips gibt das Systemsicherheitsdienstprogramm den generellen, vom Benutzer konfigurierten Sicherheitsstatus von macOS an, wie etwa das Starten einer Kernel-Erweiterung oder die Konfiguration des Systemintegritätsschutzes (System Integrity Protection, SIP). Wenn das Ändern der Sicherheitseinstellung zur Folge hat, dass die Sicherheit deutlich herabgesetzt und das System anfälliger für Aktionen wird, die es kompromittieren können, müssen Benutzer den recoveryOS-Prozess starten, indem sie die Taste „Ein/Aus“ („Power Button“) gedrückt halten, um diese Änderung vorzunehmen. (Das entsprechende Signal kann dann nicht durch Schadsoftware ausgelöst werden, sondern nur von einer Person, die physischen Zugang zum Gerät hat.) Aus diesem Grund werden auf einem Mac mit Apple Chips keine Firmware-Passwörter vorausgesetzt (oder unterstützt) – alle kritischen Änderungen werden bereits von der Benutzerauthentifizierung abgesichert. Weitere Informationen zu SIP sind unter Systemintegritätsschutz zu finden.

Die Einstellungen „Volle Sicherheit“ und „Reduzierte Sicherheit“ können mit dem Startsicherheitsdienstprogramm von recoveryOS festgelegt werden. Die Einstellung „Permissive Sicherheit“ kann dagegen nur per Befehlszeilenprogramm durch Benutzer festgelegt werden, die sich des Risikos bewusst sind, dass mit dieser Einstellung ihr Mac viel an Sicherheit einbüßt.

Richtlinie „Volle Sicherheit“

„Volle Sicherheit“ ist die Standardeinstellung, die ein Verhalten wie bei iOS und iPadOS zur Folge hat. Wenn Software heruntergeladen und für die Installation vorbereitet wird, verwendet macOS nicht die zur Software gehörige globale Signatur, sondern fordert bei dem Apple-Signierungsserver, der auch für iOS und iPadOS verwendet wird, eine neue „personalisierte“ Signatur an. Eine Signatur gilt als personalisiert, wenn sie die Exclusive Chip Identification (ECID) – eine eindeutige ID, die in diesem Fall für die Apple-CPU spezifisch ist – als Teil der Signierungsanfrage umfasst. Die vom Signierungsserver zurückgegebene Signatur ist dann eindeutig und nur für diese spezifische Apple-CPU nutzbar. Wenn die Richtlinie „Volle Sicherheit“ aktiv ist, stellen der Boot-ROM und LLB sicher, dass eine bestimmte Signatur nicht nur von Apple signiert, sondern für den spezifischen Mac signiert wird. Auf diese Weise wird die jeweilige Version von macOS an diesen Mac gebunden.

Die Verwendung eines Online-Signierungsservers bietet auch mehr Schutz vor Rollback-Angriffen als typische Ansätze mit globalen Signaturen. In einem globalen Signierungssystem könnte die Sicherheitsepoche mehrfach fortgeführt worden sein, ohne dass dies einem System, das nicht die neueste Firmware kennt, bekannt ist. Beispielsweise akzeptiert aktuell ein Computer in der Annahme, in Sicherheitsepoche 1 zu sein, Software von Sicherheitsepoche 2, auch wenn 5 die tatsächliche aktuelle Sicherheitsepoche ist. Mit dem Online-Signierungssystem bei Apple Chips kann der Signierungsserver das Erstellen von Signaturen für jegliche Software ablehnen, die sich nicht in der neuesten Sicherheitsepoche befindet.

Hinzu kommt, dass ein Angreifer, der nach einer Änderung der Sicherheitsepoche eine Schwachstelle entdeckt, nicht einfach die anfällige Software einer früheren Epoche von System A nehmen und auf System B anwenden kann, um es anzugreifen. Dadurch dass die anfällige Software einer älteren Epoche für System A personalisiert wurde, ist sie nicht übertragbar und kann nicht für einen Angriff auf System B verwendet werden. Das Zusammenwirken all dieser Mechanismen bietet eine stärkere Gewähr dafür, dass Angreifer nicht gezielt anfällige Software auf einem Mac platzieren können, um die Schutzvorkehrungen der neuesten Software zu umgehen. Ein Benutzer, der über den Namen und das Passwort eines Administrators für den Mac verfügt, kann jederzeit die Sicherheitsrichtlinie auswählen, die sich für seine Zwecke am besten eignet.

Richtlinie „Reduzierte Sicherheit“

Die reduzierte Sicherheit ähnelt im Verhalten der „mittleren“ Sicherheit bei Intel-basierten Mac-Computern mit einem T2-Chip; hier generiert der jeweilige Lieferant (in diesem Fall Apple) eine digitale Signatur für den Code, die belegt, dass der Code von dem betreffenden Lieferanten stammt. Angreifer haben so keine Möglichkeit, nicht signierten Code einzuschleusen. Diese Signatur wird von Apple als „globale“ Signatur bezeichnet, weil sie auf einem beliebigen Mac für beliebig lange Zeit verwendet werden kann, sofern auf diesem Mac die reduzierte Sicherheit konfiguriert ist. Die reduzierte Sicherheit selbst bietet keinen Schutz vor Rollback-Angriffen (obwohl nicht autorisierte Änderungen am Betriebssystem dazu führen können, dass nicht mehr auf Benutzerdaten zugegriffen werden kann). Weitere Informationen sind unter Kernel-Erweiterungen auf einem Mac mit Apple Chips zu finden.

Außer Benutzern zu ermöglichen, auch ältere Versionen von macOS ausführen zu können, ist die reduzierte Sicherheit Voraussetzung für andere Aktionen, die ein Sicherheitsrisiko für das System mit sich bringen, beispielsweise das Hinzufügen von Kernel-Erweiterungen (KEXTs) von Drittanbietern. Kernel-Erweiterungen haben dieselben Berechtigungen wie der Kernel, weshalb Schwachstellen und Sicherheitslücken in Kernel-Erweiterungen von Drittanbietern dazu führen können, dass das gesamte Betriebssystem kompromittiert wird. Aus diesem Grund sind Entwickler angehalten, Systemerweiterungen zum Einsatz zu bringen, bevor bei künftigen Mac-Computern mit Apple Chips die Unterstützung für Kernel-Erweiterungen durch macOS entfernt wird. Auch wenn Kernel-Erweiterungen von Drittanbietern aktiviert werden, können sie nicht „on demand“ in den Kernel geladen werden. Die Kernel-Erweiterungen werden vielmehr in einer Auxiliary Kernel Collection (AuxKC) zusammengeführt, deren Hash in der LocalPolicy-Datei gesichert wird. Deshalb ist ein Neustart erforderlich. Weitere Informationen zur AuxKC-Generierung sind unter Sichere Erweiterung des Kernels in macOS zu finden.

Richtlinie „Permissive Sicherheit“

Die Richtlinie „Permissive Sicherheit“ ist für Benutzer gedacht, die sich des Risikos bewusst sind, dass dieser Modus die Sicherheit ihres Mac-Computers deutlich beeinträchtigt. Dieser Modus unterscheidet sich vom Modus „Ohne Sicherheit“ bei Intel-basierten Mac-Computern mit T2-Chip. Bei der permissiven Sicherheit erfolgt die Signaturprüfung zwar weiterhin über die gesamte Startkette, durch das Herabstufen der Richtlinie auf „Permissiv“ wird iBoot aber angewiesen, lokal in der Secure Enclave signierte Startobjekte zu akzeptieren, beispielsweise eine vom Benutzer generierte Boot Kernel-Sammlung, die aus einem angepassten XNU-Kernel erstellt wird. Auf diese Weise bietet der Modus „Permissive Sicherheit“ architekturbasiert die Möglichkeit, einen beliebigen Kernel für ein „Betriebssystem ohne jegliche Vertrauenswürdigkeit“ auszuführen. Wenn eine angepasste Boot Kernel-Sammlung oder ein Betriebssystem ohne jegliche Vertrauenswürdigkeit geladen wird, stehen bestimmte Entschlüsselungsschlüssel nicht mehr zur Verfügung. Dadurch wird verhindert, dass ein nicht vertrauenswürdiges Betriebssystem auf Daten vertrauenswürdiger Betriebssysteme zugreift.

Die permissive Sicherheit unterscheidet sich auf eine weitere Weise vom Modus „Ohne Sicherheit“ auf Intel-basierten Mac-Computern mit T2-Chip. Sie ist eine Voraussetzung für einige Herabstufungen der Sicherheit, die in der Vergangenheit unabhängig voneinander gesteuert werden konnten. Das wichtigste Beispiel ist, dass Benutzer zum Deaktivieren des Systemintegritätsschutzes (System Integrity Protection, SIP) auf einem Mac mit Apple Chips explizit bestätigen müssen, dass sie das System in den Modus „Permissive Sicherheit“ versetzen möchten. Dies wird gefordert, da das Deaktivieren von SIP das System immer schon in einen Zustand versetzt hat, in dem der Kernel sehr viel einfacher kompromittiert werden kann. Wird SIP auf einem Mac mit Apple Chips deaktiviert, wird insbesondere auch das Erzwingen der KEXT-Signatur(en) im Zuge der AuxKC-Generierung deaktiviert, was dazu führt, dass beliebige KEXT-Erweiterungen in den Kernel-Arbeitsspeicher geladen werden können. Auf Mac-Computern mit Apple Chips wurde SIP außerdem insofern verbessert, als der Richtlinienspeicher aus dem NVRAM in die LocalPolicy-Datei verlagert wurde. So wird erreicht, dass das Deaktivieren von SIP durch einen Benutzer authentifiziert werden muss, der Zugriff auf den Signierschlüssel der lokalen Richtlinie hat; diesen Zugriff erhält er aber nur während des recoveryOS-Prozesses, den er durch Gedrückthalten der Taste „Ein/Aus“ („Power Button“) initiiert. Dadurch wird es für einen auf die Software abzielenden Angreifer und selbst für einen Angreifer, der physisch anwesend ist, deutlich schwerer, SIP zu deaktivieren.

Im Startsicherheitsdienstprogramm ist eine Herabstufung in den Modus „Permissive Sicherheit“ nicht möglich. Benutzer können nur Befehlszeilendienstprogramme wie csrutil (zur Deaktivierung der SIP) in Terminal ausführen, um die Herabstufung vorzunehmen. Nach der Herabstufung durch den Benutzer wird dieser Modus im Startsicherheitsdienstprogramm angezeigt, sodass Benutzer leicht einen Sicherheitsmodus auswählen können, der mehr Sicherheit bietet.