Wie deaktiviere ich die System Integrity Protection (SIP) -ALKA "rootless" auf macOs [OS X]?


157

Apple hat mit OS X 10.11, El Capitan, den Systemintegritätsschutz eingeführt , der auch als "rootless" bezeichnet wird. Ich verstehe, dass dies ein Schritt zum allgemeinen Schutz vor Malware ist, aber als Entwickler benötige ich Schreibzugriff auf einige der Dateien, die gesperrt werden.

Wie deaktiviere ich diesen Schutz?


2
Obwohl Sie alle SIP-Aspekte beheben können, gibt es dafür zahlreiche Einträge. Bedenken Sie, dass Sie durch die Beeinträchtigung des Systems Dinge erstellen, die möglicherweise nicht auf dem Client-Computer ausgeführt werden, auf dem SIP aktiviert ist, und Benutzer das Deaktivieren nicht akzeptieren
Motti Shneor

5
@Motti Shneor - In einigen Fällen muss dies jedoch deaktiviert werden, um Schreibzugriff zum Installieren einiger SDKs für Entwicklungszwecke zu haben. Dies würde nicht erfordern, dass der Kunde dasselbe tut.
defaultNINJA

Ich kam aus dem Unix-Hintergrund und versuchte, die Logik von rootless zu verstehen: Da es sich bei dem Computer meistens um eine Einzelbenutzer-Maschine handelt, wird alles im Benutzer-Home-Verzeichnis installiert, sodass es nicht erforderlich ist, mit dem Systemverzeichnis zu experimentieren wie / usr / share / vim /.
Kemin Zhou

Antworten:


148

Die Dokumentation von Apple befasst sich mit dem Deaktivieren von SIP, Informationen zum Systemintegritätsschutz auf Ihrem Mac und dem Konfigurieren des Systemintegritätsschutzes .

Ein Artikel auf lifehacker.com listet diese Schritte auf:

  1. Starten Sie Ihren Mac im Wiederherstellungsmodus neu, indem Sie den Computer neu starten und Command+ gedrückt halten, Rbis das Apple-Logo auf dem Bildschirm angezeigt wird.
  2. Klicken Sie auf Dienstprogramme> Terminal.
  3. Geben Sie im Terminalfenster ein csrutil disableund drücken Sie Enter.
  4. Starten Sie Ihren Mac neu.

Sie können überprüfen, ob eine Datei oder ein Ordner eingeschränkt ist, indem Sie diesen lsBefehl mit dem Großbuchstaben O (und nicht mit Null 0) absetzen, um das Langlisten-Flag zu ändern:

ls -lO /System /usr 

Suchen Sie nach dem eingeschränkten Text, um anzugeben, wo SIP erzwungen wird.

Standardmäßig (= SIP aktiviert) sind die folgenden Ordner eingeschränkt (siehe Apple Support-Seite ):

/System
/usr
/bin
/sbin
Apps that are pre-installed with OS X

... und die folgenden Ordner sind kostenlos:

/Applications
/Library
/usr/local

1
Ich sehe vom Laufen ls -lO /usr/localkeine Einschränkung. Ich habe auch /usr/local/rekursiv chownd . Aber ich sehe immer wieder, wie Root das Eigentum an Homebrew übernimmt /usr/local/binund /usr/local/sharewelche Auswirkungen dies hat. Ist das auch die Arbeit von SIP?
SaxDaddy

1
@SaxDaddy Solange /usr/localkeine Einschränkung besteht, können Sie Berechtigungen "unterhalb" dieses Verzeichnisses problemlos korrigieren . Homebrew empfiehlt tatsächlich die Ausführung sudo chown -R $(whoami) /usr/local(während Sie als Administrator angemeldet sind), um Berechtigungsprobleme zu beheben.
Nohillside

4
@SaxDaddy Verwenden Sie Sophos Anti-Virus zufällig? Bei Sophos ist ein Problem bekannt, bei dem die Berechtigungen für diese Verzeichnisse geändert werden. Laut einem Thread in ihren Community-Foren sollte es in einem Update "bald" behoben sein.
ND Geek

1
@NDGeek: +1: Genial, danke! Du hast es richtig genannt. Und ich sehe, dass SAV 9.4.1 (veröffentlicht 18nov15) das Problem behoben hat. Ich habe diese Version installiert und bestätigt, dass /usr/localjetzt die Berechtigungen richtig eingestellt sind.
SaxDaddy

1
@andro Das Flag -O funktioniert noch in 10.11.6. Wenn es bei Ihnen nicht funktioniert, handelt es sich um ein separates Problem, und Sie sollten eine neue Frage stellen.
Mike Scott

105

Sie können SIP deaktivieren, indem Sie auf Recovery HD booten und den folgenden Befehl ausführen:

csrutil disable

Bildbeschreibung hier eingeben

Es ist auch möglich, den SIP-Schutz zu aktivieren und bestimmte Aspekte davon zu deaktivieren, indem dem csrutil enableBefehl ein oder mehrere Flags hinzugefügt werden . Alle müssen von Recovery gebootet werden, um sie einzustellen:

