Que disent les sources

Comme tout le monde, mon /System/Library/Sandbox/rootless.conffichier contient les entrées suivantes:

$ cat /System/Library/Sandbox/rootless.conf
[…]
        /System
[…]
*       /System/Library/Extensions
        /System/Library/Extensions/*
[…]

Toutes les sources sur le sujet que j'ai trouvées (exemple 1 2 3 ) semblent suggérer que selon les règles de rootless.conf, ces entrées seront appliquées au démarrage et peuvent être interprétées comme suit:

À l'intérieur de la /Systemhiérarchie , aucun processus n'est autorisé à écrire dans un fichier ou un dossier, sauf lorsqu'une règle plus spécifique accorde un tel accès;
à l'intérieur/System/Library/Extensions , tout processus disposant de privilèges root est autorisé à créer de nouveaux fichiers et sous-dossiers;
cependant, aucun processus n'est autorisé à modifier ou supprimer des fichiers ou sous-dossiers existants à l' intérieur /System/Library/Extensions.

Ce que j'observe réellement

Cependant, lorsque j'ai regardé le contenu réel de /System/Library/Extensions, j'ai découvert à ma grande surprise plusieurs fichiers et dossiers qui, malgré l'activation de SIP, sont parfaitement inscriptibles et supprimables:

$ csrutil status
System Integrity Protection status: enabled.
$ ls -lAO /System/Library/Extensions | tail -16
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 corecrypto.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 exfat.kext
drwxr-xr-x  3 root  wheel  -            102 19 Aug  2013 hp_Inkjet9_io_enabler.kext
drwxr-xr-x  3 root  wheel  -            102 27 Apr  2013 hp_fax_io.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 iPodDriver.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 mcxalr.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 msdosfs.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 ntfs.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 pmtelemetry.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 pthread.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 smbfs.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 triggers.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 udf.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 vecLib.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 webcontentfilter.kext
drwxr-xr-x@ 3 root  wheel  restricted   102 20 Apr  2016 webdav_fs.kext

Notez que hp_Inkjet9_io_enabler.kextet hp_fax_io.kextsont des extensions du noyau tiers qui étaient déjà présents au I temps mis à jour à El Capitan (que je fait en mai 2016).

Lorsque je recherche la liste des exceptions SIP sur /System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths, je ne vois pas non plus ces extensions tierces répertoriées:

$ defaults read /System/Library/Sandbox/Compatibility.bundle/Contents/Info.plist CFBundleVersion
12.0
$ grep Extensions /System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths
/System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleRTL815XComposite109.kext
/System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleRTL815XEthernet109.kext

J'ai trouvé plus d'une douzaine d'extensions de noyau supplémentaires qui manquent également d' restrictedindicateur et d' com.apple.rootlessattribut; toutes les extensions de noyau affectées semblent être des extensions tierces que j'ai installées au cours de la dernière décennie et ont apparemment survécu à la mise à jour d'El Capitan.

Ce qui m'interroge sur les énigmes suivantes:

Ce que j'aimerais savoir

Q1. Drapeaux manquants

Comment se fait-il qu'aucune extension de noyau tiers - et en fait aucun fichier que je crée manuellement à l'intérieur /System/Library/Extensions- ne reçoive un restrictedindicateur ou un com.apple.rootlessattribut, même si la rootless.confrègle semble prescrire le contraire?

Par exemple, un ls -dlOlong de la chaîne de chemin d'accès hp_fax_io.kextrévèle:

$ ruby -rpathname -e 'puts Pathname.new("/System/Library/Extensions/hp_fax_io.kext").enum_for(:ascend).to_a' | xargs ls -dlO
drwxr-xr-x   39 root  wheel  -           1394 19 Jan 11:36 /
drwxr-xr-x@   4 root  wheel  restricted   136 19 Jan 11:29 /System
drwxr-xr-x   80 root  wheel  restricted  2720 10 Jan 19:19 /System/Library
drwxr-xr-x  297 root  wheel  sunlnk     10098 22 Jan 00:57 /System/Library/Extensions
drwxr-xr-x    3 root  wheel  -            102 27 Apr  2013 /System/Library/Extensions/hp_fax_io.kext

Je me souviens également qu'au moment de la mise à niveau de Yosemite, l'installateur El Capitan a choisi de déplacer pratiquement tout et leur grand-mère en quarantaine SIP dans de nombreux cas.

Q2. Moment de l'exécution

Si je devais:

démarrer dans un volume de récupération,
puis ajoutez rootless.conf(sur le volume d'origine) une ligne:
```
/usr/local/*
```
puis redémarrez à nouveau dans le volume d'origine,

macOS éteindrait-il alors tous les fichiers sous /usr/local/avec des restricteddrapeaux au prochain redémarrage?

Sinon, cela m'amène à ma dernière question:

Q3. Objectif réel

À quoi sert rootless.conf réellement ?

— Synoli
source

J'aimerais bien que quelqu'un de la communauté ait quelques réponses ou même des indices. J'ai des questions similaires.

— CXJ

Dans cette optique, la modification de rootless.conf (désactiver SIP, modifier le fichier, réactiver SIP) ne devrait-elle pas modifier les répertoires protégés? Cela ne semble pas se produire réellement ... alors le fichier est-il lu du tout?

— Wowfunhappy

Pourquoi mon `rootless.conf` n'affecte-t-il pas toujours le choix par SIP des fichiers qui reçoivent le traitement d'indicateur` restreint`?