chrootes una operación en Unix y sistemas operativos similares a Unix que cambia el directorio raíz aparente para el proceso en ejecución actual 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 llama 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 su sistema de compilación. [1] Todas las versiones de BSD que tenían kernel tienen chroot(2). [2] [3] Un uso temprano del término "cárcel" aplicado a chroot proviene de Bill Cheswick que creó un honeypot para monitorear a un hacker en 1991. [4]
El primer artículo sobre jailbreak se analizó 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 versión 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 de Linux proporcionaron servicios SAAS/PAAS (contenedores shell, proxy, ircd, bots, ...) facturados por el 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 cual se construyó Docker más tarde) 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 separada del sistema de software. Esto puede ser útil para:
El mecanismo chroot no pretende defenderse contra la manipulación intencional por parte de usuarios privilegiados (root). Una excepción notable 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 acumulan correctamente y los programas chroot con privilegios suficientes pueden realizar un segundo chroot para salir. Para mitigar el riesgo de estas debilidades de seguridad, los programas chroot 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 normales, un usuario root con chroot aún puede crear nodos de dispositivos y montar los sistemas de archivos en ellos; por lo tanto, el mecanismo chroot no está diseñado por sí solo para bloquear el acceso de bajo nivel a dispositivos del sistema por parte de usuarios privilegiados. No pretende restringir el uso de recursos como E/S , ancho de banda, espacio en disco o tiempo de CPU. La mayoría de Unixes no están completamente orientados al sistema de archivos y dejan funcionalidades potencialmente disruptivas, como redes y control de procesos, disponibles a través de la interfaz de llamada del sistema para un programa chroot.
Al inicio, los programas esperan encontrar espacio temporal , archivos de configuración, nodos de dispositivos y bibliotecas compartidas en ciertas ubicaciones preestablecidas. Para que un programa 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 mecanismo general de espacio aislado. Herramientas como Jailkit pueden ayudar a facilitar y automatizar este proceso.
Sólo 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ñaría y provocaría una escalada de privilegios .
Algunos 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 opera como una canalización de programas auxiliares con chroot individual.
Al igual que 4.2BSD antes, las granjas de creación de paquetes internas de Debian y Ubuntu utilizan chroots ampliamente para detectar dependencias de compilación no intencionales entre paquetes. SUSE utiliza un método similar con su programa de compilación . Fedora, Red Hat y varias otras distribuciones basadas en RPM crean todos los RPM utilizando una herramienta chroot como mock.
Muchos servidores FTP para sistemas POSIX utilizan el mecanismo chroot para proteger a clientes FTP que no son de confianza. Esto se puede hacer bifurcando un proceso para manejar una conexión entrante y luego haciendo chroot al niño (para evitar tener que llenar el chroot con las bibliotecas necesarias para el inicio del programa).
Si la separación de privilegios está habilitada, el demonio OpenSSH direccionará un proceso auxiliar sin privilegios a un directorio vacío para manejar el tráfico de red de autenticación previa para cada cliente. El demonio también puede proteger sesiones SFTP y shell en un chroot (desde la versión 4.9p1 en adelante). [dieciséis]
ChromeOS puede usar un chroot para ejecutar una instancia de Linux usando Crouton , [17] proporcionando a un sistema operativo delgado 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 montar -t sysfs sysfs $TARGETDIR /sys montar -t devtmpfs devtmpfs $TARGETDIR /dev montaje -t tmpfs tmpfs $TARGETDIR /dev/shm montar -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