Aktivieren Sie SIP und erlauben Sie die Installation von nicht signierten Kernel-Erweiterungen

csrutil enable --without kext

Bildbeschreibung hier eingeben

Aktivieren Sie SIP und deaktivieren Sie den Dateisystemschutz

csrutil enable --without fs

Bildbeschreibung hier eingeben

Aktivieren Sie SIP und deaktivieren Sie die Debugging-Einschränkungen

csrutil enable --without debug

Bildbeschreibung hier eingeben

Aktivieren Sie SIP und deaktivieren Sie DTrace-Einschränkungen

csrutil enable --without dtrace

Bildbeschreibung hier eingeben

Aktivieren Sie SIP und deaktivieren Sie Einschränkungen beim Schreiben in den NVRAM

csrutil enable --without nvram

Bildbeschreibung hier eingeben

Ich habe auch einen Beitrag mit weiteren Informationen zu SIP:

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


5
Was für ein willkommener Wissensschatz. Vielleicht muss ich dieses Kopfgeld
verdoppeln

Ich erhalte eine Fehlermeldung:csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.
IgorGanapolsky

5
@IgorGanapolsky Lesen Sie die Antwort. " Deaktivieren Sie SIP durch Booten auf Recovery HD " .
Brick

13

Wenn das Ziel darin besteht, den Systemintegritätsschutz wirklich nur zu deaktivieren, ist das Booten der Recovery HD-Partition, wie in den anderen Antworten hier empfohlen, über Command+ rbeim Booten nicht der schnellste Weg.

Sie können den Einzelbenutzermodus-Start mit dem Wiederherstellungs-HD-Start in einer undokumentierten Startschlüsselkombination kombinieren:

Dies bringt Sie nur in die minimale Umgebung, die dafür direkt benötigt wird .


7

Es wäre sicherer, das /etc/pathsso zu modifizieren , dass /usr/local/bines lediglich vorher geht usr/bin. Auf diese Weise können Sie Ihre Entwicklungsarbeit innerhalb von erledigen, /usr/local/binohne SIP deaktivieren zu müssen.

Neuinstallationen des Betriebssystems werden /etc/pathsseit El Capitan auf diese Weise ausgeführt. Wenn Sie jedoch ein Upgrade des Betriebssystems von Yosemite oder einer früheren Version durchführen, müssen Sie die Pfadreihenfolge manuell ändern.


@iconoclast Vor El Capitan bestand eine übliche Konvention darin, Programme zu installieren usr/bin. Da SIP dies jetzt verhindert, sollten Programme installiert werden usr/local/bin, die nicht durch SIP eingeschränkt sind. Als usr/local/binerstes können Benutzer Programme ausführen, ohne den absoluten Pfad zum Programm eingeben zu müssen. Macht das Sinn? Bist du über etwas anderes verwirrt?
user260467

Ich habe immer verstanden, dass es eine sehr schlechte Praxis ist, irgendetwas einzutragen /usr/bin... aber ich denke, ich hätte fragen sollen: "Wie beantwortet das die Frage von OP?" Ich war ursprünglich davon ausgegangen, dass es in irgendeiner Weise geschah und dass ich einfach keine Verbindung aufbaute. Aber jetzt bin ich sehr zweifelhaft, ob es irgendeinen Zusammenhang gibt.
Iconoclast

@iconoclast Ich denke, es wäre unverantwortlich, einem Entwickler nicht zu erwähnen, dass er SIP wirklich nicht deaktivieren sollte, nur um eine App zu entwickeln.
user260467

6

Wenn Sie nur auf / usr / local zugreifen möchten, besuchen Sie diese Seite: https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/El_Capitan_and_Homebrew.md

Die Idee ist , SIP vorübergehend zu deaktivieren, indem csrutil disableSie /usr/localchflags hinzufügen und verwenden, um dieses Verzeichnis auf uneingeschränkt zu setzen

 sudo mkdir /usr/local && sudo chflags norestricted /usr/local && sudo chown -R $(whoami):admin /usr/local

und dann wieder mit SIP aktivieren csrutil enable.

Wenn dies /usr/localzum Zeitpunkt Ihres Upgrades bereits vorhanden ist, ist auch das oben Genannte nicht erforderlich. Sie können einfach laufen

sudo chown -R $(whoami):admin /usr/local

Ich Read-only file system
bekomme

Dieser Link ist tot: 404 Fehler.
Iconoclast

2

Wenn Sie nicht in die Wiederherstellungspartition gelangen können csrutil disable, um SIP auszuführen (zu deaktivieren ), versuchen Sie, die Startargumente mit einem nvramBefehl festzulegen , z

sudo nvram boot-args="rootless=0"

Wenn Sie jedoch den folgenden Fehler haben:

nvram: Fehler beim Setzen der Variablen - 'boot-args': (iokit / common) nicht erlaubt

dann klappt es nicht. Sie müssen es dennoch im Wiederherstellungs- / abgesicherten Modus starten.

Sehen:


nvram: Error setting variable - 'boot-args': (iokit/common) not permitted
Mghicks

1
@mghicks In diesem Fall funktioniert es nicht. Ich habe die Antwort aktualisiert.
Kenorb

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.