GNU/Linux >> Tutoriels Linux >  >> Linux

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

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)


Linux
  1. Comment configurer les privilèges Sudo pour l'utilisateur sous Linux

  2. Linux - Comment définir les autorisations de fichier par défaut pour tous les dossiers/fichiers d'un répertoire ?

  3. Comment fonctionnent les composants internes de Sudo ?

  4. Si je modifie les autorisations sur un fichier tar, cela s'appliquera-t-il aux fichiers qu'il contient ?

  5. Comment faire en sorte que ssh se connecte avec le bon utilisateur ?

Comment modifier récursivement les autorisations de fichiers sous Linux

Comment décompresser les fichiers gz sous Linux

Comment vérifier les fichiers volumineux dans la console

Comment puis-je corriger les autorisations de mes fichiers ?

Comment désactiver la connexion SSH pour l'utilisateur root sous Linux ?

Comment trouver le fichier .pid pour un processus donné