Was ist das "rootless" -Feature in El Capitan wirklich?

Ich habe gerade von der "Rootless" -Funktion in El Capitan erfahren und höre Dinge wie "Es gibt keinen Root-Benutzer", "Nichts kann geändert werden /System" und "Die Welt wird untergehen, weil wir nicht root werden können".

Was ist das "Rootless" -Feature von El Capitan auf technischer Ebene? Was bedeutet das für die Benutzererfahrung und die Entwicklererfahrung? Funktioniert das sudo -simmer noch und wenn ja, wie wird sich die Erfahrung mit einer Shell rootändern?

Erstens: Der Name "rootless" ist irreführend, da es immer noch ein Root-Konto gibt und Sie immer noch darauf zugreifen können (der offizielle Name "System Integrity Protection" ist genauer). Was es wirklich tut, ist die Leistung des Root-Kontos zu begrenzen, sodass Sie selbst dann nicht die volle Kontrolle über das System haben, wenn Sie Root werden. Grundsätzlich ist die Idee, dass Malware zu leicht auf den Root-Zugriff zugreifen kann (z. B. indem dem Benutzer ein Authentifizierungsdialog angezeigt wird, in dem der Benutzer das Administratorkennwort reflexartig eingibt). SIP fügt eine weitere Schutzschicht hinzu, in die Malware nicht eindringen kann, selbst wenn sie root wird. Das Schlimme dabei ist natürlich, dass es auch für Dinge gilt, die Sie absichtlich tun. Aber die Einschränkungen, die es Root auferlegt, sind nicht so schlimm. sie verhindern nicht die meisten "normalen"

Hier ist, was es einschränkt, auch von root:

• Sie können nicht alles in modifizieren /System, /bin, /sbin, oder /usr(ausgenommen /usr/local); oder eine der integrierten Apps und Dienstprogramme. Nur das Installationsprogramm und das Software-Update können diese Bereiche ändern, und dies auch nur, wenn von Apple signierte Pakete installiert werden. Da jedoch normale Anpassungen im OS X-Stil /Library(oder ~/Libraryoder /Applications) und Anpassungen im Unix-Stil (z. B. Homebrew) /usr/local(oder manchmal /etcoder /opt) vorgenommen werden, sollte dies keine große Sache sein. Außerdem werden Schreibvorgänge auf Blockebene auf die Startdiskette verhindert, sodass Sie sie nicht auf diese Weise umgehen können.

  Die vollständige Liste der eingeschränkten Verzeichnisse (und Ausnahmen wie /usr/localund einige andere) befindet sich in /System/Library/Sandbox/rootless.conf. Natürlich befindet sich diese Datei selbst in einem eingeschränkten Bereich.

  Beim Upgrade auf El Capitan werden alle "nicht autorisierten" Dateien aus eingeschränkten Bereichen nach verschoben /Library/SystemMigration/History/Migration-(some UUID)/QuarantineRoot/.

• Sie können keine Systemprozesse (z. B. solche, die von diesen Systemstandorten aus ausgeführt werden) zum Debuggen (oder Ändern der von ihnen geladenen dynamischen Bibliotheken oder einiger anderer Dinge) anhängen. Wieder nicht zu viel von einer großen Sache; Entwickler können weiterhin ihre eigenen Programme debuggen.

  Dies blockiert einige wichtige Dinge wie das Einfügen von Code in die integrierten Apple-Apps (insbesondere den Finder). dtraceDies bedeutet auch, dass auf -basierende Tools für die Systemüberwachung (z. B. opensnoop) nicht in der Lage sind, viele Systemprozesse zu überwachen und darüber zu berichten.

• Sie können Kernel-Erweiterungen (kexts) nur laden, wenn sie ordnungsgemäß signiert sind (z. B. von Apple oder einem von Apple genehmigten Entwickler). Beachten Sie, dass dies das alte System zur Erzwingung der Textsignatur (und die alten Methoden zu deren Umgehung) ersetzt. Seit Version 10.10.4 von Apple die Unterstützung von Trimms für SSDs von Drittanbietern aktiviert wurde , ist der Hauptgrund für die Verwendung nicht signierter Kexts weggefallen.

• Ab Sierra (10.12) können einige Startkonfigurationseinstellungen nicht geändert werden (z. B. können einige Startdämonen nicht entladen werden).

• Ab Mojave (10.14) ist der Zugriff auf die persönlichen Informationen der Benutzer (E-Mail, Kontakte usw.) auf Apps beschränkt, für die der Benutzer den Zugriff auf diese Informationen genehmigt hat. Dies wird im Allgemeinen als separate Funktion (als TCC (Personal Information Protection) bezeichnet) betrachtet, basiert jedoch auf SIP und wird durch Deaktivieren von SIP ebenfalls deaktiviert. Siehe: "Was und wie implementiert macOS Mojave, um den Zugriff von Anwendungen auf personenbezogene Daten einzuschränken?"

