¿Ejemplos de por qué un directorio /raíz legible mundialmente es malo?

¿Ejemplos de por qué un directorio /raíz legible mundialmente es malo?

Para agregar peso a una discusión que estoy teniendo, estoy tratando de encontrar ejemplos concretos de por qué tener el directorio /root legible en todo el mundo es malo desde el punto de vista de la seguridad.

He encontrado muchos casos en línea de personas que repiten el mantra de que realmente no es bueno darle a /root, digamos, 755 permanentes, pero sin más evidencia.

¿Podría alguien proporcionarnos un escenario en el que la seguridad de un sistema pueda verse comprometida si este es el caso? Cuanto menos ideado, mejor; entonces, por ejemplo, ¿cómo puede sufrir un sistema Centos recién instalado si /root tiene 755 permisos?

EDITAR: gracias por las respuestas, pero hasta ahora no hay ejemplos concretos. Para decirlo de otra manera, ¿cómo podrías utilizar el hecho de que /root esté visible para comprometer el sistema? ¿Hay algún ejemplo de programas que se instalan y se supone que /root no es accesible para todos?

EDITAR 2: creo que el consenso hasta ahora es que no es un gran riesgo para la seguridad, aparte de que alguien no verifique los permisos y use el directorio como si fuera privado para root.

Respuesta1

Esto no es fundamentalmente diferente a la recomendación de evitar que otros usuarios lean el directorio de inicio de otro usuario.

Si el valor predeterminado es legible en todo el mundo, habrá una ventana de oportunidad cuando guarde un archivo nuevo que desee mantener privado. Siempre existe la posibilidad de que alguien pueda copiarlo antes que usted chmod go-r.

Respuesta2

Fundamentalmente creo que todo se reduce a una elección hecha por los desarrolladores principales y nada más que eso. ¿Por qué? Porque de forma predeterminada, no debería haber casi nada de valor para nadie en /root. Nadie debería iniciar sesión como usuario root para cuestiones generales.

Por ejemplo, en FreeBSD todos pueden leer /root. Algunos archivos que contiene /rootno se pueden leer por razones de seguridad, pero aún puede "ver" que están ahí ls(simplemente no puede leerlos). Por ejemplo, .historyestá configurado -rw-------pero .logines -rw-r--r--.

FreeBSD tiene un enfoque de seguridad ligeramente diferente al de Linux. Históricamente, FreeBSD ha sido para servidores y, si bien se puede ejecutar como escritorio, realmente es mejor (por defecto) como servidor.

Personalmente, no veo nada malo en esta configuración ( /rootse puede leer).

FreeBSD /rootno tiene casi nada excepto configuraciones. El correo debe reenviarse a un usuario real. Nadie debería iniciar sesión como usuario root. La cuenta sólo debe usarse para la instalación y configuración de software, así como para tareas de mantenimiento. Aparte de algunos archivos sensibles a la seguridad (como .history), en mi opinión, no hay nada que ocultar /rooten FreeBSD.

Para leer más sobre esto, pruebe elSección del manual de FreeBSD sobre seguridad. No vi nada sobre su elección para que sea /rootlegible en un escaneo rápido, pero hay mucha información allí.

Respuesta3

Quizás un administrador descuidado busque contraseñas fáciles de descifrar y deje el resultado por ahí (puede que esta no sea la invocación correcta, pero se entiende la idea):

# john-the-ripper /etc/shadow > ~/cracked-passwords.txt

Respuesta4

Si ~rootse pudiera escribir, cualquier usuario podría agregar su clave SSH ~root/.ssh/authorized_keysy luego tener acceso de root simplemente a través de ssh root@some-host.

Si ~rootes "simplemente" legible, aún tendrá acceso al archivo rootdel usuario .bash_history, que podría contener contraseñas u otras credenciales ingresadas en la línea de comando. O ingresado o pegado accidentalmente en un símbolo del sistema.

Claro, se supone que no debes pasar datos seguros en la línea de comando, pero esa advertencia generalmente se trata como de bajo riesgo porque es arriesgado detectarla en vuelo, y otros usuarios no deberían poder leer tus variables de entorno de todos modos. . Si tiene acceso al archivo rootde .bash_history, tiene acceso a cualquier dato confidencial rootque alguna vez haya ingresado de esa manera, accidentalmente o no.

Claro, existen mitigaciones para estos problemas, como no permitir rootel inicio de sesión en SSH, incluso con autenticación de clave. O deshabilitar el historial del shell. O ser estudioso a la hora de limpiarlo. Pero estos sonmitigaciones; son capas en la cebolla de seguridad.

Ser ~root0700 es otra capa en esa cebolla de seguridad. Si no quieres llorar, no peles la cebolla más de lo necesario.

información relacionada