Comment les autorisations de fichiers fonctionnent-elles pour l'utilisateur "root"?

Question

J'ai le fichier suivant:

---------- 1 Steve Steve 341 2017-12-21 01:51 myFile.txt

J'ai basculé l'utilisateur sur root dans le terminal et j'ai remarqué les comportements suivants:

Je peux lire ce fichier et y écrire.
Je ne peux pas exécuter ce fichier.
Si je mets le bit x dans les autorisations utilisateur (---x------) ou les autorisations de groupe (------x---) ou les autres autorisations (---------x) du fichier, alors je serais en mesure d'exécuter ce fichier.

Quelqu'un peut-il m'expliquer ou me diriger vers un didacticiel qui explique toutes les règles qui s'appliquent lorsque l'utilisateur root traite des fichiers et des répertoires?

ilkkachu · Accepted Answer

L'accès privilégié aux fichiers et aux répertoires est en fait déterminé par les capacités, et pas seulement en étant root ou non. En pratique, root possède généralement toutes les capacités possibles, mais il existe des situations où tout/plusieurs d'entre elles peuvent être supprimé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 capacités l'affectent réellement:

La principale la capacité ici est CAP_DAC_OVERRIDE , un processus qui en est capable "peut contourner la lecture, l'écriture et l'exécution des vérifications des autorisations". Cela inclut la lecture et l'écriture dans tous les fichiers, ainsi que la lecture, l'écriture et l'accès aux répertoires.

Il ne s'applique pas réellement à l'exécution de fichiers qui ne sont pas marqués comme exécutables. commentaire dans generic_permission (fs/namei.c), Avant que l'accès ne vérifie les fichiers, dit que

Les DAC en lecture/écriture sont toujours remplaçables. Les DAC exécutables sont remplaçables lorsqu'il y a au moins un bit d'exécution 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 faire une copie exécutable et l'exécuter. _{(Bien que cela puisse faire une différence en théorie, les fichiers setuid d'un processus étaient capables de remplacer les autorisations de fichiers (CAP_DAC_OVERRIDE), Mais n'avaient pas d'autres capacités connexes (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 la capacité CAP_DAC_READ_SEARCH 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 uniquement au propriétaire du fichier, comme changer les bits d'autorisation et le groupe de fichiers.

Remplacer le bit collant 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 une autorisation d'écriture, mais généralement dans les répertoires collants, vous en avez quand même, et +t Le limite.)

_{(Je pense que les périphériques spéciaux comptent ici comme des "fichiers". 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 capacités ne vous aideront pas à modifier les fichiers:

certains fichiers dans /proc et /sys, car ce ne sont pas vraiment des fichiers réels
SELinux et autres modules de sécurité qui pourraient limiter root
chattr immuable +i et n'ajoute que +a drapeaux sur ext2/ext3/ext4, tous deux arrêtent même root, et empêchent également les renommages de fichiers, etc. .
systèmes de fichiers réseau, où le serveur peut effectuer son propre contrôle d'accès, par ex. root_squash Dans NFS mappe la racine à personne
Fuse, qui je suppose pourrait tout faire
montures en lecture seule
périphériques en lecture seule

Kevin Lemaire · Answer

C'est exactement comme vous l'avez remarqué pour les autorisations par défaut:

Lecture et écriture:
Par défaut, l'utilisateur root peut accéder à n'importe quel fichier du système. Vous pouvez supprimer cet accès en changeant les attributs comme expliqué ici: chattr . Ceci est ensuite lié aux capacités.
Exécuter:
L'utilisateur root n'a pas d'autorisation d'exécution sauf si au moins un des bits d'exécution est défini.

GAD3R · Answer

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 aucune autorisation pour l'utilisateur, le groupe et autres.

L'utilisateur root a une capacité illimitée pour modifier ce fichier. La lecture/écriture est accordée. Pour exécuter ce fichier, l'utilisateur root doit tout de même le rendre exécutable. (chmod 100, 010 ou 001)

Barmar · Answer

Le mode d'exécution est traité un peu différemment des autres modes.

Les autorisations de lecture et d'écriture sont utilisées pour appliquer les politiques de sécurité. L'utilisateur root est généralement à l'abri des restrictions de sécurité (il y a quelques exceptions, comme les fichiers immuables, et des fonctionnalités modernes comme les capacités ont rendu cela plus fin), c'est pourquoi un autre nom pour ce compte est le "superutilisateur" ".

L'autorisation d'exécution est plus un mode consultatif, distinguant si le fichier est destiné pour être exécutable ou est juste des données. Pour cette raison, même l'utilisateur root s'y conforme - il est inutile d'exécuter un fichier de données. Si aucune des autorisations d'exécution n'est définie, root ne peut pas exécuter le fichier; si l'un d'eux est défini, il le peut. Bien sûr, puisque root a également l'autorisation de modifier les autorisations de n'importe quel fichier, le compte peut rendre un fichier exécutable s'il le souhaite (sauf si le système de fichiers est en lecture seule).

BTW, les scripts sont un cas intéressant à cet égard. Les scripts sont des fichiers de données pour l'interprète concerné. Si le script a un #! line, vous pouvez l'exécuter en tant que programme - l'interpréteur nommé dans le Shebang est exécuté avec le nom de fichier du script comme argument. Mais cela ne sera fait que si l'autorisation d'exécution est définie. D'un autre côté, vous pouvez simplement exécuter l'interpréteur directement, par ex. /bin/bash scriptname. Les interprètes ne se soucient que s'ils peuvent lire le fichier, ils ne vérifient pas les autorisations d'exécution.

Hassan Sohail · Answer

Permettez-moi de vous expliquer théoriquement.

l'utilisateur root est le roi du système d'exploitation.

Si un fichier ou un répertoire dispose d'une autorisation comme X pour exécuter mais rien d'autre et que quelqu'un comme l'utilisateur Steve possède le fichier, root peut également exécuter le fichier.

Rappelez-vous toujours que sous Linux, root peut tout faire, il n'y a aucune restriction sur root.