chroot

chrootes un comando de shell y una llamada al sistema en sistemas operativos Unix y similares a Unix que cambia el directorio raíz aparente para el proceso en ejecución actual y sus procesos 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 a la utilidad de línea de comandos chroot(8) . El entorno modificado se denomina jaula 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 agregó el 18 de marzo de 1982 , 17 meses antes del lanzamiento de 4.2BSD , para probar su sistema de instalación y compilación. ^{[ 1 ]} Todas las versiones de BSD que tenían un kernel tienen chroot(2) . ^{[ 2 ] [ 3 ]} Un uso temprano del término "jail" aplicado a chroot proviene de Bill Cheswick creando un honeypot para monitorear a un hacker en 1991. ^{[ 4 ]}  

El primer artículo sobre un jailbreak se ha tratado 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 relacionados con chroot() . ^{[ 5 ]}

Para hacerlo útil para la virtualización , FreeBSD amplió el concepto y en su versión 4.0 del año 2000 introdujo el comando jail . ^{[ 6 ]}

En 2002, un artículo francés de Nicolas Boiteux describió cómo crear jaulas en Linux. ^{[ 7 ]}

Para 2003, los primeros proveedores de microservicios de Internet con jaulas Linux ofrecían servicios SaaS / PaaS (por ejemplo, contenedores shell, proxy, ircd, bots, etc.) facturados según el consumo dentro de la jaula por uso. ^{[ 8 ]}

En 2005, Sun lanzó Solaris Containers (también conocidos como Solaris Zones), descritos como "chroot con esteroides". ^{[ 9 ]}

Para 2008, LXC (sobre el cual se construyó Docker posteriormente) 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 los 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 ser útil para:

Pruebas y desarrollo

En el entorno chroot se puede configurar un entorno de prueba para software que, de otro modo, sería demasiado arriesgado implementar en un sistema de producción.

Control de dependencias

El software se puede desarrollar, compilar y probar en un entorno chroot que contenga únicamente sus dependencias previstas. Esto puede prevenir ciertos problemas de vinculación que pueden surgir cuando los desarrolladores crean proyectos con diferentes conjuntos de bibliotecas de programas instaladas.

Compatibilidad

En ocasiones , el software heredado o el software que utiliza una ABI diferente debe ejecutarse en un entorno chroot, ya que, de lo contrario, sus bibliotecas o archivos de datos de soporte podrían entrar en conflicto por nombre o enlace con los del sistema anfitrión.

Recuperación

Si un sistema queda inutilizable, se puede utilizar un entorno chroot para volver al entorno dañado tras arrancar desde un sistema de archivos raíz alternativo (como un medio de instalación o un Live CD ).

Separación de privilegios

Los programas pueden llevar descriptores de archivos abiertos (para archivos, tuberías y conexiones de red) al entorno chroot, lo que simplifica el diseño de entornos aislados al eliminar la necesidad de dejar archivos de trabajo dentro del directorio chroot. Esto también simplifica la práctica común de ejecutar las partes potencialmente vulnerables de un programa con privilegios en un entorno aislado, para contener de forma preventiva una brecha de seguridad. Cabe destacar que chroot no es necesariamente suficiente para contener un proceso con privilegios de administrador.

El mecanismo chroot no está diseñado para proteger contra manipulaciones intencionadas por parte de usuarios privilegiados (root). Una excepción notable es NetBSD , donde chroot se considera un mecanismo de seguridad y no se conocen vulnerabilidades de escape. En la mayoría de los sistemas, los contextos chroot no se apilan correctamente y los programas chroot con privilegios suficientes pueden realizar un segundo chroot ^{[ 12 ]} para escapar. Para mitigar el riesgo de esta vulnerabilidad de seguridad, los programas chroot deben renunciar a los privilegios de root tan pronto como sea posible después de chrootear, o bien se deben utilizar otros mecanismos  , como las jaulas de FreeBSD . Cabe señalar que algunos sistemas, como FreeBSD , toman precauciones para prevenir un segundo ataque chroot. ^{[ 13 ]}

