El mecanismo de cárcel es una implementación de la virtualización a nivel de sistema operativo de FreeBSD que permite a los administradores de sistemas particionar un sistema informático derivado de FreeBSD en varios minisistemas independientes llamados cárceles , todos compartiendo el mismo núcleo, con muy poca sobrecarga [1] . Se implementa a través de una llamada al sistema, jail(2), [2] así como una utilidad de espacio de usuario, jail(8), [3] más, dependiendo del sistema, una serie de otras utilidades. La funcionalidad fue incorporada a FreeBSD en 1999 por Poul-Henning Kamp después de un período de uso en producción por parte de un proveedor de alojamiento, y fue lanzada por primera vez con FreeBSD 4.0, por lo que es compatible con una serie de descendientes de FreeBSD, incluido DragonFly BSD , hasta el día de hoy.
La necesidad de las cárceles de FreeBSD surgió del deseo de un pequeño proveedor de alojamiento de entornos compartidos (el propietario de R&D Associates, Inc., Derrick T. Woolworth) de establecer una separación clara y nítida entre sus propios servicios y los de sus clientes, principalmente por motivos de seguridad y facilidad de administración (jail(8)). En lugar de añadir una nueva capa de opciones de configuración de grano fino, la solución adoptada por Poul-Henning Kamp fue compartimentar el sistema (tanto sus archivos como sus recursos) de tal forma que sólo las personas adecuadas tuvieran acceso a los compartimentos adecuados. [4]
Las cárceles se introdujeron por primera vez en la versión 4.0 de FreeBSD, que se lanzó el 14 de marzo de 2000. [ 5] La mayor parte de la funcionalidad original es compatible con DragonFly, y varias de las nuevas características también se han adaptado.
Las cárceles de FreeBSD tienen como objetivo principal tres objetivos:
A diferencia de la cárcel chroot , que solo restringe los procesos a una vista particular del sistema de archivos , el mecanismo de cárcel de FreeBSD restringe las actividades de un proceso en una cárcel con respecto al resto del sistema. En efecto, los procesos encarcelados están aislados . Están vinculados a direcciones IP específicas , y un proceso encarcelado no puede acceder a sockets de desvío o enrutamiento. Los sockets sin formato también están deshabilitados de forma predeterminada, pero se pueden habilitar configurando la opción security.jail.allow_raw_sockets sysctl . Además, se restringe la interacción entre procesos que no se ejecutan en la misma cárcel.
La utilidad jail(8) y la llamada al sistema jail(2) aparecieron por primera vez en FreeBSD 4.0 . En FreeBSD 5.1 se añadieron nuevas utilidades (por ejemplo, jls(8) para listar jails) y llamadas al sistema (por ejemplo, jail_attach(2) para adjuntar un nuevo proceso a un jail) que facilitan enormemente la gestión de jails. El subsistema jail recibió importantes actualizaciones adicionales con FreeBSD 7.2, incluyendo compatibilidad con múltiples direcciones IPv4 e IPv6 por jail y compatibilidad con la vinculación de jails a CPU específicas.
Con las cárceles es posible crear entornos, cada uno con su propio conjunto de utilidades instaladas y su propia configuración. Las cárceles permiten a los paquetes de software ver el sistema de forma egoísta, como si cada paquete tuviera la máquina para sí mismo. Las cárceles también pueden tener sus propios superusuarios independientes encarcelados. [6]
Sin embargo, la cárcel de FreeBSD no logra una verdadera virtualización; no permite que las máquinas virtuales ejecuten versiones de kernel diferentes a las del sistema base. Todas las cárceles comparten el mismo kernel. No hay soporte para agrupamiento en clústeres ni migración de procesos .
Las cárceles de FreeBSD son una forma efectiva de aumentar la seguridad de un servidor debido a la separación entre el entorno encarcelado y el resto del sistema (las otras cárceles y el sistema base).
Las cárceles de FreeBSD están limitadas de las siguientes maneras: [6]
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}