Qu'est-ce que la fonction "sans racine" d'El Capitan, en réalité ?

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 le demander au noyau. Sous Linux, ce processus de surveillance se déroule en dehors du noyau, dans le "userland", et les permissions sont donc assez fines. Un utilisateur peut surveiller ses propres applications (pour corriger des bogues, trouver des fuites de mémoire, etc.) mais il faudrait être Root pour surveiller le processus d'un autre utilisateur.

DTrace sur OSX fonctionne cependant au niveau du noyau, ce qui le rend beaucoup plus performant et puissant, mais il nécessite un accès Root pour ajouter ses sondes dans le noyau et ainsi faire quelque chose. 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 fait TOUS les processus du système simultanément. Par exemple, vous pouvez surveiller un fichier (avec iosnoop) et voir quel processus le lit. C'est l'une des fonctionnalités les plus utiles pour détecter les logiciels malveillants. Comme le noyau traite également les entrées-sorties réseau, il en va de même. Wireshark détecte une activité réseau inhabituelle, DTrace vous indique le processus qui envoie les données, même s'il est aussi intégré au système que le noyau lui-même.

Cependant, à partir d'El Capitan, Apple a délibérément empêché DTrace de fonctionner, c'est-à-dire qu'il a été spécifiquement ciblé et désigné comme une restriction de SIP. Pourquoi font-ils cela ? Eh bien, Apple avait auparavant modifié son noyau et DTrace pour permettre à certains processus de ne pas être surveillés par DTrace (ce qui a contrarié de nombreux chercheurs en sécurité à l'époque, car certains processus étaient désormais hors limites, même en tant que Root - y compris les logiciels malveillants). La raison de cette modification était de protéger les DRM dans des applications comme iTunes, puisque théoriquement quelqu'un pouvait DTrace et récupérer des données non DRM dans la mémoire des processus.

Cependant, il existait une solution de contournement importante qui permettait aux chercheurs de continuer à faire leur travail, et qui consistait à modifier le noyau pour qu'il ignore ce drapeau d'exclusion, de sorte que DTrace pouvait toujours être utilisé sur ces processus. C'était en fait très bien parce que les programmes qui essayaient d'échapper à la détection étaient maintenant éclairés par ce drapeau "no-DTrace". Tout ce qu'Apple ou les méchants voulaient cacher était maintenant à la vue de tous...

Mais cela ne fonctionne pas maintenant, alors comment cela vous affecte-t-il ? Eh bien, cela vous affectera à la fois directement et indirectement. Directement, cela limitera votre capacité à surveiller votre système. Un grand nombre d'outils d'administration et de surveillance du système de bas niveau (sur lesquels reposent les outils de plus haut niveau) ne fonctionneront plus. L'effet indirect sera cependant beaucoup plus important : les professionnels de la sécurité comptent sur un accès profond au système pour détecter les pires types de menaces. Nous ne pouvons tout simplement plus le faire. Il est essentiel, lors de l'analyse d'un logiciel malveillant, que celui-ci ne sache pas qu'il fonctionne dans un débogueur ou un pot de miel. La désactivation de SIP indique à tous les logiciels, qu'il s'agisse des malfaiteurs ou d'Apple, que ce système est surveillé. Plus de surveillance des surveillants. Si SIP était une question de sécurité, ils auraient pu éduquer les utilisateurs sur Root - au lieu de cela, ils l'ont supprimé. En fin de compte, cela signifie qu'Apple a remplacé la barrière de sécurité "tout et tout le temps" du mot de passe Root, par le mécanisme de protection SIP "tout et tout le temps". Ou si vous êtes bon en ingénierie sociale, un mot de passe Root avec un reboot...

Il y a aussi ça :

La protection de l'intégrité du système (SIP) est une politique de sécurité globale dont l'objectif est d'empêcher les fichiers et les processus du système d'être modifiés par des tiers. Pour y parvenir, elle repose sur les concepts suivants :

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

Protection du système de fichiers

SIP empêche les parties autres qu'Apple d'ajouter, de supprimer ou de modifier les répertoires et les 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 dans /usr sauf pour /usr/local sont protégés par le SIP.

Il est possible d'ajouter, de supprimer ou de modifier des fichiers et des répertoires protégés par SIP via un paquet 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 son propre usage ; les paquets d'installation signés par l'ID du développeur ne sont pas en mesure de modifier les fichiers ou les répertoires protégés par SIP.

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

/System/Library/Sandbox/rootless.conf

où rootless.conf liste toutes les applications et le premier niveau des répertoires que SIP protège.

Applications

SIP protège les applications de base qu'OS X installe dans Applications et Utilitaires d'applications. 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 en utilisant les privilèges Root.

Annuaires

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

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

Parmi ces exceptions figurent les suivantes :

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

Apple considère que ce fichier lui appartient et que toute modification apportée par un tiers sera écrasée par Apple.

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

ls -O

Les fichiers protégés par SIP seront étiquetés en tant que restreint .

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 il est lié est protégé par SIP. Au niveau de la racine d'un disque de démarrage d'OS X El Capitan, il existe plusieurs liens symboliques protégés par SIP pointant vers des répertoires stockés dans le répertoire de niveau racine nommé private .

Toutefois, lorsque le contenu de la private sont examinés, les répertoires vers lesquels pointent ces liens symboliques ne sont pas protégés par SIP et tant ces répertoires que leur contenu peuvent être déplacés, édités ou modifiés par des processus utilisant les privilèges Root.

En plus de la liste d'exceptions SIP qu'Apple a établie en 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. Comme pour rootless.conf Cette liste d'exclusion est celle d'Apple et toute modification apportée par un tiers à cette liste sera écrasée par Apple.

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

Protection de l'exécution

Les protections de SIP ne se limitent pas à protéger le système contre les modifications du système de fichiers. Il existe également des appels système dont la fonctionnalité est désormais limitée.

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

Cependant, le SIP ne bloque pas l'inspection par le développeur de ses propres applications pendant leur développement. Les outils de Xcode continueront à permettre l'inspection et le débogage des applications pendant le processus de développement.

Pour plus de détails à ce sujet, je vous recommande de consulter le site suivant Documentation d'Apple pour les développeurs concernant SIP .

Protection de l'extension du noyau

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

1. être signé par un ID du développeur pour la signature de Kexts certificat
2. Installer dans /Bibliothèque/Extensions

Si vous installez une extension de noyau non signée, il faudra d'abord désactiver SIP.

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

System Integrity Protection - Ajout d'une couche supplémentaire au modèle de sécurité d'Apple