Quelle est la fonctionnalité «sans racine» dans El Capitan, vraiment?

Je viens tout juste d'apprendre la fonctionnalité "Rootless" d'El Capitan, et j'entends des choses comme "Il n'y a pas d'utilisateur root", "Rien ne peut modifier /System" et "Le monde va se terminer parce que nous ne pouvons pas obtenir de racine".

Quelle est la fonctionnalité "sans racines" d'El Capitan au niveau technique? Qu'est-ce que cela signifie réellement pour l'expérience utilisateur et l'expérience développeur? Cela sudo -sfonctionnera- t-il toujours et, dans l'affirmative, comment l'expérience de l'utilisation d'une coquille rootchangera-t-elle?

Premièrement: le nom "rootless" est trompeur, car il existe toujours un compte root et vous pouvez toujours y accéder (le nom officiel "System Integrity Protection" est plus précis). En réalité, il limite la puissance du compte root. Ainsi, même si vous devenez root, vous n’avez pas le plein contrôle du système. En gros, l’idée est qu’il est trop facile pour les logiciels malveillants d’obtenir un accès root (par exemple, en présentant un dialogue d’authentification à l’utilisateur, ce qui le poussera à entrer de manière réflexe le mot de passe de l’administrateur). SIP ajoute une autre couche de protection que les logiciels malveillants ne peuvent pénétrer même s’ils sont root. La mauvaise partie de cela, bien sûr, c'est que cela doit également s'appliquer aux choses que vous faites intentionnellement. Mais les restrictions qu’il impose à la racine ne sont pas si mauvaises; ils n'empêchent pas le plus "normal"

Voici ce que cela limite, même de la racine:

• Vous ne pouvez pas modifier quoi que ce soit dans /System, /bin, /sbinou /usr(sauf /usr/local); ou l'une des applications et des utilitaires intégrés. Seuls les programmes d'installation et les mises à jour logicielles peuvent modifier ces zones et ne le font même que lors de l'installation de packages signés par Apple. Mais comme les personnalisations normales de style OS X vont /Library(ou ~/Library, ou /Applications), et les personnalisations de style Unix (par exemple, Homebrew), /usr/local(ou parfois /etcou /opt), cela ne devrait pas être un gros problème. Cela empêche également les écritures de niveau bloc sur le disque de démarrage, vous ne pouvez donc pas le contourner.

  La liste complète des répertoires restreints (et des exceptions comme /usr/localet quelques autres) se trouve dans /System/Library/Sandbox/rootless.conf. Bien entendu, ce fichier est lui-même dans une zone restreinte.

  Lorsque vous effectuez une mise à niveau vers El Capitan, tous les fichiers "non autorisés" des zones restreintes sont déplacés vers /Library/SystemMigration/History/Migration-(some UUID)/QuarantineRoot/.

