GNU/Linux >> Tutoriales Linux >  >> Linux

¿Por qué se aplica la seguridad raíz pero $HOME normalmente no está protegido?

No estoy de acuerdo con las respuestas que dicen que la antigüedad del modelo de seguridad de Unix o el entorno en el que se desarrolló tienen la culpa. No creo que ese sea el caso porque existen mecanismos para manejar esto.

El sistema de permisos de raíz tiene sentido, pero en los sistemas de escritorio parece que protege los datos incorrectos.

Los permisos de superusuario existen para proteger el sistema de sus usuarios. Los permisos de las cuentas de usuario están ahí para proteger la cuenta de otras cuentas no root.

Al ejecutar un programa, le otorga permisos para hacer cosas con su UID. Dado que su UID tiene acceso completo a su directorio de inicio, le ha dado transitivamente al programa el mismo acceso. Así como el superusuario tiene acceso para realizar cambios en los archivos del sistema que necesitan protección contra el comportamiento malicioso (contraseñas, configuración, archivos binarios), es posible que tenga datos en su directorio de inicio que necesiten el mismo tipo de protección.

El principio de privilegio mínimo dice que no debe dar más acceso del que es absolutamente necesario. El proceso de decisión para ejecutar cualquier programa debe ser el mismo con respecto a sus archivos que a los archivos del sistema. Si no le da un código en el que no confía el uso sin restricciones de la cuenta de superusuario con el fin de proteger el sistema, no se le debe dar el uso sin restricciones de su cuenta con el fin de proteger sus datos.

¿No hay forma de evitar que ocurra un código malicioso en $HOME? ¿Y por qué a nadie le importa?

Unix no ofrece permisos tan granulares por la misma razón por la que no hay un protector de hoja alrededor del comando rm:los permisos no están ahí para proteger a los usuarios de sí mismos.

La forma de evitar que el código malicioso dañe los archivos en su directorio de inicio es no ejecutarlo usando su cuenta. Cree un usuario independiente que no tenga ningún permiso especial y ejecute el código con ese UID hasta que haya determinado si puede o no confiar en él.

Hay otras formas de hacer esto, como cárceles chroot, pero configurarlas requiere más trabajo y escapar de ellas ya no es el desafío que alguna vez fue.


Porque el modelo de seguridad basado en UNIX tiene 50 años.

UNIX es la base de los sistemas operativos más extendidos, e incluso la gran excepción de Windows se ha visto influenciado por él más de lo que parece. Proviene de una época en que las computadoras eran máquinas grandes, caras y lentas utilizadas exclusivamente por especialistas arcanos.

En ese momento, los usuarios simplemente no tenían recopilaciones extensas de datos personales en ninguno computadora, no su servidor universitario, no su computadora personal (y ciertamente no su teléfono móvil). Los datos que variaban de un usuario a otro solían ser datos de entrada y salida de procesos informáticos científicos; perderlos podría constituir una pérdida, pero en gran medida podría compensarse volviéndolos a calcular, ciertamente nada parecido a las consecuencias de las fugas de datos actuales.

Nadie habría tenido su diario, información bancaria o fotos de desnudos en una computadora, así que protegerlos del acceso malicioso no era algo que tuviera una alta prioridad; de hecho, la mayoría de los estudiantes universitarios en los años 70 probablemente habrían estado emocionados si otros mostraron interés en sus datos de investigación. Por lo tanto, la prevención de la pérdida de datos se consideró la máxima prioridad en la seguridad informática, y eso se garantiza adecuadamente mediante copias de seguridad periódicas en lugar de control de acceso.


Esta es una observación muy astuta. Sí, el malware que se ejecuta como su usuario puede dañar/destruir/modificar datos en su directorio de inicio. Sí, la separación de usuarios en sistemas de un solo usuario es menos útil que en servidores. Sin embargo, todavía hay algunas cosas que solo el usuario root (o equivalente) puede hacer:

  • Instalar un rootkit en el kernel.
  • Modifique el gestor de arranque para que contenga una puerta trasera temprana para la persistencia.
  • Borra todos los bloques del disco duro, haciendo que tus datos sean irrecuperables.

Honestamente, encuentro que la separación de privilegios en las estaciones de trabajo es más útil para proteger la estación de trabajo de su mayor enemigo:yo. Hace que sea más difícil arruinar y romper mi sistema.

Además, siempre puede configurar un trabajo cron como raíz que haga una copia de seguridad de su directorio de inicio (con, por ejemplo, rsnapshot ) y lo almacena de manera que su usuario no pueda escribirlo. Eso sería cierto nivel de protección en la situación que describe.

xkcd obligatorio


Linux
  1. Usuario no raíz predeterminado de Kali

  2. Cómo crear usuarios casi equivalentes a root pero no usuarios idénticos a root en Linux

  3. ¿Por qué se considera seguro instalar algo como usuario no root en entornos Linux?

  4. ¿Por qué proteger el kernel de Linux del usuario root?

  5. ¿Por qué usar innodb_file_per_table?

Espacio reservado para la raíz en un sistema de archivos:¿por qué?

¿Deshabilitar el shell de usuario por razones de seguridad?

¿Diferencia entre el usuario de Sudo y el usuario raíz?

¿Por qué no se puede encontrar Read /run/user/1000/gvfs aunque se esté ejecutando como raíz?

Instalar WordPress en una cuenta de usuario como root

Cómo limitar el usuario root en CentOS