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 root
ou non. Dans la pratique, a root
gé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 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 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_OVERRIDE
permet d' éditer /etc/shadow
et 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_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
cela 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
ce 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 +t
cela 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
/proc
et /sys
, comme 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 des +a
drapeaux 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_squash
dans NFS mappe root à personne
- FUSE, qui je suppose pourrait tout faire
- montures en lecture seule
- périphériques en lecture seule
capabilities(7)
page de manuel - pensez à déposer un rapport de bogue!