En sistemas que admiten nodos de dispositivo en sistemas de archivos ordinarios, un usuario root en un entorno chroot aún puede crear nodos de dispositivo y montar los sistemas de archivos en ellos; por lo tanto, el mecanismo chroot no está diseñado para bloquear el acceso de bajo nivel a los dispositivos del sistema por parte de usuarios privilegiados. Tampoco está diseñado 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 al sistema de archivos y dejan funcionalidades potencialmente disruptivas, como la red y el control de procesos, disponibles a través de la interfaz de llamadas al sistema para un programa en un entorno chroot.

Al iniciarse, los programas esperan encontrar espacio temporal , archivos de configuración, nodos de dispositivo y bibliotecas compartidas en ciertas ubicaciones predefinidas. Para que un programa en un entorno chroot se inicie correctamente, el directorio chroot debe contener un conjunto mínimo de estos archivos. Esto puede dificultar el uso de chroot como mecanismo general de aislamiento. Herramientas como Jailkit ^{[ 14 ]} pueden ayudar a simplificar 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 jaula chroot especialmente diseñada (por ejemplo, con un archivo /etc/passwd y /etc/shadow falsos ) que lo engañaría para lograr una escalada de privilegios .

Algunos sistemas Unix ofrecen extensiones del mecanismo chroot para abordar al menos algunas de estas limitaciones (véase 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: ^{[ 15 ] [ 16 ]}

• Utilice xhost (o copie el secreto de .Xauthority)
• Servidores X anidados como Xnest o el más moderno Xephyr (o iniciar un servidor X real desde dentro del entorno aislado).
• Acceso al entorno chroot mediante SSH utilizando la función de reenvío X11 ( ssh -X ).
• xchroot es una versión extendida de chroot para usuarios y reenvío de Xorg/X11 (socat/mount).
• Un servidor VNC X11 y la conexión de un cliente VNC fuera del entorno.
• Atoms es una herramienta de gestión de chroot de Linux con una interfaz gráfica de usuario fácil de usar. ^{[ 17 ]}

El agente de transferencia de correo Postfix puede funcionar como una tubería de programas auxiliares chroot individuales. ^{[ 18 ]}

Al igual que 4.2BSD antes que él, las granjas internas de compilación de paquetes de Debian y Ubuntu usan chroots de forma extensiva para detectar dependencias de compilación no intencionadas 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 lograr creando un proceso hijo para gestionar una conexión entrante y luego aplicando chroot al proceso hijo (para evitar tener que instalar en el entorno chroot las bibliotecas necesarias para el inicio del programa).

Si la separación de privilegios está habilitada, el demonio OpenSSH creará un entorno chroot para 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 SFTP y de shell en un entorno chroot (a partir de la versión 4.9p1). ^{[ 19 ]}

ChromeOS puede usar un entorno chroot para ejecutar una instancia de Linux mediante Crouton ^{[ 20 ]} , lo que proporciona a un sistema operativo ligero acceso a recursos de hardware. Las implicaciones de seguridad mencionadas en este artículo también 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 entorno chroot.

# Montar sistemas de archivos virtuales del kernel TARGETDIR = "/mnt/chroot" mount -t proc proc $TARGETDIR /proc mount -t sysfs sysfs $TARGETDIR /sys mount -t devtmpfs devtmpfs $TARGETDIR /dev mount -t tmpfs tmpfs $TARGETDIR /dev/shm mount -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 

• Lista de comandos de Unix
• Virtualización a nivel de sistema operativo
• Entorno aislado (seguridad informática)
• sudo

• chroot(2): cambiar directorio raíz – Manual de llamadas al sistema de FreeBSD   
• chroot(8)Cambiar el directorio raíz – Manual del administrador del sistema FreeBSD   
• chroot(2): cambiar directorio raíz – Manual del programador de Linux – Llamadas al sistema de Manned.org   
• Integración de GNU/Linux con Android mediante chroot