Comment désactiver la protection de l'intégrité du système (SIP) AKA «rootless» sur des Mac OS [OS X]

157

Apple a introduit la protection de l'intégrité du système , également connue sous le nom de "rootless", avec OS X 10.11, El Capitan. Je comprends que c’est une étape de la protection générale contre les logiciels malveillants, mais en tant que développeur, j’ai besoin d’un accès en écriture à certains des fichiers qu’il bloque.

Comment désactiver cette protection?

macos sip

— bdnchr
source

2

Même si vous pouvez corriger tous les aspects SIP, il existe de nombreuses entrées pour cela. N'oubliez pas qu'en compromettant le système, vous créez des éléments qui risquent de ne pas s'exécuter sur la machine de votre client, où SIP est activé et que les utilisateurs n'accepteront pas de l'éteindre.

— Motti Shneor

5

@Motti Shneor - Cependant, dans certains cas, il suffit de disposer d'un accès en écriture pour installer certains SDK à des fins de développement. Cela n’obligerait pas le client à faire de même.

— defaultNINJA

Je viens d’unix d’arrière-plan, essayant de comprendre la logique de rootless: c’est parce qu’il s’agit généralement d’un ordinateur mono-utilisateur, tout sera installé dans le répertoire personnel de l’utilisateur, de sorte qu’il n’est pas nécessaire de jouer avec le répertoire système tels que / usr / share / vim /.

— Kemin Zhou

148

La documentation d'Apple couvre la désactivation de SIP, À propos de la protection de l'intégrité du système sur votre Mac et la Configuration de la protection de l'intégrité du système .

Un article sur lifehacker.com énumère ces étapes:

Redémarrez votre Mac en mode de récupération en redémarrant votre ordinateur et en maintenant enfoncé Command+ Rjusqu'à ce que le logo Apple apparaisse sur votre écran.

Cliquez sur Utilitaires> Terminal.

Dans la fenêtre Terminal, tapez csrutil disableet appuyez sur Enter.

Redémarrez votre Mac.

Vous pouvez vérifier si un fichier ou un dossier est restreint en émettant cette lscommande en utilisant le majuscule O (et non pas 0) pour modifier l'indicateur de liste longue:

ls -lO /System /usr

Recherchez le texte restreint pour indiquer où SIP est appliqué.

Par défaut (= SIP activé), les dossiers suivants sont restreints (voir la page d'assistance Apple ):

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

... et les dossiers suivants sont gratuits:

/Applications
/Library
/usr/local

— Mike Scott
source

1

Je vois de courir ls -lO /usr/localn'est pas marqué restreint. J'ai aussi chownd /usr/local/récursivement. Mais je continue à voir la propriété de prendre racine /usr/local/binet /usr/local/sharequi impacte homebrew. Est-ce aussi le travail de SIP?

— SaxDaddy

1

@SaxDaddy Tant qu'il /usr/localn'est pas restreint, vous pouvez corriger facilement les autorisations "situées sous" ce répertoire. Homebrew recommande en réalité de s'exécuter sudo chown -R $(whoami) /usr/local(tout en étant connecté en tant qu'utilisateur administrateur) pour résoudre les problèmes d'autorisation.

— nohillside

4

@SaxDaddy Utilisez-vous Sophos Anti-Virus, par hasard? Il existe un problème connu avec Sophos qui modifie les autorisations sur ces répertoires. Selon un fil de discussion sur leurs forums de communauté , cela devrait être résolu dans une mise à jour qui devrait sortir "bientôt".

— ND Geek

1

@NDGeek: +1: Brillant, merci! Vous l'avez appelé correctement. Et je vois que SAV 9.4.1 (publié le 18nov15) corrige le problème. J'ai cette version installée et j'ai confirmé que les /usr/localautorisations sont correctement définies.

— SaxDaddy

1

@andro L'indicateur -O fonctionne toujours dans 10.11.6. Si cela ne fonctionne pas pour vous, c'est une question distincte et vous devriez poser une nouvelle question.

— Mike Scott

105

Il est possible de désactiver SIP en démarrant sur Recovery HD et en exécutant la commande suivante:

csrutil disable

Il est également possible d'activer les protections SIP et de les désactiver de manière sélective en ajoutant un ou plusieurs indicateurs à la csrutil enablecommande. Tous doivent être démarrés à partir de la récupération pour pouvoir les définir:

Activer SIP et permettre l'installation d'extensions de noyau non signées

csrutil enable --without kext

Activer SIP et désactiver les protections du système de fichiers

csrutil enable --without fs

Activer SIP et désactiver les restrictions de débogage

