Jails FreeBSD : vue d'ensemble de l'administration avec jail.conf, jls, jexec et les limites de ressources via rctl

Ce que c'est

Les jails FreeBSD existent depuis FreeBSD 4.X et reposent sur le principe de chroot(2), qui consiste à changer le répertoire racine d'un ensemble de processus. Le Handbook décrit le résultat comme la création d'un « environnement sûr, séparé du reste du système » ("a safe environment, separate from the rest of the system"), dans lequel les processus ne peuvent accéder ni aux fichiers ni aux ressources situés à l'extérieur. Un jail va toutefois plus loin qu'un simple chroot : il isole aussi la visibilité des processus et, en option, le réseau du reste du système, ce qu'un chroot seul ne fait pas.

Un jail se déclare dans /etc/jail.conf sous la forme d'un bloc nommé d'affectations de paramètres, par exemple :

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;
}

Selon jail.conf(5), path, host.hostname, ip4.addr/ip6.addr et exec.start/exec.stop définissent respectivement la racine du jail, son nom d'hôte, ses adresses et ses commandes de démarrage et d'arrêt ; mount.devfs donne au jail un /dev restreint ; $name et ${host.hostname} illustrent la substitution de variables prise en charge par le format.

Pourquoi c'est important

Un jail s'administre depuis l'hôte : on ne s'y connecte pas comme à une machine distincte pour la gestion courante. Les outils côté hôte comptent donc autant que la configuration propre au jail. jls(8) liste tous les jails actifs (ou un seul, à partir d'un JID ou d'un nom) avec leurs adresses et leurs chemins ; c'est le moyen le plus rapide de vérifier ce qui tourne réellement. jexec(8) exécute une commande dans un jail existant depuis l'hôte ; c'est la manière habituelle d'obtenir un shell interactif pour le dépannage, sans exposer de démon SSH à l'intérieur du jail. Les limites de ressources se définissent avec rctl(8), indépendamment de la configuration du jail ; les exemples du Handbook plafonnent par jail le CPU, le nombre de processus, les fichiers ouverts et la mémoire, par exemple rctl -a jail:classic:pcpu:deny=80. rctl ne fonctionne qu'avec le paramètre kern.racct.enable=1 dans /boot/loader.conf (réglage pris en compte au démarrage), et les règles ajoutées avec rctl -a sont perdues au redémarrage si elles ne sont pas aussi inscrites dans /etc/rctl.conf.

Comment l'appliquer

• Partir de jail.conf plutôt que de lancements répétés de jail(8) en ligne de commande, afin que la configuration soit relisible et reproductible ; sysrc jail_enable=YES démarre les jails configurés au boot et service jail start <name> en démarre un immédiatement.
• Utiliser jls avant et après tout redémarrage de l'hôte ou d'un jail pour confirmer que l'ensemble attendu de jails tourne avec les adresses attendues.
• Entrer dans un jail pour la maintenance avec jexec <jail> <command> plutôt que d'y faire tourner des services offrant un accès shell exposé au réseau.
• Plafonner les jails gourmands en ressources avec des règles rctl par nom de jail (jail:<name>:<resource>:deny=<amount>), afin qu'un jail ne puisse pas priver l'hôte ou les autres jails de ressources.

Pièges

• Considérer un jail comme une frontière de sécurité complète, équivalente à une machine virtuelle : sans limites rctl, un jail peut encore épuiser des ressources communes à tout l'hôte, comme la mémoire ou les descripteurs de fichiers.
• Oublier que exec.start/exec.stop exécutent les propres scripts rc du jail : le rc.conf situé dans path doit activer les services comme sur un hôte complet, faute de quoi rien ne démarre avec le jail.