¿Por qué es malo tener archivos de escritura raíz en un directorio que no es propiedad de la raíz?

Esto surgió en un comentario a otra pregunta y me encantaría que alguien me explicara los motivos.

Sugerí que Apache registrara los errores de un VHost determinado en el directorio de inicio de un usuario. Esto fue derribado porque era inseguro. ¿Por qué?

Pedí una aclaración en un comentario de respuesta, pero todo lo que obtuve fue que no es seguro tener la escritura raíz en una carpeta que no es propiedad de la raíz. De nuevo, ¿alguien podría explicarlo?

Gracias,

Bart

linux security permissions

— Bart B
fuente

¿Qué hace Apache ejecutándose como root? ¡El principio del privilegio mínimo grita contra eso!

— Jonathan Leffler

Apache se está ejecutando como www, pero se está iniciando como root para que pueda unirse al puerto 80 como es la norma. Aparentemente, también se registra como raíz.

— Bart B

Debido a que un usuario malintencionado puede intentar señalar maliciosamente que el archivo rootestá escribiendo en una ubicación diferente . Esto no es tan simple, pero realmente posible.

Como ejemplo, si un usuario encontrara la manera de hacer un enlace simbólico desde el supuesto registro de Apache a, por ejemplo, / etc / shadow , de repente tendrá un sistema inutilizable. Apache ( root) sobrescribiría las credenciales de sus usuarios haciendo que el sistema sea defectuoso.

ln -s /etc/shadow /home/eviluser/access.log

Si el usuario no puede escribir el archivo access.log , puede ser difícil secuestrarlo, ¡pero evitar la posibilidad es mejor!

Una posibilidad podría ser usar logrotate para hacer el trabajo , creando el enlace a un archivo que aún no existe, pero ese logrotate se sobrescribirá tan pronto como crezcan los registros:

ln -s /etc/shadow /home/eviluser/access.log.1

Nota :

El método de enlace simbólico es solo uno de los posibles ataques, dado como prueba de concepto.

La seguridad debe hacerse con la mente de la Lista Blanca , no en la lista negra de lo que sabemos que es un problema.

— AlberT
fuente

¿Hay alguna manera de establecer permisos para que solo puedan leer el archivo y no eliminarlo, editarlo ni hacer nada más (como chown, chmod, etc.)?

— Joshua

¡debería hacer esta operación en todos los archivos de destino posibles! este archivo grabable es el que le gusta, no el enlace en sí que pertenece al atacante cuando lo creó.

— drAlberT

@Joshua: chown solo se puede realizar por root. El propietario del archivo puede realizar chmod. IIRC, el cambio de nombre lo puede realizar el propietario del directorio. Como menciona AlberT, cualquiera que pueda escribir en el directorio puede crear un enlace antes de que el usuario cree el archivo.

— atk

@atk: Además, el propietario del directorio generalmente puede eliminar archivos (a menos que se establezca el +tbit fijo), incluso si no tienen permiso de escritura en los archivos mismos (porque unlink () es una escritura en el directorio, no el archivo). Incluso si la raíz crea el archivo con anticipación, el propietario del directorio aún podría eliminarlo y reemplazarlo con un enlace simbólico a otra cosa.

— James Sneeringer

Si eviluser puede escribir en / home / eviluser (o puede cambiar los permisos en el directorio, ellos lo poseen, IOW), entonces no importa cuáles sean los permisos en access.log; el malusuario puede (re) mover el archivo y colocar su enlace simbólico en su lugar. Otra pregunta es si el software presta atención a lo que abre.

— Jonathan Leffler

El principio general de no hacer que los procesos escriban en un directorio que no es de su propiedad o en el que no confía es bueno. Pero en este caso particular, es razonable confiar en que el código de Apache abre el registro con O_NOFOLLOWetc: iniciar sesión en el directorio de inicio de un usuario es una configuración común.

— billar
fuente