• Vous ne pouvez pas vous attacher à des processus système (par exemple ceux qui s'exécutent à partir de ces emplacements système) pour des tâches telles que le débogage (ou changer les bibliothèques dynamiques qu'ils chargent, ou d'autres choses). Encore une fois, pas trop grave; Les développeurs peuvent toujours déboguer leurs propres programmes.

  Cela bloque certaines choses importantes telles que l’injection de code dans les applications Apple intégrées (notamment le Finder). Cela signifie également que les dtraceoutils basés sur la surveillance système (par exemple opensnoop) ne pourront pas surveiller et générer des rapports sur de nombreux processus système.

• Vous ne pouvez pas charger d'extensions de noyau (kexts) à moins qu'elles ne soient correctement signées (c'est-à-dire par Apple ou un développeur approuvé par Apple). Notez que cela remplace l’ancien système d’application de la signature kext (et les anciennes méthodes de contournement). Mais depuis la v10.10.4, Apple dispose d’ un moyen d’activer la prise en charge du découpage pour les SSD tiers , la raison n ° 1 d’utiliser des kexts non signés a disparu.

• À partir de Sierra (10.12), certains paramètres de configuration launchd ne peuvent pas être modifiés (par exemple, certains démons de lancement ne peuvent pas être déchargés).

• À partir de Mojave (10.14), l'accès aux informations personnelles des utilisateurs (e-mail, contacts, etc.) est limité aux applications que l'utilisateur a approuvées pour accéder à ces informations. Ceci est généralement considéré comme une fonctionnalité distincte (appelée protection des informations personnelles, ou TCC), mais il est basé sur SIP et sa désactivation le désactive également. Voir: "Qu'est-ce que macOS Mojave et comment implémenter pour restreindre l'accès des applications aux données personnelles?"

Si vous ne souhaitez pas ces restrictions, soit parce que vous souhaitez modifier votre système au-delà de ce que cela permet, ou parce que vous développez et déboguez quelque chose comme des mots clés qui ne sont pas pratiques avec ces restrictions, vous pouvez désactiver SIP. Actuellement, cela nécessite un redémarrage en mode de récupération et l'exécution de la commande csrutil disable(et vous pouvez également la réactiver avec csrutil enable).

Vous pouvez également désactiver sélectivement des parties de SIP. Par exemple, csrutil enable --without kextdésactivera la restriction d'extension du noyau de SIP, mais laissera ses autres protections en place.

Mais arrêtez-vous et réfléchissez avant de désactiver SIP, même temporairement ou partiellement: avez-vous vraiment besoin de le désactiver ou existe-t-il une meilleure façon (compatible SIP) de faire ce que vous voulez? Avez - vous vraiment besoin de modifier quelque chose dans /System/Libraryou /binou autre, ou pourrait - il aller dans un meilleur endroit comme /Libraryou /usr/local/binetc? SIP peut "sembler" contraignant si vous n’êtes pas habitué, et il existe des raisons légitimes de le désactiver, mais une grande partie de ce qu’il impose impose en réalité à la meilleure pratique.

Considérez les événements du 23 septembre 2019 pour souligner l'importance de laisser le plus de temps possible SIP activé. Google a publié une mise à jour de Chrome qui tentait de remplacer le lien symbolique de /varvers /private/var. Sur la plupart des systèmes, SIP a bloqué ceci et il n'y a pas eu de mauvais effets. Sur les systèmes avec SIP désactivé, macOS est cassé et ne peut plus démarrer. La raison la plus courante pour désactiver SIP était de charger des extensions de noyau non approuvées (/ mal signées) (en particulier des pilotes vidéo); s'ils avaient seulement désactivé la restriction kext, ils n'auraient pas été affectés. Consultez le fil de discussion officiel de Google , un Q & A sur les super-utilisateurs et un article sur Ars Technica .

Références et autres informations: présentation de la WWDC sur «La sécurité et vos applications» , une bonne explication d’Eldad Eilam sur quora.com , la revue Ars Technica d’El Capitan et un article de support Apple sur SIP , ainsi qu’une analyse approfondie de Rich Trouton ( qui a également posté une réponse à cette question ).

Pour moi, cela signifie que DTrace ne fonctionne plus.

DTrace est similaire à ptrace / strace sous Linux, en ce sens qu'il vous permet de voir ce qu'un processus dit au noyau. Chaque fois qu'un processus veut ouvrir un fichier, écrire un fichier ou ouvrir un port, etc., il doit interroger le noyau. Sous Linux, ce processus de surveillance se déroule hors du noyau dans "userland", et les autorisations sont donc assez détaillées. Un utilisateur peut surveiller ses propres applications (pour corriger des bogues, trouver des fuites de mémoire, etc.), mais il doit être root pour surveiller le processus d'un autre utilisateur.

DTrace sur OSX fonctionne toutefois au niveau du noyau, ce qui le rend beaucoup plus performant et puissant. Toutefois, un accès root est nécessaire pour ajouter ses sondes au noyau et ainsi faire quoi que ce soit. Un utilisateur ne peut pas suivre ses propres processus sans être root, mais en tant que root, il peut non seulement surveiller ses propres processus, mais en réalité TOUS les processus simultanément sur le système. Par exemple, vous pouvez regarder un fichier (avec iosnoop) et voir quel processus le lit. C'est l'une des fonctionnalités les plus utiles à ce jour pour détecter les logiciels malveillants. Etant donné que le noyau traite également des E / S réseau, il en va de même ici. Wireshark détecte les activités réseau inhabituelles, DTrace vous indique le processus d'envoi des données, même s'il est intégré au système comme le noyau lui-même.

Cependant, depuis El Capitan, Apple a délibérément empêché DTrace de fonctionner, car il a été spécifiquement ciblé et désigné comme un élément restreint par SIP. Pourquoi feraient-ils cela? Eh bien, auparavant, Apple avait modifié son noyau et DTrace pour permettre à certains processus de ne pas être surveillés via DTrace (qui dérangeaient de nombreux chercheurs en sécurité à l'époque, certains processus étant désormais inaccessibles, même en tant que root, y compris les logiciels malveillants). Leur raison en était de protéger les DRM dans des applications telles qu'iTunes puisque, théoriquement, quelqu'un pourrait créer et extraire des données non DRM de la mémoire des processus.

Cependant, un important travail de contournement a permis aux chercheurs de continuer à faire leur travail: il s'agissait de modifier le noyau pour ignorer cet indicateur de désabonnement afin que DTrace puisse toujours être utilisé sur ces processus. En fait, c’était vraiment bien parce que les programmes qui tentaient d’éviter la détection s’allumaient maintenant avec ce drapeau «non-DTrace». Tout ce que Apple ou les méchants voulaient cacher était désormais à la vue de tous ...

Mais cela ne fonctionne pas maintenant, alors comment cela vous affecte-t-il? Eh bien, cela vous affectera directement et indirectement. Directement, cela limitera votre capacité à surveiller votre système. Un grand nombre d'outils d'administration et de surveillance de système de bas niveau (sur lesquels s'appuient des outils de niveau supérieur) ne fonctionneront plus. L'effet indirect sera toutefois beaucoup plus important: les professionnels de la sécurité s'appuient sur un accès système approfondi pour détecter les pires types de menaces. Nous ne pouvons tout simplement plus le faire. Lors de l'analyse d'un logiciel malveillant, il est essentiel de ne pas savoir qu'il est exécuté dans un débogueur ou un pot de miel. La désactivation de SIP indique à tous les logiciels, qu'ils soient méchants ou Apple, que ce système est surveillé. Pas plus regarder les observateurs. Si SIP concernait la sécurité, ils auraient pu renseigner les utilisateurs sur root. Ils l'ont plutôt supprimé. En fin de compte, cela signifie qu'Apple a remplacé la barrière de sécurité du mot de passe racine «be all and end all» avec le mécanisme de protection SIP «be all and end all». Ou si vous êtes bon en ingénierie sociale, un mot de passe root avec un redémarrage ...

Il y a aussi ceci:

La protection de l'intégrité du système (SIP) est une politique de sécurité globale visant à empêcher la modification des processus et des fichiers système par des tiers. Pour ce faire, il repose sur les concepts suivants:

• Protection du système de fichiers
• Protection de l'extension du noyau
• Protection d'exécution

Protection du système de fichiers

SIP empêche les parties autres que Apple d'ajouter, de supprimer ou de modifier des répertoires et des fichiers stockés dans certains répertoires:

/bin
/sbin
/usr
/System

Apple a indiqué que les répertoires suivants sont accessibles aux développeurs:

/usr/local
/Applications
/Library
~/Library

Tous les répertoires à l' /usrexception de /usr/localsont protégés par SIP.

Il est possible d'ajouter, de supprimer ou de modifier des fichiers et des répertoires protégés par SIP via un package d'installation signé par la propre autorité de certification d'Apple. Cela permet à Apple d'apporter des modifications aux parties du système d'exploitation protégées par SIP sans avoir à modifier les protections SIP existantes.

L’autorité de certification en question est réservée par Apple pour leur propre usage; Les packages d'installation signés par l'ID de développeur ne peuvent pas modifier les fichiers ou les répertoires protégés par SIP.

Pour définir les répertoires protégés, Apple a défini deux fichiers de configuration sur le système de fichiers. Le principal se trouve à l'emplacement ci-dessous:

/System/Library/Sandbox/rootless.conf

où rootless.confrépertorie toutes les applications et les répertoires de niveau supérieur protégés par SIP.

Applications

SIP protège les principales applications installées par OS X dans Applications et Applications Utilities. Cela signifie qu'il ne sera plus possible de supprimer les applications installées par OS X, même à partir de la ligne de commande lors de l'utilisation des privilèges root.

Répertoires

SIP protège également un certain nombre de répertoires et de liens symboliques en dehors de, /Applicationset le niveau supérieur de ces répertoires est également répertorié dans rootless.conf.

Outre les protections, Apple a également défini certaines exceptions à la protection de SIP dans le fichier rootless.conf. Ces exceptions sont marquées d'un astérisque. Ces exemptions de la protection de SIP signifient qu'il est possible d'ajouter, de supprimer ou de modifier des fichiers et des répertoires au sein de ces emplacements.

Parmi ces exceptions sont les suivantes:

• /System/Library/User Template - où OS X stocke les répertoires de modèles qu'il utilise lors de la création de dossiers de base pour les nouveaux comptes.
• /usr/libexec/cups - où OS X stocke les informations de configuration de l'imprimante

Apple considère que ce fichier est le leur et que les modifications apportées par des tiers à ce fichier seront écrasées par Apple.

Pour voir quels fichiers ont été protégés par SIP, utilisez la lscommande avec tiret majuscule O dans Terminal:

ls -O

Les fichiers protégés par SIP seront étiquetés comme étant restreints .

Il est important de savoir que même si un lien symbolique est protégé par SIP, cela ne signifie pas nécessairement que le répertoire auquel ils sont liés est protégé par SIP. Au niveau racine d'un lecteur d'amorçage OS X El Capitan, plusieurs liens symboliques protégés par SIP pointent vers des répertoires stockés dans le répertoire de niveau racine nommé private.

Toutefois, lorsque le contenu du privaterépertoire est examiné, les répertoires vers lesquels pointent ces liens symboliques ne sont pas protégés par SIP et peuvent être déplacés, édités ou modifiés, ainsi que leur contenu, par des processus utilisant les privilèges root.

Outre la liste des exceptions SIP qu'Apple a définie rootless.conf, il existe une deuxième liste d'exceptions SIP. Cette liste comprend un certain nombre de répertoires et de noms d'applications pour des produits tiers. Semblable à rootless.conf, cette liste d'exclusion appartient à Apple et les modifications apportées par des tiers à celle-ci seront écrasées par Apple.

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

Protection d'exécution

Les protections SIP ne se limitent pas à la protection du système contre les modifications du système de fichiers. Il existe également des appels système dont les fonctionnalités sont désormais limitées.

• task_for_pid () / processor_set_tasks () échoue avec EPERM
• Les ports spéciaux Mach sont réinitialisés sur exec (2)
• les variables d'environnement dyld sont ignorées
• Sondes DTrace non disponibles

Cependant, SIP ne bloque pas l'inspection par le développeur de ses propres applications pendant leur développement. Les outils de Xcode continueront à permettre aux applications d'être inspectées et déboguées pendant le processus de développement.

Pour plus de détails à ce sujet, je vous conseillerais de consulter la documentation de développement Apple pour SIP .

Protection de l'extension du noyau

SIP bloque l'installation des extensions de noyau non signées. Pour installer une extension de noyau sur OS X El Capitan avec SIP activé, une extension de noyau doit:

1. Être signé avec un certificat de développeur pour Signing Kexts
2. Installer dans / Bibliothèque / Extensions

Si vous installez une extension de noyau non signée, SIP doit d'abord être désactivé.

Pour plus d'informations sur la gestion de SIP, veuillez consulter le lien ci-dessous:

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