chrootes una operación en sistemas operativos Unix y similares que cambia el directorio raíz aparente para el proceso que se está ejecutando actualmente y sus hijos . Un programa que se ejecuta en un entorno modificado de este tipo no puede nombrar (y por lo tanto normalmente no puede acceder) a archivos fuera del árbol de directorios designado. El término "chroot" puede referirse a la llamada al sistema chroot(2) o al programa contenedor chroot(8) . El entorno modificado se denomina cárcel chroot .
La llamada al sistema chroot se introdujo durante el desarrollo de la versión 7 de Unix en 1979. Una fuente sugiere que Bill Joy la añadió el 18 de marzo de 1982 (17 meses antes de que se lanzara 4.2BSD ) para probar su instalación y sistema de compilación. [1] Todas las versiones de BSD que tenían un núcleo tienen chroot(2). [2] [3] Un uso temprano del término "jail" aplicado a chroot proviene de Bill Cheswick, quien creó un honeypot para monitorear a un hacker en 1991. [4]
El primer artículo sobre un jailbreak fue discutido en la columna de seguridad de SunWorld Online, escrita por Carole Fennelly; las ediciones de agosto de 1999 y enero de 1999 cubren la mayoría de los temas de chroot(). [5]
Para hacerlo útil para la virtualización , FreeBSD amplió el concepto y en su lanzamiento 4.0 en 2000 introdujo el comando jail . [6]
En 2002, un artículo escrito por Nicolas Boiteux describía cómo crear una cárcel en Linux. [7]
En 2003, los primeros proveedores de microservicios de Internet con cárceles Linux ofrecen servicios SAAS/PAAS (contenedores de shell, proxy, ircd, bots, ...) facturados por consumo en la cárcel por uso. [8]
En 2005, Sun lanzó Solaris Containers (también conocidos como Solaris Zones), descritos como "chroot con esteroides". [9]
En 2008, LXC (sobre el que luego se construyó Docker ) adoptó la terminología de "contenedor" [10] y ganó popularidad en 2013 debido a la inclusión en el kernel de Linux 3.8 de espacios de nombres de usuario . [11]
Se puede utilizar un entorno chroot para crear y alojar una copia virtualizada independiente del sistema de software. Esto puede resultar útil para:
El mecanismo chroot no está pensado para defenderse de la manipulación intencionada por parte de usuarios privilegiados (root). Una notable excepción es NetBSD , en el que chroot se considera un mecanismo de seguridad y no se conocen escapes. En la mayoría de los sistemas, los contextos chroot no se apilan correctamente y los programas chrooteados con privilegios suficientes pueden realizar un segundo chroot para escapar. Para mitigar el riesgo de estas debilidades de seguridad, los programas chrooteados deben renunciar a los privilegios de root tan pronto como sea posible después del chroot, o se deben utilizar otros mecanismos, como las cárceles de FreeBSD , en su lugar. Tenga en cuenta que algunos sistemas, como FreeBSD , toman precauciones para evitar un segundo ataque chroot. [12]
En sistemas que admiten nodos de dispositivos en sistemas de archivos comunes, un usuario root con chroot puede crear nodos de dispositivos y montar los sistemas de archivos en ellos; por lo tanto, el mecanismo chroot no está pensado para bloquear el acceso de bajo nivel a los dispositivos del sistema por parte de usuarios privilegiados. No está pensado para restringir el uso de recursos como E/S , ancho de banda, espacio en disco o tiempo de CPU. La mayoría de los sistemas Unix no están completamente orientados a los sistemas de archivos y dejan funciones potencialmente disruptivas como la red y el control de procesos disponibles a través de la interfaz de llamada del sistema para un programa con chroot.
Al iniciarse, los programas esperan encontrar espacio de trabajo , archivos de configuración, nodos de dispositivos y bibliotecas compartidas en determinadas ubicaciones predeterminadas. Para que un programa en modo chroot se inicie correctamente, el directorio chroot debe estar poblado con un conjunto mínimo de estos archivos. Esto puede hacer que chroot sea difícil de usar como un mecanismo de sandbox general. Herramientas como Jailkit pueden ayudar a facilitar y automatizar este proceso.
Solo el usuario root puede realizar un chroot. Esto tiene como objetivo evitar que los usuarios coloquen un programa setuid dentro de una cárcel chroot especialmente diseñada (por ejemplo, con un archivo /etc/passwd y /etc/shadow falso ) que lo engañe para que realice una escalada de privilegios .
Algunos sistemas Unix ofrecen extensiones del mecanismo chroot para abordar al menos algunas de estas limitaciones (consulte Implementaciones de tecnología de virtualización a nivel de sistema operativo ).
Es posible ejecutar aplicaciones gráficas en un entorno chroot, utilizando métodos como: [13] [14]
El agente de transferencia de correo Postfix funciona como una tubería de programas auxiliares con chroot individual.
Al igual que 4.2BSD antes de él, las granjas de compilación de paquetes internos de Debian y Ubuntu usan chroots ampliamente para detectar dependencias de compilación no intencionales entre paquetes. SUSE usa un método similar con su programa de compilación . Fedora, Red Hat y varias otras distribuciones basadas en RPM compilan todos los RPM usando una herramienta chroot como mock.
Muchos servidores FTP para sistemas POSIX utilizan el mecanismo chroot para aislar a los clientes FTP no confiables. Esto se puede hacer bifurcando un proceso para manejar una conexión entrante y luego chrooteando el proceso secundario (para evitar tener que llenar el chroot con las bibliotecas necesarias para el inicio del programa).
Si se habilita la separación de privilegios, el demonio OpenSSH convertirá un proceso auxiliar sin privilegios en un directorio vacío para gestionar el tráfico de red previo a la autenticación de cada cliente. El demonio también puede aislar sesiones de SFTP y shell en un entorno chroot (a partir de la versión 4.9p1). [16]
ChromeOS puede usar un chroot para ejecutar una instancia de Linux mediante Crouton [17] , lo que le permite a un sistema operativo que de otro modo sería delgado tener acceso a recursos de hardware. Las implicaciones de seguridad relacionadas en este artículo se aplican aquí.
Para tener un entorno chroot funcional en Linux, los sistemas de archivos virtuales del kernel y los archivos de configuración también deben montarse/copiarse del host al chroot.
# Montar sistemas de archivos virtuales del kernel TARGETDIR = "/mnt/chroot"
mount -t proc proc $TARGETDIR /proc montaje -t sysfs sysfs $TARGETDIR /sys montaje -t devtmpfs devtmpfs $TARGETDIR /dev montaje -t tmpfs tmpfs $TARGETDIR /dev/shm montaje -t devpts devpts $TARGETDIR /dev/pts # Copiar /etc/hosts
/bin/cp -f /etc/hosts $TARGETDIR /etc/ # Copiar /etc/resolv.conf
/bin/cp -f /etc/resolv.conf $TARGETDIR /etc/resolv.conf # Enlace /etc/mtab
chroot $TARGETDIR rm /etc/mtab 2 > /dev/null
chroot $TARGETDIR ln -s /proc/mounts /etc/mtab