Le super utilisateur peut-il écrire dans des fichiers en lecture seule?

Je suis tombé sur un comportement de permission surprenant (pour moi) sur FreeBSD. Supposons que j'opère en tant qu'utilisateur non root . Je crée un fichier, définit son autorisation en lecture seule, puis j'essaye d'y écrire:

$ touch f
$ chmod 400 f
$ ls -l f
-r--------  1 user  wheel  f
$ echo a >> t
t: Permission denied.

Jusqu'ici tout va bien. Maintenant, je fais la même chose que root et il écrit dans le fichier:

# ls -l f2
-r--------  1 root  wheel  f2
# echo a >> f2
# echo $?
0

Est-ce un bug ou un comportement voulu? Puis-je supposer en toute sécurité que cela fonctionnerait ainsi sur n'importe quel Unix et Linux?

files permissions root

— arrowd
source

N'importe quel utilisateur CAP_DAC_OVERRIDEpeut le faire. Sur presque tous les systèmes Linux, cela signifie que root peut le faire, c'est donc intentionnel. Je ne peux pas parler pour la partie FreeBSD mais j'imagine qu'ils ont une configuration similaire.

— Bratchley

La raison pour laquelle root doit TOUJOURS pouvoir écrire dans un fichier est parce que sur les systèmes de fichiers Unix traditionnels (ext4, zfs etc.), les autorisations de fichiers font partie du fichier. Donc, si root ne peut pas écrire dans un fichier, NOBODY peut rendre le fichier en lecture seule à nouveau accessible en écriture car chmodil ne peut pas écrire dans le fichier.

— slebetman

@slebetman Vous n'avez pas besoin d'avoir un accès en écriture à un fichier pour mettre à jour les autorisations. Essayez simplement en touch somefile; chmod 0000 somefile; chmod 0644 somefiletant qu'utilisateur normal.

— user253751

@immibis: que vous possédez. Root doit pouvoir modifier les autorisations sur les fichiers qu'il ne possède pas

— slebetman

@slebetman Ouais ... mais vous parliez de changer les permissions sur les fichiers que vous ne pouvez pas écrire, pas de changer les permissions sur les fichiers que vous ne possédez pas.

— user253751

Réponses:

Il est normal de rootpouvoir remplacer les autorisations de cette manière.

Un autre exemple est la rootpossibilité de lire un fichier sans accès en lecture:

$ echo hello > tst
$ chmod 0 tst
$ ls -l tst
---------- 1 sweh sweh 6 Aug 16 15:46 tst
$ cat tst
cat: tst: Permission denied
$ sudo cat tst
hello

Certains systèmes ont le concept de fichiers immuables . par exemple sur FreeBSD:

# ls -l tst
-rw-r--r--  1 sweh  sweh  6 Aug 16 15:50 tst
# chflags simmutable tst
# echo there >> tst
tst: Operation not permitted.

Maintenant, même rootne peut pas écrire dans le fichier. Mais, bien sûr, rootpeut supprimer le drapeau:

# chflags nosimmutable tst
# echo there >> tst
# cat tst
hello
there

Avec FreeBSD, vous pouvez aller plus loin et définir un indicateur de noyau pour éviter rootde supprimer l'indicateur:

# chflags simmutable tst
# sysctl kern.securelevel=1
kern.securelevel: -1 -> 1
# chflags nosimmutable tst
chflags: tst: Operation not permitted

Maintenant, personne, même pas, ne rootpeut modifier ce fichier.

(Le système doit être redémarré pour réduire le niveau de sécurité).

— Stephen Harris
source

En quoi le redémarrage est-il une mesure de sécurité efficace? De plus, si root est root et peut faire n'importe quoi, pourquoi s'embêter à essayer d'empêcher root de faire ce que root veut?

— chat

Sur un système sécurisé, root n'est pas semblable à Dieu. FreeBSD securelevel est une petite tentative pour rendre root moins proche de Dieu. Securelevel peut être défini par défaut sur 1 dans la configuration du système afin qu'il reste actif même après un redémarrage. Il aurait donc besoin d'un accès à la console et d'un mode mono-utilisateur, ce qui est très évident. Il y a tout un essai sur la sécurité Unix qui est beaucoup trop pour un champ de commentaire SE, mais nous essayons de passer d'un modèle `` root a tout accès '' à quelque chose de plus nuancé. Nous essayons de faire respecter les règles dans la mesure du possible (par exemple, le niveau de sécurité) et de détecter les cas où elles ne le sont pas (redémarrage des preuves, pistes d'audit).

— Stephen Harris

FWIW, dans Linux chattr +i tstdéfinit l' attribut immuable .

— Ruslan

Oui, c'est très normal. root n'a pas de limites en lecture / écriture (avec très peu d'exceptions), car il est le root.

— Ipor Sircer
source