Wenn Sie diese Einschränkungen nicht möchten - entweder, weil Sie Ihr System über das zulässige Maß hinaus modifizieren möchten oder weil Sie Kexts entwickeln und debuggen, die unter diesen Einschränkungen nicht praktikabel sind, können Sie SIP deaktivieren. Derzeit muss der Computer im Wiederherstellungsmodus neu gestartet und der Befehl ausgeführt werden csrutil disable(und Sie können ihn auch mit erneut aktivieren csrutil enable).

Sie können auch Teile von SIP selektiv deaktivieren . csrutil enable --without kextDeaktiviert beispielsweise die Kernelerweiterungsbeschränkung von SIP, belässt jedoch die anderen Schutzfunktionen.

Aber hören Sie bitte auf und überlegen Sie, bevor Sie SIP auch nur vorübergehend oder teilweise deaktivieren: Müssen Sie es wirklich deaktivieren, oder gibt es eine bessere (SIP-konforme) Möglichkeit, das zu tun, was Sie möchten? Benötigen Sie wirklich etwas zu ändern /System/Libraryoder /binoder was auch immer, oder es könnte in einem besseren Ort wie gehen /Libraryoder /usr/local/binetc? SIP kann sich einschränkend anfühlen, wenn Sie nicht daran gewöhnt sind, und es gibt einige legitime Gründe, es zu deaktivieren, aber vieles, was es erzwingt, ist wirklich nur eine bewährte Vorgehensweise.

Berücksichtigen Sie die Ereignisse vom 23. September 2019, um zu unterstreichen, wie wichtig es ist, möglichst viel SIP-fähig zu lassen. Google hat ein Update für Chrome veröffentlicht, das versucht, den symbolischen Link von /varnach zu ersetzen /private/var. Auf den meisten Systemen hat SIP dies blockiert und es gab keine negativen Auswirkungen. Auf Systemen mit deaktiviertem SIP wurde macOS beschädigt und konnte nicht mehr gestartet werden. Der häufigste Grund für die Deaktivierung von SIP war das Laden von nicht genehmigten (/ nicht ordnungsgemäß signierten) Kernel-Erweiterungen (insbesondere Videotreibern). Wenn sie nur die Textbeschränkung deaktiviert hätten, wären sie nicht betroffen. Weitere Informationen finden Sie im offiziellen Support-Thread von Google , in den Fragen und Antworten für Superuser sowie in einem Artikel von Ars Technica .

Referenzen und weitere Informationen: WWDC-Präsentation zu "Sicherheit und Ihre Apps" , eine gute Erklärung von Eldad Eilam auf quora.com , die Ars Technica-Rezension von El Capitan und ein Apple-Supportartikel zu SIP sowie ein ausführlicher Tauchgang von Rich Trouton ( die auch eine Antwort auf diese Frage gepostet haben ).

Für mich bedeutet das, dass DTrace nicht mehr funktioniert.

DTrace ähnelt ptrace / strace in Linux, da Sie sehen können, was ein Prozess dem Kernel sagt. Jedes Mal, wenn ein Prozess eine Datei öffnen, eine Datei schreiben oder einen Port öffnen möchte, muss er den Kernel fragen. Unter Linux findet dieser Überwachungsprozess außerhalb des Kernels im "Userland" statt, und die Berechtigungen sind daher sehr feinkörnig. Ein Benutzer kann seine eigenen Anwendungen überwachen (um Fehler zu beheben, Speicherlecks zu finden usw.), muss jedoch root sein, um den Prozess eines anderen Benutzers zu überwachen.

DTrace unter OSX funktioniert jedoch auf Kernel-Ebene, wodurch es viel performanter und leistungsfähiger wird. Es ist jedoch Root-Zugriff erforderlich, um seine Probes in den Kernel einzufügen und damit alles zu tun. Ein Benutzer kann seine eigenen Prozesse nicht verfolgen, ohne als Root angemeldet zu sein, sondern kann als Root nicht nur seine eigenen Prozesse, sondern tatsächlich ALLE Prozesse auf dem System gleichzeitig überwachen. Zum Beispiel können Sie eine Datei (mit iosnoop) beobachten und sehen, welcher Prozess sie liest. Dies ist eine der nützlichsten Funktionen zur Erkennung von Malware. Da sich der Kernel auch mit Netzwerk-E / A befasst, gilt dies auch dort. Wireshark erkennt ungewöhnliche Netzwerkaktivitäten. DTrace teilt Ihnen mit, dass der Prozess die Daten sendet, auch wenn diese genauso in das System eingebettet sind wie der Kernel.

