macOS: System Integrity Protection
Seit 10.11 El Capitan hat macOS einen zusätzlichen Mechanismus, um das System vor versehentlichen Änderungen oder Manipulation durch Malware zu schützen: System Integrity Protection (SIP). Bemerken werden das allerdings nur Programme, die nicht aus dem App Store kommen, denn die Sandbox für App Store Apps ist noch strenger. SIP dient also in erster Linie dazu, Dritt-Softwware, die nicht aus dem App Store kommt, generell von Pfuscherei am System abzuhalten.
Wie die Sandbox für jede App Store App und wie jede andere Sandbox auf macOS erzwingt SIP Regeln für Code unabhängig vom User unter dem der Code läuft. Unix bietet zwar mit seiner User-Trennung und den POSIX-Zugriffsrechten schon viel Schutz vor Amok laufendem Code, aber die zusätzlichen Sandboxes, die eine Form von Mandatory Access Control (MAC) sind, legen nochmal auf eine andere Weise feingranular fest, was ein Prozeß (laufendes Programm) tun darf, egal welcher User es ausführt. Es ist sozusagen eine zweite Rechte-Dimension.
SIP ist ein zusätzlicher Schutz für macOS, der die üblichen UNIX-Schutzmechanismen in macOS völlig unabhängig ergänzt als weiteres Hindernis, das einem Angreifer System-Manipulationen verwehren soll.
SIP ist ziemlich umfangreich und besteht aus vier Bereichen:
Dateisystem-Schutz
System-Dateien bekommen ein spezielles Flag, wenn sie installiert werden. Diese Dateien und Verzeichnisse können dann nur noch von System-Prozessen, die Apples Signatur tragen und spezielle Entitlements haben, verändert werden.
Geschützte Bereiche sind /bin, /sbin, /usr, /System und Apple Apps in /Applications. Für Dritt-Entwickler stehen /usr/local, /Applications, /Library und ~/Library zur Verfügung.
Das spezielle Flag ist ein Extended Attribute, das com.apple.rootless heißt. Man sieht es
zum Beispiel im Terminal mit xattr -l /System.
Eine Liste geschützter Objecte ist anscheinend in /System/Library/Sandbox/rootless.conf
verfügbar. Die linke Seite der Liste gibt die User oder Gruppen an, die den jeweils rechts
angegebenen Ort ändern dürfen, wobei * (Stern) für jeden User steht.
Laufzeit-Schutz
Programme können jedoch nicht nur vor ihrem Start auf der Platte manipuliert werden, sondern auch zur Laufzeit. Darum bietet SIP nicht nur den oben beschriebenen Dateisystem-Schutz, sondern auch noch einen Laufzeit-Schutz.
Der Kernel prüft beim Start eines Prozesses, ob das Main Executable auf der Platte geschützt ist oder ob es mit einem speziellen System-Entitlement signiert ist. Ist eines von beidem der Fall, dann bekommt der Prozeß ein Flag, das ihn als geschützt gegen Änderungen markiert. Jeder Versuch, sich in so einen geschützten Prozeß einzuklinken wird vom Kernel verhindert.
Versuche, mit mach_override und mach_inject an diesem Prozeß zu arbeiten, sind zum Beispiel blockiert. Außerdem werden alle dlyd-Variablen (Umgebungs-Variablen des dynamischen Linkers) für geschützte Prozesse leer gemacht. Über diese Umgebungs-Variablen versuchte damals beispielsweise Flashback, andere Programme zu manipulieren.
Wenn ein Kind-Prozeß von einem geschützten SIP-Prozeß erstellt wird über NSTask oder exec, dann werden die Mach Special Ports des Kind-Prozesses zurückgesetzt, über die ansonsten der SIP-Prozeß vom Kind aus manipuliert werden könnte. Wie beim Dynamic Overriding oben besteht die Technik auch hier darin, über einen Mach-Port mit Senderechten den zu dem Mach-Port gehörenden Prozeß auf unterster Kernel-Ebene zu manipulieren.
DTrace kann nicht benutzt werden, um SIP-Prozesse zu analysieren, weder über die Entwickler-App Instruments noch über das Shell-Kommando dtrace. Mit einem Debugger wie LLDB sich an einen geschützten Prozeß zu hängen funktioniert auch nicht, noch nicht einmal unter root. Ein Debugger könnte das laufende Programm nicht nur inspizieren, sondern auch verändern.
Exklusive Kernel-Extensions
Kernel-Extensions benötigen unter SIP eine spezielle Berechtigung, um laufen zu können. Selbst der Entwickler-Modus für Kexts wurde abgeschafft. Eine Kext läuft nur noch, wenn sie mit einem Developer ID Zertifikat signiert ist, das von Apple für Kernel-Extensions berechtigt wurde. Standardmäßig hat ein Entwickler diese Berechtigung nicht. Man muß sie beantragen. Außerdem muß die Kext in /Library/Extensions liegen, um als 3rd-Party Kext zu funktionieren.
Für die Entwicklung soll man SIP auf seinen Test-Systemen deaktivieren und die Kext erst kurz vor ihrer Veröffentlichung signieren.
Sichere Konfiguration
Die SIP-Konfiguration ist nicht im System selbst gespeichert, sondern im NVRAM. Sie gilt damit für jede macOS-Installation auf dem Rechner, die SIP unterstützt, und überlebt System-Neu-Installationen. Damit SIP besser geschützt ist gegen Manipulation von einem anderen System aus, kann die Start-Disk nicht mehr programmatisch gesetzt werden, zum Beispiel mit dem bless Kommando.
Um SIP zu konfigurieren bzw. zu deaktivieren, muß man mit Command-R von der Recovery-Partition starten und
im Terminal csrutil benutzen bzw. csrutil disable eingeben. Nach dem Ein- bzw. Ausschalten
von SIP muß der Rechner neu gestartet werden.
usage: csrutil <command>
Modify the System Integrity Protection configuration. All configuration changes apply to the entire machine.
Available commands:
clear
Clear the existing configuration. Only available in Recovery OS.
disable
Disable the protection on the machine. Only available in Recovery OS.
enable
Enable the protection on the machine. Only available in Recovery OS.
status
Display the current configuration.
netboot
add <address>
Insert a new IPv4 address in the list of allowed NetBoot sources.
list
Print the list of allowed NetBoot sources.
remove <address>
Remove an IPv4 address from the list of allowed NetBoot sources.Außerdem soll SIP andere Software daran hindern, eine andere Startplatte festzulegen. Das soll nur über die Systemeinstellungen oder die Starttasten möglich sein.
Quellen
- Apple Mac Developer Library: System Integrity Protection Guide
- Apple: About System Integrity Protection on your Mac
- OS X 10.11 El Capitan: The Ars Technica Review