
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 /root
no se pueden leer por razones de seguridad, pero aún puede "ver" que están ahí ls
(simplemente no puede leerlos). Por ejemplo, .history
está configurado -rw-------
pero .login
es -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 ( /root
se puede leer).
FreeBSD /root
no 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 /root
en 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 /root
legible 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 ~root
se pudiera escribir, cualquier usuario podría agregar su clave SSH ~root/.ssh/authorized_keys
y luego tener acceso de root simplemente a través de ssh root@some-host
.
Si ~root
es "simplemente" legible, aún tendrá acceso al archivo root
del 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 root
de .bash_history
, tiene acceso a cualquier dato confidencial root
que alguna vez haya ingresado de esa manera, accidentalmente o no.
Claro, existen mitigaciones para estos problemas, como no permitir root
el 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 ~root
0700 es otra capa en esa cebolla de seguridad. Si no quieres llorar, no peles la cebolla más de lo necesario.