L'accès privilégié aux fichiers et aux répertoires est en fait déterminé par les capacités, pas seulement en étant root
ou non. En pratique, root
a généralement toutes les fonctionnalités possibles, mais il existe des situations où toutes/beaucoup d'entre elles peuvent être abandonnées, ou certaines données à d'autres utilisateurs (leurs processus).
En bref, vous avez déjà décrit le fonctionnement des vérifications de contrôle d'accès pour un processus privilégié. Voici comment les différentes fonctionnalités l'affectent réellement :
La capacité principale ici est CAP_DAC_OVERRIDE
, un processus qui l'a peut "contourner la lecture, l'écriture et l'exécution des vérifications d'autorisation de fichiers". Cela inclut la lecture et l'écriture dans tous les fichiers, ainsi que la lecture, l'écriture et l'accès aux répertoires.
Cela ne s'applique pas réellement à l'exécution de fichiers qui ne sont pas marqués comme exécutables. Le commentaire en generic_permission
(fs/namei.c
), avant que l'accès ne vérifie les fichiers, indique que
Les DAC en lecture/écriture sont toujours remplaçables. Les DAC exécutables peuvent être remplacés lorsqu'au moins un bit exec est défini.
Et le code vérifie qu'il y a au moins un x
bit défini si vous essayez d'exécuter le fichier. Je soupçonne que ce n'est qu'une fonctionnalité pratique, pour éviter d'exécuter accidentellement des fichiers de données aléatoires et d'obtenir des erreurs ou des résultats étranges.
Quoi qu'il en soit, si vous pouvez remplacer les autorisations, vous pouvez simplement créer une copie exécutable et l'exécuter. (Bien que cela puisse faire une différence en théorie pour les fichiers setuid d'un processus était capable de remplacer les autorisations de fichiers (CAP_DAC_OVERRIDE
), mais n'avait pas d'autres fonctionnalités associées (CAP_FSETID
/CAP_FOWNER
/CAP_SETUID
). Mais avoir CAP_DAC_OVERRIDE
permet d'éditer /etc/shadow
et des trucs comme ça, donc c'est à peu près égal à avoir un accès root complet de toute façon.)
Il y a aussi le CAP_DAC_READ_SEARCH
capacité qui permet de lire tous les fichiers et d'accéder à tous les répertoires, mais pas de les exécuter ou d'y écrire ; et CAP_FOWNER
qui permet à un processus de faire des choses qui sont généralement réservées au propriétaire du fichier, comme changer les bits d'autorisation et le groupe de fichiers.
Le remplacement du sticky bit sur les répertoires n'est mentionné que sous CAP_FOWNER
, il semble donc que CAP_DAC_OVERRIDE
ne suffirait pas à l'ignorer. (Cela vous donnerait la permission d'écrire, mais généralement dans les répertoires collants, vous l'avez de toute façon, et +t
limite.)
(Je pense que les appareils spéciaux comptent comme des "fichiers" ici. Au moins generic_permission()
n'a qu'une vérification de type pour les répertoires, mais je n'ai pas vérifié en dehors de cela.)
Bien sûr, il existe encore des situations où même les fonctionnalités ne vous aideront pas à modifier les fichiers :
- quelques fichiers en
/proc
et/sys
, puisqu'il ne s'agit pas vraiment de fichiers réels - SELinux et autres modules de sécurité susceptibles de limiter le root
chattr
immuable+i
et ajoutez seulement+a
drapeaux sur ext2/ext3/ext4, qui arrêtent même root et empêchent également les noms de fichiers, etc.- systèmes de fichiers réseau, où le serveur peut faire son propre contrôle d'accès, par ex.
root_squash
dans NFS mappe la racine à personne - FUSE, qui, je suppose, peut tout faire
- montages en lecture seule
- appareils en lecture seule
C'est exactement ce que vous avez remarqué pour les autorisations par défaut :
-
Lire et écrire :
Par défaut, l'utilisateur root peut accéder à n'importe quel fichier du système. Vous pouvez supprimer cet accès en modifiant les attributs comme expliqué ici :chattr. Ceci est ensuite lié aux capacités. -
Exécuter :
L'utilisateur racine n'a pas d'autorisation d'exécution à moins qu'au moins un des bits d'exécution ne soit défini.
Le myFile.txt
est obtenu par chmod 000 myFile.txt
.
0 no permission
1 execute
2 write
3 execute + write
4 read
5 read + execute
6 read + write
7 all
---------
signifie qu'il n'y a pas d'autorisation pour l'utilisateur, le groupe et autre.
L'utilisateur root dispose d'un accès illimité possibilité de modifier ce fichier. La lecture/écriture est accordée. Pour exécuter ce fichier, l'utilisateur root doit quand même le rendre exécutable. (chmod 100 , 010 ou 001)