In Bezug auf El Capitan hat Apple DTrace jedoch absichtlich daran gehindert, zu funktionieren. Dies wurde ausdrücklich als Einschränkung für SIP herausgestellt. Warum sollten sie das tun? Zuvor hatte Apple den Kernel und DTrace dahingehend modifiziert, dass einige Prozesse nicht mehr über DTrace überwacht werden konnten (was viele Sicherheitsforscher zu der Zeit verärgerte, als einige Prozesse sogar als Root verboten waren - einschließlich Malware). Der Grund dafür war, DRM in Apps wie iTunes zu schützen, da theoretisch jemand nicht DRM-fähige Daten aus dem Speicher der Prozesse entnehmen und abrufen konnte.

Es gab jedoch eine wichtige Abhilfemaßnahme, die es den Forschern ermöglichte, ihre Arbeit fortzusetzen, und die darin bestand, den Kernel so zu modifizieren, dass dieses Opt-Out-Flag ignoriert wurde, sodass DTrace weiterhin für diese Prozesse verwendet werden konnte. Das war wirklich großartig, da Programme, die versuchen, der Erkennung zu entgehen, jetzt mit diesem No-DTrace-Flag aufleuchten. Alles, was Apple oder die Bösen verstecken wollten, war jetzt in Sichtweite ...

Aber es funktioniert jetzt nicht. Wie wirkt sich das auf Sie aus? Nun, es wird Sie sowohl direkt als auch indirekt betreffen. Direkt wird es Ihre Fähigkeit einschränken, Ihr System zu überwachen. Eine große Anzahl von Systemverwaltungs- und Überwachungstools auf niedriger Ebene (auf denen Tools auf höherer Ebene aufbauen) funktionieren nicht mehr. Der indirekte Effekt wird jedoch viel größer sein - Sicherheitsexperten verlassen sich auf einen umfassenden Systemzugriff, um die schlimmsten Arten von Bedrohungen zu erkennen. Das können wir einfach nicht mehr. Bei der Analyse von Malware ist es wichtig, dass sie nicht weiß, dass sie in einem Debugger oder Honeypot ausgeführt wird. Durch Deaktivieren von SIP wird der gesamten Software, sowohl von den Bösewichten als auch von Apple, mitgeteilt, dass dieses System überwacht wird. Nicht mehr die Beobachter beobachten. Wenn es bei SIP um Sicherheit ging, hätten sie die Benutzer über root aufklären können - stattdessen haben sie es entfernt. Letztendlich bedeutet dies, dass Apple die Sicherheitsbarriere des Root-Passworts "Alles und Alles" durch den SIP-Schutzmechanismus "Alles und Alles" ersetzt hat. Oder wenn Sie sich mit Social Engineering auskennen, ein Root-Passwort mit einem Neustart ...

Es gibt auch Folgendes:

System Integrity Protection (SIP) ist eine umfassende Sicherheitsrichtlinie, mit der verhindert werden soll, dass Systemdateien und -prozesse von Dritten geändert werden. Um dies zu erreichen, hat es die folgenden Konzepte:

• Dateisystemschutz
• Kernel-Erweiterungsschutz
• Laufzeitschutz

Dateisystemschutz

SIP verhindert, dass andere Parteien als Apple Verzeichnisse und Dateien, die in bestimmten Verzeichnissen gespeichert sind, hinzufügen, löschen oder ändern können:

/bin
/sbin
/usr
/System

Apple hat angegeben, dass die folgenden Verzeichnisse für Entwickler verfügbar sind:

/usr/local
/Applications
/Library
~/Library

Alle Verzeichnisse mit /usrAusnahme von /usr/localsind durch SIP geschützt.

Es ist möglich, SIP-geschützte Dateien und Verzeichnisse über ein Installationspaket hinzuzufügen, zu entfernen oder zu ändern, das von Apples eigener Zertifizierungsstelle signiert ist. Auf diese Weise kann Apple Änderungen an SIP-geschützten Teilen des Betriebssystems vornehmen, ohne die vorhandenen SIP-Schutzfunktionen ändern zu müssen.

Die betreffende Zertifizierungsstelle wird von Apple für den eigenen Gebrauch reserviert. Von der Entwickler-ID signierte Installationspakete können keine SIP-geschützten Dateien oder Verzeichnisse ändern.

Um festzulegen, welche Verzeichnisse geschützt sind, hat Apple derzeit zwei Konfigurationsdateien im Dateisystem definiert. Die primäre befindet sich an der folgenden Stelle:

