Was ist eigentlich die „Rootless“-Funktion in El Capitan?

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 Macht des Root-Kontos einzuschränken, so dass Sie, selbst wenn Sie Root werden, nicht die volle Kontrolle über das System haben. Im Wesentlichen ist die Idee, dass es für Malware zu einfach ist, Root-Zugriff zu erhalten (z. B. indem dem Benutzer ein Authentifizierungsdialog angezeigt wird, der den Benutzer veranlasst, reflexartig das Administratorpasswort einzugeben). SIP fügt eine weitere Schutzebene hinzu, die Malware nicht durchdringen kann, selbst wenn sie root wird. Das Schlimme daran ist natürlich, dass es auch für Dinge gelten muss, 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, sogar von root:

• Sie können nichts in /System, /bin, /sbinoder /usr(außer /usr/local) ändern; oder eine der integrierten Apps und Dienstprogramme. Nur Installer und Software-Update können diese Bereiche ändern, und selbst sie tun dies nur, wenn sie von Apple signierte Pakete installieren. Aber da normale Anpassungen im Stil von OS X hineingehen /Library(oder ~/Library, oder /Applications) und Anpassungen im Unix-Stil (zB Homebrew) hineingehen /usr/local(oder manchmal /etcoder /opt), sollte das keine große Sache sein. Es verhindert auch Schreibvorgänge auf Blockebene auf das Startvolume, sodass Sie es auf diese Weise nicht 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 geschützten Bereich.

  Wenn Sie auf El Capitan upgraden, verschiebt es alle "nicht autorisierten" Dateien aus eingeschränkten Bereichen in /Library/SystemMigration/History/Migration-(some UUID)/QuarantineRoot/.

• Sie können sich nicht an Systemprozesse (z. B. solche, die von diesen Systemspeicherorten ausgeführt werden) für Dinge wie das Debuggen (oder das Ändern, welche dynamischen Bibliotheken sie laden, oder einige andere Dinge) anhängen. Auch hier keine allzu große 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). Dies bedeutet auch, dass dtrace-basierte Tools zur Systemüberwachung (z. B. opensnoop) viele Systemprozesse nicht überwachen und melden können.

• Sie können keine Kernel-Erweiterungen (Kexts) laden, es sei denn, sie sind ordnungsgemäß signiert (dh von Apple oder einem von Apple zugelassenen Entwickler). Beachten Sie, dass dies das alte System zum Erzwingen von Kext-Signaturen ersetzt (und die alten Methoden, es zu umgehen). Aber seit v10.10.4 hat Apple eine Möglichkeit, die Trim-Unterstützung für SSDs von Drittanbietern zu aktivieren , der Hauptgrund für die Verwendung unsignierter Kexts ist verschwunden.

