![](https://help.apple.com/assets/6537FB06A074DBB5E802EA07/6537FB31280588A5490B6E1D/de_DE/52d714626638d3391623c853be0c593b.png)
Inhalt einer LocalPolicy-Datei für Mac-Computer mit Apple Chips
Die lokale Richtlinie (LocalPolicy-Datei) ist eine von der Secure Enclave signierte Image4-Datei. Image4 ist ein in ASN.1 (Abstract Syntax Notation One) DER-codiertes Datenstrukturformat, mit dem für Apple-Plattformen Informationen über Objekte beschrieben werden, die für den sicheren Startvorgang relevant sind. Bei einem auf Image4 basierten Modell für den sicheren Startvorgang werden Sicherheitsrichtlinien zum Zeitpunkt der Softwareinstallation angefordert. Zu diesem Zweck wird eine Signierungsanfrage an einen zentralen Apple-Signierungsserver gesendet. Wenn die Richtlinie akzeptabel ist, sendet der Signierungsserver eine signierte Image4-Datei zurück, die eine Vielzahl von jeweils vier Zeichen langen Codesequenzen (4CC) enthält. Diese signierten Image4-Dateien und 4CCs werden während des Systemstarts von Software wie dem Boot-ROM oder LLB evaluiert.
Übergabe des Eigentümerstatus zwischen Betriebssystemen
Der Zugriff auf den OIK (Owner Identity Key) wird als „Eigentümerstatus“ bezeichnet. Der Eigentümerstatus ist notwendig, um es Benutzern zu erlauben, die LocalPolicy-Datei nach dem Ändern der Richtlinie oder Software erneut zu signieren. Der OIK wird mit derselben Schlüsselhierarchie geschützt, die unter Sealed Key Protection (SKP) beschrieben ist. Dabei wird der OIK mit demselben KEK (Key Encryption Key) wie der VEK (Volume Encryption Key) geschützt. Das bedeutet, dass er im Normalfall sowohl mit den Benutzerpasswörtern als auch den Spezifikationen des Betriebssystems und der Richtlinie geschützt ist. Es gibt nur einen OIK für alle Betriebssysteme auf dem Mac. Aus diesem Grund ist beim Installieren eines zweiten Betriebssystems die ausdrückliche Zustimmung des Benutzers auf dem ersten Betriebssystem erforderlich, um den Eigentümerstatus an den Benutzer auf dem zweiten Betriebssystem zu übergeben. Allerdings existieren für das zweite Betriebssystem noch keine Benutzer, wenn das Installationsprogramm auf dem ersten Betriebssystem ausgeführt wird. Benutzer werden in Betriebssystemen normalerweise erst generiert, wenn das Betriebssystem gestartet und der Systemassistent ausgeführt wurde. Daher sind zwei neue Schritte erforderlich, wenn ein zweites Betriebssystem auf einem Mac mit Apple Chips installiert wird:
LocalPolicy-Datei für das zweite Betriebssystem erstellen
Benutzerinstallation („Install User“) für die Übergabe des Eigentümerstatus vorbereiten
Wenn ein Installationsassistent gestartet und eine Installation auf einem zweiten leeren Volume durchgeführt wird, wird der Benutzer gefragt, ob er einen Benutzer vom aktuellen Volume auf das zweite Volume als erster Benutzer kopieren möchte. Wenn der Benutzer dies bestätigt, wird die Benutzerinstallation (eigentlich ein vom Passwort und den Hardwareschlüsseln des ausgewählten Benutzers abgeleiteter KEK) für die Verschlüsselung des OIK verwendet, wenn dieser an das zweite Betriebssystem übergeben wird. Im Anschluss fragt der Installationsassistent des zweiten Betriebssystems nach dem Passwort dieses Benutzers, um den Zugriff auf den OIK in der Secure Enclave durch das neue Betriebssystem zu erlauben. Wenn sich Benutzer gegen das Kopieren eines Benutzers entscheiden, wird die Benutzerinstallation trotzdem auf dieselbe Weise ausgeführt, allerdings wird ein leeres Passwort anstatt eines Benutzerpassworts verwendet. Der zweite Prozess ist für bestimmte Systemadministrationsszenarien konzipiert. Benutzer, die Installationen auf verschiedenen Volumes verwenden und die Übergabe des Eigentumsstatus auf die sicherste Art und Weise durchführen möchten, sollten immer einen Benutzer vom ersten Betriebssystem auf das zweite Betriebssystem kopieren.
LocalPolicy-Datei auf einem Mac mit Apple Chips
Bei einem Mac mit Apple Chips wurde die Steuerung für die lokale Sicherheitsrichtlinie an eine Anwendung übergeben, die in der Secure Enclave ausgeführt wird. Diese Software kann ausgehend von den Anmeldeinformationen des Benutzers und dem Startmodus der primären CPU feststellen, wer die Sicherheitsrichtlinie ändern kann und aus welcher Startumgebung heraus dies möglich ist. Dadurch kann verhindert werden, dass Schadsoftware die Steuerung für die Sicherheitsrichtlinie gegen den Benutzer einsetzen kann, indem der Benutzer herabgestuft wird, um danach zusätzliche Rechte und Berechtigungen zu erhalten.
Eigenschaften des LocalPolicy-Manifests
Die LocalPolicy-Datei umfasst einige architekturelle 4CCs, die in nahezu allen Image4-Dateien zu finden sind – beispielsweise Board- oder Modellkennung (BORD), Angabe eines bestimmten Apple-Chips (CHIP) oder Exclusive Chip Identification (ECID). Die im Folgenden beschriebenen 4CCs beschränken sich allerdings auf die Sicherheitsrichtlinien, die vom Benutzer konfiguriert werden können.
Hinweis: Apple bezeichnet mit dem Begriff 1TR (Paired One True recoveryOS) den Prozess, mit dem durch das Drücken der physischen Taste „Ein/Aus“ („Power Button“) das Starten der gekoppelten recoveryOS-Software initiiert wird. Hierin unterscheidet sich dieser Prozess von einem normalen recoveryOS-Start, der über den NVRAM oder durch zweimaliges Drücken und anschließendes Halten bewerkstelligt werden kann bzw. der ausgelöst werden kann, wenn beim Starten ein Fehler auftritt. Das Drücken einer physischen Taste auf eine bestimmte Art und Weise stärkt das Vertrauen darin, dass die Startumgebung für einen Angreifer, der in macOS eingedrungen ist und allein auf die Software abzielt, nicht zugänglich ist.
LocalPolicy Nonce Hash (lpnh)
Typ: OctetString (48)
Veränderbare Umgebungen: 1TR, recoveryOS, macOS
Beschreibung:
lpnh
wird als Maßnahme gegen das Anti-Replay der LocalPolicy-Datei eingesetzt. Hierbei handelt es sich um einen SHA-384-Hash-Wert der Nonce der lokalen Richtlinie (LPN, Local Policy Nonce), der in der Secure Storage-Komponente gespeichert ist und über den Boot-ROM der Secure Enclave oder die Secure Enclave zugänglich ist. Die eigentliche Nonce wird nur gegenüber sepOS, niemals gegenüber dem Anwendungsprozessor offengelegt. Ein Angreifer, der LLB dahingehend manipulieren möchte, dass eine frühere von ihm abgegriffene LocalPolicy-Datei gültig ist, müsste somit einen Wert in der Secure Storage-Komponente platzieren, dessen Hash-Wert identisch mit demlpnh
-Wert aus der lokalen Richtlinie ist, deren Replay ausgelöst werden soll. Im Normalfall ist nur eine einzige LPN im System gültig. Eine Ausnahme dazu besteht nur während einer Softwareaktualisierung. Während dieses Vorgangs sind zwei LPNs gleichzeitig gültig, damit es im Fall eines Fehlers bei der Aktualisierung möglich ist, wieder die alte Software zu starten. Wenn die LocalPolicy-Datei irgendeines Betriebssystems geändert wird, werden alle Richtlinien mit dem neuen lpnh-Wert signiert, der mit dem neuen LPN in der Secure Storage-Komponente korrespondiert. Diese Änderung erfolgt, wenn der Benutzer Änderungen an den Sicherheitseinstellungen vornimmt oder neue Betriebssysteme mit einer jeweils neuen LocalPolicy-Datei erstellt.
Remote Policy Nonce Hash (rpnh)
Typ: OctetString (48)
Veränderbare Umgebungen: 1TR, recoveryOS, macOS
Beschreibung:
rpnh
zeigt das gleiche Verhalten wielpnh
; dieser Wert wird aber nur aktualisiert, wenn die Remote-Richtlinie aktualisiert wird. Das ist zum Beispiel der Fall, wenn der Status der Registrierung für „Wo ist?“ geändert wird. Diese Änderung erfolgt implizit, wenn der Benutzer auf seinem Mac den Status von „Wo ist?“ ändert.
recoveryOS Nonce Hash (ronh)
Typ: OctetString (48)
Veränderbare Umgebungen: 1TR, recoveryOS, macOS
Beschreibung:
ronh
zeigt das gleiche Verhalten wie „lpnh“; dieser Wert ist aber ausschließlich in der lokalen Richtlinie für das recoveryOS des Systems enthalten. Er wird aktualisiert, wenn recoveryOS des Systems (zum Beispiel im Zuge einer Softwareaktualisierung) aktualisiert wird. Die Verwendung dieser separaten Nonce (nebenlpnh
undrpnh
) hat folgenden Grund: Wenn ein Gerät mit „Wo ist?“ in den Status „Deaktiviert“ versetzt wird, können vorhandene Betriebssysteme deaktiviert werden (indem ihre LPN und RPN aus der Secure Storage-Komponente entfernt werden), während zugleich das recoveryOS des Systems seine Startfähigkeit behält. Auf diese Weise können die Betriebssysteme wieder aktiviert werden, wenn der Benutzer des Systems den Nachweis erbringt, dass sich das Gerät wieder unter seiner Kontrolle und Steuerung befindet, indem er das iCloud-Passwort eingibt, das für den „Wo ist?“-Account hinterlegt ist. Diese Änderung erfolgt, wenn ein Benutzer das recoveryOS des Systems aktualisiert oder neue Betriebssysteme erstellt.
Next Stage Image4 Manifest Hash (nsih)
Typ: OctetString (48)
Veränderbare Umgebungen: 1TR, recoveryOS, macOS
Beschreibung: Das Feld „nsih“ steht für den SHA-384-Hash-Wert der Image4-Manifestdatenstruktur, die das gestartete macOS-Betriebssystem beschreibt. Das Image4-Manifest für macOS enthält Kennzahlen für alle Startobjekte (zum Beispiel für iBoot, den statischen Cache für die Vertrauensstellung („Static Trust Cache“), die Gerätestruktur („Device Tree“), die Boot Kernel-Sammlung und den Root-Hash-Wert des Signed System Volume (SSV)). Wenn LLB instruiert wird, ein bestimmtes macOS-Betriebssystem zu starten, stellt LLB sicher, dass der Hash-Wert des Image4-Manifests für macOS, das an iBoot angehängt ist, mit dem Wert übereinstimmt, der im
nsih
-Feld der LocalPolicy-Datei erfasst ist. Auf diesem Weg erfasstnsih
die Absicht des Benutzers, für welches Betriebssystem er eine lokale Richtlinie (LocalPolicy-Datei) erstellt hat. Dernsih
-Wert wird implizit geändert, wenn eine Softwareaktualisierung durchgeführt wird.
Cryptex1 Image4 Manifest Hash (spih)
Typ: OctetString (48)
Veränderbare Umgebungen: 1TR, recoveryOS, macOS
Beschreibung: Das Feld
spih
steht für den SHA-384-Hash-Wert der Image4-Manifestdatenstruktur. Das Cryptex1-Image4-Manifest enthält Kennzahlen seiner Cryptexes, ihrer Dateisystem-Seals (Siegel) und ihrer Caches für die Vertrauensstellung. Während des Startvorgangs von macOS stellen der XNU-Kernel und die PPL (Page Protection Layer) sicher, dass der Hash-Wert des Cryptex1-Image4-Manifests mit dem Wert übereinstimmt, den iBoot gemäß demspih
-Feld der LocalPolicy-Datei veröffentlicht hat. Derspih
-Wert wird implizit geändert, wenn eine schnelle Sicherheitsmaßnahme (Rapid Security Response) installiert oder eine Softwareaktualisierung durchgeführt wird. Der Cryptex1 Image4 Manifest Hash kann unabhängig vom Next Stage Image4 Manifest Hash (nsih) aktualisiert werden.
Cryptex1 Generation (stng)
Typ: Unsignierte 64-Bit-Ganzzahl
Veränderbare Umgebungen: 1TR, recoveryOS, macOS
Beschreibung: Das Feld
stng
enthält einen Zählerwert, der angibt, wann der Cryptex1 Image4 Manifest Hash zuletzt in der LocalPolicy-Datei aktualisiert wurde. Es stellt eine Nonce anstelle vonlpnh
bereit, während die PPL (Page Protection Layer) die lokale Richtlinie für die Anwendung des eingehenden Cryptex auswertet. Derstng
-Wert wird implizit geändert, wenn eine schnelle Sicherheitsmaßnahme (Rapid Security Response) installiert oder eine Softwareaktualisierung durchgeführt wird.
Auxiliary Kernel Collection (AuxKC) Policy Hash (auxp)
Typ: OctetString (48)
Veränderbare Umgebungen: macOS
Beschreibung:
auxp
ist ein SHA-384-Hash-Wert der Richtlinie für die Liste der vom Benutzer autorisierten Kernel-Erweiterungen (UAKL, User-authorized KEXT list). Dieser Wert wird zum Zeitpunkt der AuxKC-Generierung verwendet, um sicherzustellen, dass nur Kernel-Erweiterungen (KEXTs) in die AuxKC übernommen werden, die vom Benutzer autorisiert wurden.smb2
ist erforderlich, um dieses Feld festlegen zu können. Derauxp
-Wert wird implizit geändert, wenn der Benutzer die UAKL-Liste ändert, indem er in „Systemeinstellungen“ > „Datenschutz & Sicherheit“ (macOS 13 oder neuer) oder „Systemeinstellungen“ > „Sicherheit & Datenschutz“ (macOS 12 oder älter) eine Kernel-Erweiterung genehmigt.
Auxiliary Kernel Collection (AuxKC) Image4 Manifest Hash (auxi)
Typ: OctetString (48)
Veränderbare Umgebungen: macOS
Beschreibung: Nachdem das System verifiziert hat, dass der Hash-Wert der UAKL mit dem Wert im Feld
auxp
der lokalen Richtlinie übereinstimmt, veranlasst es, dass die AuxKC vom Prozessor der Secure Enclave signiert wird, der für das Signieren der LocalPolicy-Datei zuständig ist. Danach wird ein SHA-384-Hash-Wert der Image4-Manifestsignatur der AuxKC in der lokalen Richtlinie platziert um die Möglichkeit einer Verwechslung und des fälschlichen Abgleichs einer zu einem früheren Zeitpunkt signierten AuxKC mit einem Betriebssystem auszuschließen. Wenn iBoot das Feldauxi
in der lokalen Richtlinie vorfindet, versucht iBoot, die AuxKC vom Speichermedium zu laden und deren Signatur zu validieren. Außerdem wird geprüft, ob der Hash-Wert des an den AuxKC angeschlossenen Image4-Manifests mit dem Wert im Feldauxi
übereinstimmt. Wenn die AuxKC aus irgendeinem Grund nicht geladen werden kann, setzt das System den Startvorgang ohne dieses Startobjekt fort, d. h. ohne dass irgendwelche Kernel-Erweiterung von Drittanbietern geladen werden. Das Feldauxp
muss vorhanden sein, damit das Feld „auxi“ in der LocalPolicy-Datei festgelegt werden kann. Derauxi
-Wert wird implizit geändert, wenn der Benutzer die UAKL-Liste ändert, indem er in „Systemeinstellungen“ > „Datenschutz & Sicherheit“ (macOS 13 oder neuer) oder „Systemeinstellungen“ > „Sicherheit & Datenschutz“ (macOS 12 oder älter) eine Kernel-Erweiterung genehmigt.
Auxiliary Kernel Collection (AuxKC) Receipt Hash (auxr)
Typ: OctetString (48)
Veränderbare Umgebungen: macOS
Beschreibung:
auxr
ist ein SHA-384-Hash-Wert des AuxKC-Empfangsbelegs; aus ihm geht hervor, welcher Satz von Kernel-Erweiterungen genau in die AuxKC aufgenommen wurde. Bei dem AuxKC-Beleg kann es sich um eine Untermenge der UAKL-Liste handeln, da Kernel-Erweiterungen, die bekanntermaßen für Angriffe genutzt werden können, aus der AuxKC ausgeschlossen werden können, selbst wenn sie vom Benutzer autorisiert wurden. Außerdem können bestimmte Kernel-Erweiterungen, die dafür verwendet werden können, die Begrenzung des Benutzer-Kernels zu umgehen, eine funktionale Einschränkung zur Folge haben, sodass beispielsweise Apple Pay nicht verwendet und 4K/HDR-Inhalte nicht wiedergegeben werden können. Benutzer, die von entsprechenden Möglichkeiten Gebrauch machen möchten, sollten sich für eine restriktivere Form der Aufnahme in die AuxKC entscheiden. Das Feldauxp
muss vorhanden sein, damit das Feldauxr
in der LocalPolicy-Datei festgelegt werden kann. Derauxr
-Wert wird implizit geändert, wenn der Benutzer über „Systemeinstellungen“ > „Datenschutz & Sicherheit“ (macOS 13 oder neuer) oder „Systemeinstellungen“ > „Sicherheit & Datenschutz“ (macOS 12 oder älter) eine neue AuxKC erstellt.
CustomOS Image4 Manifest Hash (coih)
Typ: OctetString (48)
Veränderbare Umgebungen: 1TR
Beschreibung:
coih
ist ein SHA-384-Hash des CustomOS-Image4-Manifest. Die Payload für dieses Manifest wird von iBoot (anstelle des XNU-Kernels) verwendet, um die Steuerung zu übergeben. Dercoih
-Wert wird implizit geändert, wenn der Benutzer daskmutil configure-boot
-Befehlszeilenprogramm in 1TR verwendet.
APFS volume group UUID (vuid)
Typ: OctetString (16)
Veränderbare Umgebungen: 1TR, recoveryOS, macOS
Beschreibung:
vuid
ist die Volumegruppe, die der Kernel als Root (Stamm) verwenden soll. Dieses Feld dient primär der Information; es wird nicht für sicherheitsrelevante Einschränkungen verwendet. Die Festlegung dervuid
erfolgt implizit, wenn der Benutzer eine neue Betriebssysteminstallation erstellt.
Key encryption key (KEK) Group UUID (kuid)
Typ: OctetString (16)
Veränderbare Umgebungen: 1TR, recoveryOS, macOS
Beschreibung:
kuid
ist das gestartete Volume. Der Key Encryption Key wird üblicherweise für Zwecke des Datenschutzes und der Datensicherheit verwendet. Bei jeder LocalPolicy-Datei wird er verwendet, um den Signierschlüssel der lokalen Richtlinie zu schützen. Die Festlegung derkuid
erfolgt implizit, wenn der Benutzer eine neue Betriebssysteminstallation erstellt.
Paired recoveryOS Trusted Boot Policy Measurement (prot)
Typ: OctetString (48)
Veränderbare Umgebungen: 1TR, recoveryOS, macOS
Beschreibung: Das Trusted Boot Policy Measurement der gekoppelten recoveryOS-Software ist eine spezielle iterative SHA-384-Hash-Berechnung auf der Basis des Image4-Manifests einer lokalen Richtlinie und unter Ausschluss von Nonces, um eine konsistente Messung im Zeitablauf zu erhalten (da Nonces wie
lpnh
häufig aktualisiert werden). Das Feldprot
ist nur in lokalen Richtlinien für macOS enthalten und enthält eine Angabe, welche LocalPolicy-Datei für recoveryOS mit welcher LocalPolicy-Datei für macOS korrespondiert.
Has Secure Enclave Signed recoveryOS Local Policy (hrlp)
Typ: Boolescher Wert
Veränderbare Umgebungen: 1TR, recoveryOS, macOS
Beschreibung:
hrlp
gibt an, ob der oben beschriebeneprot
-Wert eine Kennzahl für die LocalPolicy-Datei für eine durch die Secure Enclave signierte recoveryOS-Software ist oder nicht. Ist dies nicht der Fall, wird die LocalPolicy-Datei von recoveryOS vom Apple Online-Signierungsserver signiert, der Objekte wie macOS Image4-Dateien signiert.
Local Operating System Version (love)
Typ: Boolescher Wert
Veränderbare Umgebungen: 1TR, recoveryOS, macOS
Beschreibung:
love
zeigt die Version des Betriebssystems an, für das die lokale Richtlinie (LocalPolicy) erstellt wurde. Die Version wird von dem nächsten Statusmanifest während der Erstellung der LocalPolicy abgerufen und verwendet, um die Kopplungseinschränkungen für das recoveryOS umzusetzen.
Secure Multi-Boot (smb0)
Typ: Boolescher Wert
Veränderbare Umgebungen: 1TR, recoveryOS
Beschreibung: Wenn
smb0
vorhanden ist und den Wert „True“ enthält, lässt LLB es zu, dass das nsih-Manifest (Next stage Image4) global signiert wird und keine personalisierte Signatur erforderlich ist. Dieses Feld kann vom Benutzer mit dem Startsicherheitsdienstprogramm oder mitbputil
geändert werden, um die Herabstufung auf „Reduzierte Sicherheit“ vorzunehmen.
Secure Multi-Boot (smb1)
Typ: Boolescher Wert
Veränderbare Umgebungen: 1TR
Beschreibung: Wenn
smb1
vorhanden ist und den Wert „True“ enthält, lässt iBoot es zu, dass Objekte wie beispielsweise eine angepasste Kernel-Sammlung in der Secure Enclave mit demselben Schlüssel wie die LocalPolicy-Datei signiert wird. Das Feldsmb1
kann nur vorhanden sein, wenn das Feldsmb0
vorhanden ist. Dieses Feld kann vom Benutzer mit dem Befehlszeilenprogrammcsrutil
oderbputil
geändert werden, um die Herabstufung auf „Permissive Sicherheit“ vorzunehmen.
Secure Multi-Boot (smb2)
Typ: Boolescher Wert
Veränderbare Umgebungen: 1TR
Beschreibung: Wenn
smb2
vorhanden ist und den Wert „True“ enthält, lässt iBoot es zu, dass die Auxiliary Kernel Collection in der Secure Enclave mit demselben Schlüssel wie die LocalPolicy-Datei signiert wird. Das Feldsmb2
kann nur vorhanden sein, wenn das Feldsmb0
vorhanden ist. Dieses Feld kann vom Benutzer mit dem Startsicherheitsdienstprogramm oderbputil
geändert werden, um die Herabstufung auf „Reduzierte Sicherheit“ vorzunehmen und Kernel-Erweiterungen von Drittanbietern zu aktivieren.
Secure Multi-Boot (smb3)
Typ: Boolescher Wert
Veränderbare Umgebungen: 1TR
Beschreibung: Wenn
smb3
vorhanden ist und den Wert „True“ enthält, bedeutet dies, dass sich ein Benutzer auf dem System für die Registrierung in einer MDM-Lösung (Mobile Device Management) entschieden hat. Das Vorhandensein dieses Felds bewirkt, dass die Prozessoranwendung der Secure Enclave, die die LocalPolicy-Datei steuert, die Authentifizierung über die MDM-Lösung anstelle der lokalen Benutzerauthentifizierung akzeptiert. Dieses Feld kann vom Benutzer mit dem Startsicherheitsdienstprogramm oder mitbputil
geändert werden, um die verwaltete Steuerung für Kernel-Erweiterungen von Drittanbietern und von Softwareaktualisierungen zu aktivieren. (In macOS 11.2 (oder neuer) kann die MDM-Lösung auch eine Aktualisierung auf die neueste macOS-Version veranlassen, wenn als Sicherheitsmodus „Volle Sicherheit“ ausgewählt ist.)
Secure Multi-Boot (smb4)
Typ: Boolescher Wert
Veränderbare Umgebungen: macOS
Beschreibung: Wenn
smb4
vorhanden ist und den Wert „True“ enthält, bedeutet dies, dass das Gerät über Apple School Manager, Apple Business Manager oder Apple Business Essentials in einer MDM-Lösung registriert wurde und von ihr gesteuert wird. Das Vorhandensein dieses Felds bewirkt, dass die Anwendung der Secure Enclave, die die LocalPolicy-Datei steuert, die Authentifizierung über die MDM-Lösung anstelle der lokalen Benutzerauthentifizierung akzeptiert. Dieses Feld wird durch die MDM-Lösung geändert, wenn sie erkennt, dass die Seriennummer des Geräts in einem dieser drei Dienste erscheint.
System Integrity Protection (sip0)
Typ: Unsignierte 64-Bit-Ganzzahl
Veränderbare Umgebungen: 1TR
Beschreibung:
sip0
umfasst die Bits der SIP-Richtlinie (System Integrity Protection, Systemintegritätsschutz), die bisher im NVRAM gespeichert wurden. Neue SIP-Richtlinienbits werden hier hinzugefügt (und nicht in die nachfolgend beschriebenen Felder der lokalen Richtlinie), wenn sie ausschließlich von macOS und nicht auch von LLB verwendet werden. Dieses Feld kann von einem Benutzer mitcsrutil
aus 1TR geändert werden, um SIP zu deaktivieren und die Herabstufung auf „Permissive Sicherheit“ vorzunehmen.
System Integrity Protection (sip1)
Typ: Boolescher Wert
Veränderbare Umgebungen: 1TR
Beschreibung: Wenn
sip1
vorhanden ist und den Wert „True“ enthält, lässt iBoot Fehler beim Prüfen des Hash-Werts des SSV zu. Dieses Feld kann von einem Benutzer mitcsrutil
oderbputil
aus 1TR geändert werden.
System Integrity Protection (sip2)
Typ: Boolescher Wert
Veränderbare Umgebungen: 1TR
Beschreibung: Wenn sip2 vorhanden ist und den Wert „True“ enthält, sperrt iBoot nicht das Hardwareregister CTRR (Configurable Text Read-only Region), das Kernelspeicher als nicht beschreibbar markiert. Dieses Feld kann von einem Benutzer mit
csrutil
oderbputil
aus 1TR geändert werden.
System Integrity Protection (sip3)
Typ: Boolescher Wert
Veränderbare Umgebungen: 1TR
Beschreibung: Wenn
sip3
vorhanden ist und den Wert „True“ enthält, erzwingt iBoot nicht die Verwendung der eigenen integrierten Positivliste für die NVRAM-Variable boot-args, die ansonsten die Optionen filtern würde, die an den Kernel übergeben werden. Dieses Feld kann von einem Benutzer mitcsrutil
oderbputil
aus 1TR geändert werden.
Zertifikate und Remote-Richtlinien (RemotePolicy)
Wie unter Erstellung und Verwaltung von Signaturschlüsseln für die lokale Richtlinie (LocalPolicy) beschrieben ist, enthält die Image4-Datei der lokalen Richtlinie auch das OIC (Owner Identity Certificate) und die eingebettete Remote-Richtlinie (RemotePolicy).