Apple a introduit Protection de l'intégrité du système également connu sous le nom de "rootless", avec OS X 10.11, El Capitan. Je comprends qu'il s'agit d'une mesure de 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'elle verrouille.
Comment désactiver cette protection ?
Comme le dit Apple dans le la documentation du développeur sur SIP :
Avertissement
Ne désactivez SIP que temporairement pour effectuer les tâches nécessaires, et réactivez-le dès que possible. Si vous ne réactivez pas le protocole SIP lorsque vous avez terminé les tests, votre ordinateur reste vulnérable aux codes malveillants.
Si vous essayez simplement de configurer des outils de développement de système tels que vim , python2 , ruby et ainsi de suite, il est presque certain que vous ne voulez installer que des versions maintenues par la communauté à partir des sites suivants Homebrew et de les configurer à la place. Les outils fournis par le système peuvent être pratiques pour démarrer, mais si vous avez besoin d'exceptions SIP pour votre flux de travail quotidien, vous êtes presque certainement en train de faire les choses d'une manière qui se cassera dans une future version du système d'exploitation, et qui peut casser des applications et d'autres fonctionnalités du système entre-temps.
Les raisons valables pour désactiver le SIP vous-même peuvent être :
Au-delà des implications en matière de sécurité, il est également important de noter que tout ce que vous faites sur un Mac avec le SIP désactivé ne fonctionnera sur personne. d'autres mac, à moins qu'ils ne le désactivent aussi d'abord. Si vous développez des applications pour Mac, votre système devient moins utile en tant que banc d'essai car vous ne savez pas si votre code fonctionne uniquement parce que vous avez piraté votre système. Si vous développez pour une autre plate-forme, par exemple pour un déploiement sur un serveur Web, vous ne pouvez pas partager la configuration de votre environnement de développement avec les autres développeurs de votre équipe sans compromettre également leur sécurité.
La documentation d'Apple couvre la désactivation de SIP, À propos de la protection de l'intégrité du système sur votre Mac y 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ée la touche Command + R jusqu'à ce que le logo Apple apparaisse sur votre écran.
- Cliquez sur Utilitaires > Terminal.
- Dans la fenêtre du 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 la commande suivante ls en utilisant la majuscule O (et non le zéro 0) pour modifier le drapeau de la liste longue :
ls -lO /System /usr Cherchez le restreint texte pour indiquer où le SIP est appliqué.
Par défaut (=SIP activé), les dossiers suivants sont limités (voir Page de support Apple ):
/System
/usr
/bin
/sbin
Apps that are pre-installed with OS X... et les dossiers suivants sont libres :
/Applications
/Library
/usr/local
Je vois qu'en courant ls -lO /usr/local n'est pas marqué "restreint". J'ai aussi mangé /usr/local/ de manière récursive. Mais je continue à voir Root s'approprier /usr/local/bin y /usr/local/share qui a un impact sur le homebrew. Est-ce que c'est aussi le travail de SIP ?
@SaxDaddy Tant que /usr/local n'est pas restreint, vous pouvez facilement fixer les permissions "sous" ce répertoire. Homebrew recommande en fait d'exécuter sudo chown -R $(whoami) /usr/local (tout en étant connecté en tant qu'utilisateur admin) pour corriger les problèmes de permission.
@patrix Merci. Je suis toujours curieux car /usr/local est pas restreints et dotés par moi quotidien . Chaque jour, je vois toujours ces deux mêmes dossiers appartenant à Root. Je vais parcourir la console et mettre à jour si je trouve le coupable.
Il est possible de désactiver SIP en démarrant en mode Recovery HD et exécuter la commande suivante :
csrutil disable
Il est également possible d'activer les protections SIP et d'en désactiver sélectivement certains aspects, en ajoutant un ou plusieurs drapeaux à la balise csrutil enable commandement. Toutes les commandes nécessitent d'être démarrées à partir de Recovery afin de 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 le SIP et désactiver les restrictions DTrace
csrutil enable --without dtrace
Activez le SIP et désactivez les restrictions d'écriture dans la NVRAM.
csrutil enable --without nvram
J'ai également un post disponible avec plus d'informations sur SIP :
System Integrity Protection - Ajout d'une couche supplémentaire au modèle de sécurité d'Apple
Quelle richesse de connaissances bienvenue. Il se pourrait que je doive doubler la mise sur cette prime :-)
Je reçois une erreur : csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.
Si l'objectif est de désactiver la protection de l'intégrité du système, il suffit de démarrer sur la partition du disque dur de récupération, comme cela a été recommandé dans les autres réponses ici via Command + r au démarrage est no le moyen le plus rapide de le faire.
Vous pouvez combiner le démarrage en mode utilisateur unique avec le démarrage du disque de récupération dans une combinaison de touches de démarrage non documentée :
Cela vous permet de disposer de l'environnement minimum nécessaire pour cette opération. directement .
Il serait plus sûr de modifier /etc/paths de sorte que /usr/local/bin est simplement avant usr/bin . De cette façon, vous pouvez faire votre travail de développement dans /usr/local/bin sans avoir à désactiver le SIP.
Les installations propres de l'OS ont commandé /etc/paths de cette façon depuis El Capitan, mais si vous mettez à jour le système d'exploitation à partir de Yosemite ou d'une version antérieure, vous devez modifier l'ordre des chemins manuellement.
@iconoclast Avant El Capitan, une convention commune était d'installer les programmes sur usr/bin . Puisque SIP empêche cela maintenant, des programmes devraient être installés pour usr/local/bin qui n'est pas limité par le protocole SIP. En mettant usr/local/bin Tout d'abord, les utilisateurs peuvent exécuter des programmes sans avoir à taper le chemin absolu du programme. Est-ce que cela a du sens ? Vous avez des doutes sur quelque chose d'autre ?
J'ai toujours pensé que c'était une très mauvaise pratique de mettre quelque chose dans /usr/bin ... mais je crois que j'aurais dû demander "en quoi cela répond-il à la question de l'OP ?". Je supposais à l'origine que cela a fait d'une certaine manière, et que je ne faisais pas le lien. Mais maintenant, je doute fort qu'il y ait un lien.
Si tout ce dont vous avez besoin est d'accéder à /usr/local, jetez un coup d'oeil à cette page : http://web.archive.org/web/20160117204214/https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/El_Capitan_and_Homebrew.md
L'idée est de temporairement désactiver SIP en utilisant csrutil disable , ajouter /usr/local Utilisez chflags pour définir ce répertoire comme non restreint.
sudo mkdir /usr/local && sudo chflags norestricted /usr/local && sudo chown -R $(whoami):admin /usr/localpuis réactivez SIP en utilisant csrutil enable .
Si /usr/local existe déjà au moment de votre mise à jour, alors même ce qui précède n'est pas nécessaire. Vous pouvez simplement exécuter
sudo chown -R $(whoami):admin /usr/localLesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.
2 votes
Même si vous pouvez corriger tous les aspects de SIP, il y a beaucoup d'entrées pour cela - n'oubliez pas qu'en compromettant le système, vous construisez des choses qui ne fonctionneront peut-être pas sur la machine de votre client, où SIP est activé, et les utilisateurs n'accepteront pas de le désactiver.
5 votes
@Motti Shneor - Cependant, dans certains cas, il est nécessaire d'activer cette fonction pour disposer d'un accès en écriture afin d'installer certains SDK à des fins de développement. Cela n'obligerait pas le client à faire de même.
0 votes
Je viens d'un environnement Unix et j'essaie de comprendre la logique de l'absence de racine : est-ce parce que l'ordinateur est le plus souvent une machine mono-utilisateur, tout sera installé dans le répertoire personnel de l'utilisateur, de sorte qu'il n'y a pas besoin de s'occuper du répertoire système tel que /usr/share/vim/.
0 votes
La prémisse de cette question est incorrecte. En tant que développeur, vous devez impérativement pas besoin d'écrire dans les fichiers qu'il verrouille.