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 ?

macos el-capitan kernel-extensions sip Synoli
la 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`?