csrutil enable --without debug

Activer SIP et désactiver les restrictions DTrace

csrutil enable --without dtrace

Activer SIP et désactiver les restrictions sur l'écriture dans la NVRAM

csrutil enable --without nvram

J'ai aussi un article disponible avec plus d'informations sur SIP:

Protection de l'intégrité du système - Ajout d'une autre couche au modèle de sécurité d'Apple

— Rich Trouton
source

5

Quelle richesse de connaissances bienvenue. Il faudra peut-être doubler cette prime :-)

— bmike

Je reçois une erreur:csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.

— IgorGanapolsky

5

@IgorGanapolsky Lisez la réponse. « Désactivez SIP en démarrant sur Recovery HD » .

— Brique

13

Si l'objectif est simplement de désactiver System Integrity Protection, le démarrage de la partition Recovery HD comme recommandé précédemment dans les autres réponses, via Command+ rau démarrage, n'est pas le moyen le plus rapide de procéder.

Vous pouvez combiner un démarrage en mode utilisateur unique avec un démarrage HD de récupération dans une combinaison de touches de démarrage non documentée:

https://support.apple.com/fr-fr/HT204904 couvre la récupération normale
Maintenez Command+ r+ spour démarrer en mode de récupération mono-utilisateur.

Cela vous amène juste dans le strict minimum nécessaire pour cela directement .

— LangLangC
source

7

Il serait plus sûr de modifier /etc/pathsafin que ce /usr/local/binsoit simplement avant usr/bin. De cette façon, vous pouvez effectuer votre travail de développement /usr/local/binsans avoir à désactiver SIP.

Les installations propres du système d'exploitation ont été commandées de /etc/pathscette manière depuis El Capitan, mais si vous mettiez à niveau le système d'exploitation depuis Yosemite ou une version antérieure, vous auriez à modifier manuellement l'ordre des chemins.

— utilisateur260467
source

@iconoclast Avant El Capitan, une convention commune consistait à installer des programmes sur usr/bin. Comme SIP empêche cela maintenant, les programmes doivent être installés sur usr/local/bin, ce qui n’est pas restreint par SIP. En mettant d' usr/local/binabord, les utilisateurs peuvent exécuter des programmes sans avoir à taper le chemin absolu vers le programme. Est-ce que ça a du sens? Êtes-vous confus à propos de quelque chose d'autre?

— user260467

J'ai toujours compris que c'était une très mauvaise pratique de mettre quoi /usr/binque ce soit ... mais je suppose que ce que j'aurais dû demander, c'est "comment cela répond-il à la question de OP?" Je supposais à l' origine qu'il a fait en quelque sorte, et que je viens de ne faisais pas la connexion. Mais maintenant, je doute fort que cela ait un lien.

— iconoclaste

@iconoclast Je pense qu'il serait irresponsable de ne pas mentionner à un développeur qu'il ne devrait vraiment pas désactiver SIP uniquement pour développer une application.

— user260467

6

Si tout ce dont vous avez besoin est d'accéder à / usr / local, consultez cette page: https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/El_Capitan_and_Homebrew.md

L’idée est de désactiver temporairement SIP en utilisant csrutil disable, ajouter /usr/local, utiliser chflags pour définir ce répertoire comme étant non restreint.

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

puis réactivez SIP en utilisant csrutil enable.

S'il /usr/localexiste déjà au moment de votre mise à niveau, même ce qui précède n'est pas nécessaire. Vous pouvez simplement courir

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

— m_cuffa
source

Je continue à avoir une erreur:Read-only file system

— IgorGanapolsky

Ce lien est mort: erreur 404.

— iconoclaste

2

Si vous ne parvenez pas à exécuter la partition de récupérationcsrutil disable (pour désactiver SIP ), essayez de définir les arguments de démarrage avec la nvramcommande, par exemple:

sudo nvram boot-args="rootless=0"

Cependant, si vous avez l'erreur suivante:

nvram: Variable de paramétrage d'erreur - 'boot-args': (iokit / common) non autorisé

alors ça ne marchera pas. Vous devez toujours démarrer le mode récupération / sans échec.

Voir:

— Kenorb
source

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

— Mghicks

1

@mghicks Dans ce cas, cela ne fonctionnera pas. J'ai mis à jour la réponse.

— Kenorb

0

Je n'ai pas assez de réputation pour ajouter cela en tant que commentaire au lien github Homebrew 404 ci-dessus. La Wayback Machine l'a toujours:

http://web.archive.org/web/20160117204214/https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/El_Capitan_and_Homebrew.md

— Setaa
source