CHROOT y Seguridad - Seguridad (o inseguridad, según se mire)

En principio, un entorno CHROOT es bastante seguro, al menos siempre y cuando:

1. Se tenga un sistema operativo reciente y que se suponga sin bugs conocidos.
2. Se eviten los comandos SUID como la peste. Ello evita su explotación y el posterior uso de los comandos MKNOD, MOUNT, UADMIN, acceso directo a la memoria del kernel, etc. En general, habría que modificar el kernel para no permitir el uso de las llamadas "chroot", "mknod", "chmod" y "mkdir" (para no crear entradas "/dev" falsas, por ejemplo), así como el acceso a dispositivos vía "/dev" o "/device".
3. Sea imposible hacerse superusuario una vez dentro de un CHROOT. Si eres "root", el CHROOT se puede saltar de forma trivial.
4. No se importen ficheros abiertos desde fuera del CHROOT.
5. El directorio actual del proceso esté dentro del CHROOT.
6. No se replique nada innecesario, especialmente directorios como "/dev", "/proc", etc. "/proc", por ejemplo, permite acceder al directorio raíz de cada proceso que corre en el sistema (bajo Linux). De hecho, bajo linux, "/proc" es toda una interfaz al kernel. Hay que evitarla a toda costa. Lo mismo para "/procfs" y "/kernfs" sobre NetBSD/FreeBSD.
7. Los servicios accesibles no sean "explotables": léase SYSLOG flood y similares. Ojo con dejar el AT, CRON y CRONTAB accesibles.
8. Que no se permitan cargar módulos en el Kernel.
9. Si es posible montar particiones, hacerlas "sólo lectura". En las que se pueda escribir, usar el modo "NOSUID".

En todo caso un entorno CHROOT debe considerarse sólo una barrera más, de cara a la seguridad, no una forma de crear máquinas virtuales. Y, por supuesto, no debe ser el único obstáculo contra intrusiones.

Una interesante forma de salir de un chroot:

mkdir("foo",S_IRUSR|S_IXUSR);
chroot("foo");
chdir("..");


Esto explica, entre otras cosas, por qué:

• No debe ser posible hacerse superusuario.
• Hay que tener cuidado y hacer que el directorio actual del proceso esté dentro del CHROOT.