Jaulas de FreeBSD: una visión general administrativa de jail.conf, jls, jexec y los límites de recursos con rctl

Qué es

Las jaulas de FreeBSD están disponibles desde FreeBSD 4.X y se basan en el concepto de chroot(2) de cambiar el directorio raíz para un conjunto de procesos. El Handbook describe el resultado como la creación de «un entorno seguro, separado del resto del sistema», en el que los procesos internos no pueden acceder a archivos ni recursos fuera de él; pero una jaula va más allá de un chroot simple, ya que también confina la visibilidad de procesos y, opcionalmente, la red respecto al resto del sistema, algo que un chroot básico no hace.

Una jaula se declara en /etc/jail.conf como un bloque con nombre de asignaciones de parámetros, por ejemplo:

foo {
    host.hostname = "foo.com";
    ip4.addr = 10.1.1.1, 10.1.1.2, 10.1.1.3;
    path = "/var/jail/$name";
    exec.start = "/bin/sh /etc/rc";
    exec.stop = "/bin/sh /etc/rc.shutdown jail";
    mount.devfs;
}

jail.conf(5) documenta path, host.hostname, ip4.addr/ip6.addr y exec.start/exec.stop como los parámetros que establecen, respectivamente, la raíz, el nombre de host, las direcciones y los comandos de arranque/parada de la jaula; mount.devfs le da a la jaula un /dev restringido; $name y ${host.hostname} son ejemplos de la sustitución de variables que admite el formato.

Por qué importa

Dado que una jaula se administra desde el host en lugar de iniciar sesión en ella como en una máquina aparte para el mantenimiento rutinario, las herramientas del lado del host importan tanto como la configuración propia de la jaula. jls(8) enumera todas las jaulas activas (o una sola, dado un JID o un nombre) con sus direcciones y rutas: la forma más rápida de confirmar qué se está ejecutando realmente. jexec(8) ejecuta un comando dentro de una jaula existente desde el host, la forma habitual de obtener un shell interactivo para solucionar problemas sin exponer un demonio SSH interno a la jaula. Los límites de recursos se establecen con rctl(8), de forma independiente a la configuración propia de la jaula; los ejemplos del Handbook limitan la CPU, el número de procesos, los archivos abiertos y la memoria por jaula, por ejemplo rctl -a jail:classic:pcpu:deny=80. rctl solo funciona con el ajustable kern.racct.enable=1 en /boot/loader.conf (una configuración en tiempo de arranque), y las reglas añadidas con rctl -a se pierden al reiniciar a menos que también se escriban en /etc/rctl.conf.

Cómo aplicarlo

• Empezar por jail.conf, no por invocaciones repetidas de la línea de comandos jail(8), para que la configuración sea revisable y reproducible; sysrc jail_enable=YES inicia las jaulas configuradas al arrancar, y service jail start <name> inicia una de inmediato.
• Usar jls antes y después de cualquier reinicio del host o de la jaula para confirmar que el conjunto esperado de jaulas se está ejecutando con las direcciones esperadas.
• Entrar en una jaula para tareas de mantenimiento con jexec <jail> <command> en lugar de ejecutar servicios con acceso de shell expuesto a la red dentro de ella.
• Limitar las jaulas que consumen muchos recursos con reglas de rctl por nombre de jaula (jail:<name>:<resource>:deny=<amount>), de modo que una jaula no pueda dejar sin recursos al host ni a sus vecinas.

Trampas

• Tratar una jaula como un límite de seguridad completo equivalente a una máquina virtual: sin límites de rctl, una jaula puede seguir agotando recursos de todo el host, como la memoria o los descriptores de archivo.
• Olvidar que exec.start/exec.stop ejecutan los propios scripts rc de la jaula: el rc.conf de la jaula dentro de path necesita tener sus servicios habilitados igual que lo necesitaría un host completo, o no arrancará nada cuando lo haga la jaula.