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

J'ai le fichier suivant:

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

J'ai basculé l'utilisateur sur rootdans 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 xbit dans les autorisations utilisateur ( ---x------) ou les autorisations groupe ( ------x---) ou les autres autorisations (---------x ) du fichier, 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' rootutilisateur traite des fichiers et des répertoires?

L'accès privilégié aux fichiers et répertoires est en fait déterminé par les capacités, et pas seulement par l'être rootou non. Dans la pratique, a rootgénéralement toutes les capacités possibles, mais il y a des situations où tout / plusieurs d'entre eux pourraient être abandonnés, ou certains donnés à 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 capacité ici estCAP_DAC_OVERRIDE un processus qui peut "contourner la lecture, l’écriture et l’exécution de vérifications d’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. Le commentaire entregeneric_permission ( fs/namei.c), avant la vérification d'accès pour 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 xbit 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 dans la théorie des fichiers suid d'un processus était capable d'autorisations de fichiers remplaçant ( CAP_DAC_OVERRIDE), mais n'a pas eu d' autres capacités connexes ( CAP_FSETID/ CAP_FOWNER/ CAP_SETUID). Mais avoir CAP_DAC_OVERRIDEpermet d' éditer /etc/shadowet d'autres choses comme ça, il est à peu près égale d'avoir juste un accès root complet de toute façon.)}

Il y a aussi la CAP_DAC_READ_SEARCHcapacité 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_FOWNERcela 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_OVERRIDEce ne serait pas suffisant pour l'ignorer. (Cela vous donnerait une autorisation d'écriture, mais généralement dans les répertoires collants, vous en avez de toute façon et +tcela la limite.)

_{(Je pense que les périphériques spéciaux comptent comme des "fichiers" ici. Au moins, il generic_permission()n'y 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:

• certains fichiers /procet /sys, comme ce ne sont pas vraiment des fichiers réels
• SELinux et autres modules de sécurité qui pourraient limiter root
• chattrimmuable +iet n'ajoute que des +adrapeaux sur ext2 / ext3 / ext4, qui arrêtent même root, et empêchent également les renommages de fichiers, etc.
• systèmes de fichiers réseau, où le serveur peut faire son propre contrôle d'accès, par exemple root_squashdans NFS mappe root à personne
• FUSE, qui je suppose pourrait tout faire
• montures en lecture seule
• périphériques en lecture seule

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

• Lire é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 des attributs comme l'expliquer 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.

Le myFile.txtest 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 de 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)

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é. leroot utilisateur 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 davantage un mode consultatif, distinguant si le fichier est destiné à être exécutable ou s'il s'agit uniquement de 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 une #!ligne, 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 exemple /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.

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.