• Ab Sierra (10.12) können einige Launchd-Konfigurationseinstellungen nicht geändert werden (z. B. können einige Launch-Daemons 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, denen der Benutzer den Zugriff auf diese Informationen genehmigt hat. Dies wird im Allgemeinen als separate Funktion betrachtet (Personal Information Protection oder TCC genannt), 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?“

• Ab Catalina (10.15) wird der Schutz der meisten Systemdateien verstärkt, indem sie auf einem separaten schreibgeschützten Volume gespeichert werden. Dies ist nicht unbedingt Teil von SIP und wird durch Deaktivieren von SIP nicht deaktiviert. Siehe: WWDC-Präsentation zu „What’s New in Apple [Catalina] File Systems“ und „What’s /System/Volumes/Data?“ .

• Ab Big Sur (11.x) ist das schreibgeschützte Systemvolume jetzt ein „versiegeltes Systemvolume“ (ein gemounteter Snapshot anstelle eines normalen Volumes), sodass Änderungen daran noch komplizierter sind. Siehe: den Artikel „Big Sur Boot Volume Layout“ der Eclectic Light Company .

Wenn Sie diese Einschränkungen nicht möchten – entweder weil Sie Ihr System über das hinaus modifizieren möchten, was dies zulässt, oder weil Sie so etwas wie Kexts entwickeln und debuggen, die unter diesen Einschränkungen nicht praktikabel sind, können Sie SIP deaktivieren. Derzeit erfordert dies einen Neustart im Wiederherstellungsmodus und das Ausführen des Befehls csrutil disable(und Sie können ihn auf ähnliche Weise mit erneut aktivieren csrutil enable).

Das Ändern des Systemvolumes in Catalina erfordert das Deaktivieren von SIP, das anschließende Mounten des Volumes mit Schreibzugriff (und dann ein Neustart und das Wiedereinschalten von SIP wird empfohlen). In Big Sur sind zusätzliche Schritte erforderlich, um die Authentifizierung des Systemvolumes vor Änderungen zu deaktivieren und anschließend einen neuen Snapshot zu erstellen .

Sie können auch Teile von SIP selektiv deaktivieren . Deaktiviert beispielsweise csrutil enable --without kextdie Kernel-Erweiterungsbeschränkung von SIP, lässt aber die anderen Schutzmaßnahmen bestehen.

Aber bitte halten Sie inne und denken Sie nach, bevor Sie SIP deaktivieren, auch nur vorübergehend oder teilweise: Müssen Sie es wirklich deaktivieren, oder gibt es einen besseren (SIP-konformen) Weg, um das zu tun, was Sie wollen? Müssen Sie wirklich etwas in /System/Libraryoder /binoder was auch immer ändern, oder könnte es an einem besseren Ort wie /Libraryoder /usr/local/binusw. stehen? SIP kann sich einschränkend anfühlen, wenn Sie nicht daran gewöhnt sind, und es gibt einige berechtigte Gründe, es zu deaktivieren, aber vieles, was es erzwingt, ist sowieso nur eine bewährte Vorgehensweise.

Um zu unterstreichen, wie wichtig es ist, so viel SIP wie möglich so oft wie möglich aktiviert zu lassen, betrachten Sie die Ereignisse vom 23. September 2019. Google hat ein Update für Chrome veröffentlicht, mit dem versucht wurde, den symbolischen Link von /varzu zu ersetzen /private/var. Auf den meisten Systemen blockierte SIP dies und es gab keine negativen Auswirkungen. Auf Systemen mit deaktiviertem SIP wurde macOS beschädigt und nicht mehr bootfähig gemacht. Der häufigste Grund für das Deaktivieren von SIP war das Laden nicht genehmigter (/falsch signierter) Kernel-Erweiterungen (insbesondere Videotreiber); Wenn sie nur die Kext-Einschränkung deaktiviert hätten, wären sie nicht betroffen gewesen. Siehe den offiziellen Google-Support-Thread , Superuser-Fragen und Antworten dazu und einen Artikel von Ars Technica .

Referenzen und weitere Informationen: WWDC-Präsentation zu „Security and Your Apps“ , eine gute Erklärung von Eldad Eilam auf quora.com , die Ars Technica-Rezension von El Capitan und ein Apple-Support-Artikel zu SIP sowie ein Deep Dive von Rich Trouton ( der auch eine Antwort auf diese Frage gepostet hat ).

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

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

DTrace unter OSX arbeitet jedoch auf der Kernel-Ebene, wodurch es viel performanter und leistungsfähiger wird, es erfordert jedoch Root-Zugriff, um seine Sonden in den Kernel einzufügen und somit alles zu tun. Ein Benutzer kann seine eigenen Prozesse nicht verfolgen, ohne Root zu sein, aber als Root kann er nicht nur seine eigenen Prozesse beobachten, sondern tatsächlich ALLE Prozesse auf dem System gleichzeitig. Beispielsweise können Sie eine Datei (mit iosnoop) beobachten und sehen, welcher Prozess sie liest. Dies ist eine der nützlichsten Funktionen zum Erkennen von Malware. Da sich der Kernel auch mit Netzwerk-IO befasst, gilt das Gleiche dort. Wireshark erkennt ungewöhnliche Netzwerkaktivitäten, DTrace teilt Ihnen den Prozess mit, der die Daten sendet, selbst wenn er so in das System eingebettet ist wie der Kernel selbst.

Ab El Capitan hat Apple jedoch absichtlich verhindert, dass DTrace funktioniert - da es speziell als etwas ausgewählt und als SIP-Einschränkung herausgegriffen wurde. Warum sollten sie das tun? Nun, zuvor hat Apple seinen Kernel und DTrace modifiziert, um es einigen Prozessen zu ermöglichen, sich von der Überwachung durch DTrace abzumelden (was damals viele Sicherheitsforscher verärgerte, da einige Prozesse jetzt selbst als Root gesperrt waren – einschließlich Malware). Ihr Grund dafür war, DRM in Apps wie iTunes zu schützen, da theoretisch jemand DTrace durchführen und Daten ohne DRM aus dem Speicher der Prozesse holen könnte.

Es gab jedoch einen wichtigen Workaround, der es den Forschern ermöglichte, ihre Arbeit fortzusetzen, und der darin bestand, den Kernel so zu modifizieren, dass er dieses Opt-out-Flag ignoriert, sodass DTrace weiterhin auf diesen Prozessen verwendet werden konnte. Das war wirklich großartig, weil Programme, die versuchten, sich der Erkennung zu entziehen, jetzt mit diesem No-DTrace-Flag aufleuchteten. Alles, was Apple oder die bösen Jungs verbergen 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 übergeordnete Tools aufbauen) wird nicht mehr funktionieren. Der indirekte Effekt wird jedoch viel größer sein – Sicherheitsexperten verlassen sich auf tiefen Systemzugriff, um die schlimmsten Arten von Bedrohungen zu erkennen. Das können wir einfach nicht mehr. Bei der Analyse von Malware ist es entscheidend, dass sie nicht weiß, dass sie in einem Debugger oder Honeypot ausgeführt wird. Durch das 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 ginge, hätten sie die Benutzer über Root aufklären können – stattdessen haben sie es entfernt. Letztendlich bedeutet dies, dass Apple die „alles und alles“-Sicherheitsbarriere des Root-Passworts durch den „alles und alles beenden“-SIP-Schutzmechanismus ersetzt hat. Oder wenn Sie gut in Social Engineering sind, ein Root-Passwort mit einem Neustart ...

