¿Puede el súper usuario escribir en archivos de solo lectura?

Me topé con un comportamiento de permiso sorprendente (para mí) en FreeBSD. Digamos que estoy operando como usuario no root . Creo un archivo, configuro su permiso en solo lectura y luego intento escribir en él:

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

Hasta ahora tan bueno. Ahora hago lo mismo que root y escribe en el archivo:

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

¿Es un error o un comportamiento previsto? ¿Puedo suponer con seguridad que esto funcionaría en cualquier Unix y Linux?

files permissions root

— arrowd
fuente

Cualquier usuario con CAP_DAC_OVERRIDEpuede hacer esto. En casi todos los sistemas Linux, esto significa que root puede hacer esto, por lo que es intencional. No puedo hablar por la parte de FreeBSD, pero me imagino que tienen una configuración similar.

— Bratchley

La razón por la que la raíz necesita SIEMPRE poder escribir en un archivo es porque en los sistemas de archivos Unix tradicionales (ext4, zfs, etc.) los permisos de archivo son parte del archivo. Entonces, si la raíz no puede escribir en un archivo, NADIE puede volver a escribir el archivo de solo lectura porque chmodno puede escribir en el archivo.

— slebetman

@slebetman No necesita tener acceso de escritura a un archivo para actualizar los permisos. Solo inténtalo touch somefile; chmod 0000 somefile; chmod 0644 somefilecomo un usuario normal.

— user253751

@immibis: Que tienes. Root necesita poder cambiar los permisos de los archivos que no posee

— slebetman

@slebetman Sí ... pero estabas hablando de cambiar permisos en archivos en los que no puedes escribir, no de cambiar permisos en archivos que no tienes.

— user253751

Respuestas:

Es normal rootpoder anular los permisos de esta manera.

Otro ejemplo es rootpoder leer un archivo sin acceso de lectura:

$ 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

Algunos sistemas tienen el concepto de archivos inmutables . Por ejemplo, en 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.

Ahora incluso rootno puedo escribir en el archivo. Pero, por supuesto, rootpuede eliminar la bandera:

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

Con FreeBSD puede ir un paso más allá y establecer un indicador de kernel para evitar rooteliminar el indicador:

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

Ahora nadie, ni siquiera rootpuede cambiar este archivo.

(El sistema necesita reiniciarse para reducir el nivel de seguridad).

— Stephen Harris
fuente

¿Cómo se requiere reiniciar una medida de seguridad efectiva? Además, si root es root y puede hacer cualquier cosa, ¿por qué molestarse en tratar de evitar que root haga lo que root quiere?

— gato

En un sistema seguro, root no es como Dios. FreeBSD securelevel es un pequeño intento de hacer root menos a Dios. Securelevel se puede establecer como predeterminado en 1 en la configuración del sistema para que permanezca activo incluso después de reiniciar. Entonces, necesitaría acceso a la consola y modo de usuario único y eso es muy evidente. Hay un ensayo completo sobre la seguridad de Unix que es demasiado para un campo de comentarios de SE, pero estamos tratando de pasar de un modelo de 'root tiene acceso completo' a algo más matizado. Intentamos hacer cumplir siempre que sea posible (por ejemplo, nivel seguro) y detectar dónde no (reiniciar evidencia, pistas de auditoría).

— Stephen Harris

FWIW, en Linux chattr +i tstestablece un atributo inmutable .

— Ruslan

Sí, esto es muy normal. root no tiene límites en lectura / escritura (con muy poca excepción), porque él es la raíz.

— Ipor Sircer
fuente