¿Por qué chroot se considera inseguro?


12

He estado jugando con CentOS box durante un par de años. Así que estoy bastante cómodo con la terminal. Sin embargo, leí muchas publicaciones de blog alegando que Chroot es inseguro y que la cantidad de esas publicaciones asusta. ¿Es realmente así? ¿Por qué?

Utilizo chroot para bloquear a los usuarios de solo SFTP en un contexto específico, sin ningún tipo de shell o comandos. Entonces, ¿cuál es el problema de seguridad con eso?

La pregunta está exiliada de StackOverflow .


1
Primero: la pregunta no se ha cerrado / migrado en Stack Overflow , pero es claramente OT allí. La acción apropiada sería esperar hasta que se migre o marcarlo y pedirle a un mod que lo haga, no publicarlo en otro sitio. Pero segundo: si "juegas con CentOS", también te equivocas aquí. Este sitio es para administradores de sistemas profesionales, no para aficionados. Consulte nuestras preguntas frecuentes .
Sven

2
@SvenW gracias, tendré en cuenta tu consejo para el futuro. Y sobre el 'segundo', bueno, lo siento, pero no veo cómo mi pregunta viola las preguntas frecuentes. Después de leerlo dos veces, puedo decir que no. A partir de la frase "jugar con CentOS", bueno, pensé que era bastante obvio que los usuarios de chrooting y solo SFTP y que se los considerara acerca de la seguridad es un tema muy serio del que los profesionales pueden beneficiarse también en su empresa o en cualquier otro " ambientes profesionales ".
Aleksandr Makov

1
@sven en caso de que no lo supieras, SF se ha eliminado de la lista de migración de SO debido a cuántas preguntas malas nos envían.
MDMarra

Respuestas:


9

Porque, en la mayoría de los casos, un proceso raíz puede salir fácilmente del chroot. Esto es por diseño, ya que chroot nunca fue pensado como un dispositivo de seguridad.

Alan Cox reprendió a un desarrollador que envió un parche de kernel para "arreglar" este comportamiento, alegando que Chroot ha sido abusado como un dispositivo de seguridad, pero que nunca tuvo la intención de serlo.


¡Perfecto! Muchas gracias. Así que este es el asunto de los procesos raíz que están presentes en la raíz o son accesibles desde ella. Gracias.
Aleksandr Makov

Acabo de verificar que ejecutando el programa C que se muestra en unixwiz.net/techtips/mirror/chroot-break.html como root en Linux 4.18 es posible escapar del chroot.
pts

Así que no reparta privilegios de root. Incluso los sistemas "seguros" regulares tienen cuentas raíz.
Cees Timmerman

6

Conozco al menos un ejemplo de por qué se considera inseguro. Un entorno chroot /procno está aislado, por lo que es bastante fácil acceder a recursos que no pertenecen a procesos iniciados en su chroot.

El uso de un entorno fragmentado para SFTP está bien y mejora significativamente el nivel de seguridad. Simplemente no abuses de ella como virtualización basada en contenedores, que proporciona más niveles de seguridad. En esto, subrayo lo que hay en la respuesta de @ MDMarra.


Gracias. Entonces, ahora queda más claro, que el chroot en sí mismo no es pobre en seguridad, sino que su seguridad depende del entorno en el que está configurado.
Aleksandr Makov

En realidad, chroot no es pobre en seguridad, porque nunca fue pensado para ser un dispositivo de seguridad. Estaba destinado a ser una herramienta de desarrollo para ejecutar múltiples versiones de los mismos binarios en paralelo con diferentes dependencias. No es un sustituto para asegurar adecuadamente los servicios, aunque puede ser útil en ciertas circunstancias siempre que comprenda qué es y qué no es.
MDMarra

MDMarra, básicamente, chroot no está destinado a ser utilizado para capturar conexiones SSH. Entonces, en su opinión, ¿le parece "poco profesional" cambiar las conexiones SSH entrantes? ¿Debería evitarlo?
Aleksandr Makov

No, no necesariamente, solo date cuenta de que cualquier exploit que podría conducir a la elevación de privilegios o cualquier proceso que se ejecute como root en el chroot sería trivial de romper. Ciertamente puede ser una pieza en el rompecabezas, pero no debería ser todo.
MDMarra
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.