Das gibt es auch:

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

• Dateisystemschutz
• Kernel-Erweiterungsschutz
• Laufzeitschutz

Dateisystemschutz

SIP hindert andere Parteien als Apple daran, Verzeichnisse und Dateien, die in bestimmten Verzeichnissen gespeichert sind, hinzuzufügen, zu löschen oder zu ändern:

/bin
/sbin
/usr
/System

Apple hat angegeben, dass Entwickler auf die folgenden Verzeichnisse zugreifen können:

/usr/local
/Applications
/Library
~/Library

Alle Verzeichnisse in /usraußer /usr/localsind per 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. Dadurch kann Apple Änderungen an SIP-geschützten Teilen des Betriebssystems vornehmen, ohne dass die bestehenden SIP-Schutzmaßnahmen geändert werden müssen.

Die betreffende Zertifizierungsstelle ist von Apple für den eigenen Gebrauch reserviert; Mit einer Entwickler-ID signierte Installationspakete können SIP-geschützte Dateien oder Verzeichnisse nicht ändern.

Um zu definieren, welche Verzeichnisse geschützt werden, hat Apple derzeit zwei Konfigurationsdateien auf dem Dateisystem definiert. Der primäre befindet sich an der folgenden Stelle:

/System/Library/Sandbox/rootless.conf

wo rootless.confalle Anwendungen und die Verzeichnisse der obersten Ebene aufgelistet sind, die SIP schützt.

Anwendungen

SIP schützt die Kern-Apps, die OS X in Anwendungen und Anwendungsdienstprogrammen installiert. Das bedeutet, dass es nicht mehr möglich ist, die von OS X installierten Anwendungen zu löschen, auch nicht von der Befehlszeile aus, wenn Sie Root-Rechte verwenden.

Verzeichnisse

SIP schützt auch eine Reihe von Verzeichnissen und symbolischen Links außerhalb von /Applicationsund die oberste Ebene dieser Verzeichnisse ist auch in aufgelistet rootless.conf.

Zusätzlich zum Schutz hat Apple auch einige Ausnahmen zum Schutz von SIP in der Datei rootless.conf definiert, und diese Ausnahmen sind mit Sternchen gekennzeichnet. Diese Ausnahmen vom SIP-Schutz bedeuten, dass es möglich ist, Dateien und Verzeichnisse innerhalb dieser Speicherorte hinzuzufügen, zu entfernen oder zu ändern.

Zu diesen Ausnahmen gehören die folgenden:

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

Apple geht davon aus, dass diese Datei ihnen gehört und dass alle Änderungen Dritter daran von Apple überschrieben werden.

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

ls -O

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

Ein wichtiger Gedanke ist, dass selbst wenn ein Symlink durch SIP geschützt ist, dies nicht unbedingt bedeutet, dass das Verzeichnis, auf das sie verlinken, durch SIP geschützt ist. Auf der Root-Ebene eines OS X El Capitan-Startlaufwerks gibt es mehrere SIP-geschützte Symlinks, die auf Verzeichnisse verweisen, die im Root-Level-Verzeichnis mit dem Namen gespeichert sind private.

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

Neben der Liste der SIP-Ausnahmen, die Apple in eingestellt hat rootless.conf, gibt es noch eine zweite Liste mit SIP-Ausnahmen. Diese Liste enthält eine Reihe von Verzeichnissen und Anwendungsnamen für Produkte von Drittanbietern. Ähnlich wie bei rootless.conf, ist diese Ausschlussliste die von Apple, und alle Änderungen daran durch Dritte werden von Apple überschrieben.

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

Laufzeitschutz

Der Schutz von SIP ist nicht darauf beschränkt, das System vor Dateisystemänderungen zu schützen. Es gibt auch Systemaufrufe, die jetzt in ihrer Funktionalität eingeschränkt sind.

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

SIP verhindert jedoch nicht die Überprüfung der eigenen Anwendungen durch den Entwickler während der Entwicklung. Die Tools von Xcode werden es weiterhin ermöglichen, Apps während des Entwicklungsprozesses zu inspizieren und zu debuggen.

Für weitere Details hierzu empfehle ich einen Blick in Apples Entwicklerdokumentation für SIP .

Kernel-Erweiterungsschutz

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

1. Mit einer Entwickler-ID zum Signieren von Kexts- Zertifikaten signiert sein
2. Installieren Sie in /Library/Extensions

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

Weitere Informationen zur Verwaltung von SIP finden Sie unter folgendem Link:

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