/System/Library/Sandbox/rootless.conf

Dabei werden rootless.confalle Anwendungen und die oberste Ebene der Verzeichnisse aufgelistet, die von SIP geschützt werden.

Anwendungen

SIP schützt die Kern-Apps, die OS X in Applications und Applications Utilities installiert. Dies bedeutet, dass die von OS X installierten Anwendungen nicht mehr gelöscht werden können, auch nicht über die Befehlszeile, wenn Root-Berechtigungen verwendet werden.

Verzeichnisse

SIP schützt auch eine Reihe von Verzeichnissen und Symlinks außerhalb von /Applicationsund die oberste Ebene dieser Verzeichnisse ist ebenfalls in aufgeführt rootless.conf.

Zusätzlich zu den Schutzmaßnahmen hat Apple in der Datei rootless.conf einige Ausnahmen für den SIP-Schutz definiert. Diese Ausnahmen sind mit Sternchen gekennzeichnet. Diese Ausnahmen vom SIP-Schutz bedeuten, dass es möglich ist, Dateien und Verzeichnisse an diesen Standorten hinzuzufügen, zu entfernen oder zu ändern.

Zu diesen Ausnahmen gehören:

• /System/Library/User Template - wo OS X die Vorlagenverzeichnisse speichert, die es beim Erstellen von Basisordnern für neue Konten verwendet.
• /usr/libexec/cups - wo OS X Druckerkonfigurationsinformationen speichert

Apple betrachtet diese Datei als ihre und die Änderungen, die Dritte daran vornehmen, werden von Apple überschrieben.

Um zu sehen, welche Dateien durch SIP geschützt wurden, verwenden Sie den lsBefehl mit dem Bindestrich O in Terminal:

ls -O

SIP-geschützte Dateien werden als eingeschränkt gekennzeichnet .

Es ist wichtig zu wissen, dass selbst wenn ein Symlink durch SIP geschützt ist, dies nicht zwangsläufig bedeutet, dass das Verzeichnis, zu dem sie verlinken, durch SIP geschützt ist. Auf der Stammebene eines OS X El Capitan-Startlaufwerks befinden sich mehrere SIP-geschützte Symlinks, die auf Verzeichnisse verweisen, die im genannten Stammverzeichnis gespeichert sind private.

Wenn jedoch der Inhalt des privateVerzeichnisses untersucht wird, werden die Verzeichnisse, auf die diese Symlinks verweisen, nicht durch SIP geschützt, und sowohl sie als auch ihr Inhalt können von Prozessen unter Verwendung von Root-Rechten verschoben, bearbeitet oder geändert werden.

Neben der Liste der von Apple festgelegten SIP-Ausnahmen rootless.confgibt es eine zweite Liste der SIP-Ausnahmen. Diese Liste enthält eine Reihe von Verzeichnissen und Anwendungsnamen für Produkte von Drittanbietern. Ähnlich wie bei rootless.confdieser Ausschlussliste werden Änderungen von Apple und Drittanbietern von Apple überschrieben.

/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths

Laufzeitschutz

Der Schutz von SIP beschränkt sich nicht nur auf den Schutz des Systems vor Dateisystemänderungen. Es gibt auch Systemaufrufe, deren Funktionalität jetzt eingeschränkt ist.

• task_for_pid () / processor_set_tasks () schlagen mit EPERM fehl
• Mach spezielle Ports auf exec (2) zurückgesetzt
• dyld-Umgebungsvariablen werden ignoriert
• DTrace-Sonden nicht verfügbar

SIP blockiert jedoch nicht die Überprüfung der eigenen Anwendungen durch den Entwickler, während diese entwickelt werden. Mit den Tools von Xcode können Apps weiterhin während des Entwicklungsprozesses überprüft und debuggt werden.

Weitere Informationen hierzu finden Sie in der Entwicklerdokumentation von Apple für SIP .

Kernel-Erweiterungsschutz

SIP blockiert die Installation von nicht signierten Kernel-Erweiterungen. Um eine Kernel-Erweiterung unter OS X El Capitan mit aktiviertem SIP zu installieren, muss eine Kernel-Erweiterung:

1. Sie müssen mit einer Entwickler-ID für das Signing Kexts- Zertifikat signiert sein
2. Installieren Sie in / Library / Extensions

Wenn Sie eine nicht signierte Kernel-Erweiterung installieren, muss SIP zuerst deaktiviert werden.

Weitere Informationen zum Verwalten von SIP finden Sie unter folgendem Link:

Systemintegritätsschutz - Hinzufügen einer weiteren Ebene zum Apple-Sicherheitsmodell