FreeBSD-Jails: Überblick für Administratoren zu jail.conf, jls, jexec und Ressourcenlimits mit rctl

Worum es geht

FreeBSD-Jails gibt es seit FreeBSD 4.X. Sie bauen auf dem Konzept von chroot(2) auf, das für eine Gruppe von Prozessen das Wurzelverzeichnis ändert. Das Handbook beschreibt das Ergebnis als "a safe environment, separate from the rest of the system" (eine sichere, vom restlichen System getrennte Umgebung), in der Prozesse nicht auf Dateien oder Ressourcen ausserhalb zugreifen können. Ein Jail geht jedoch über ein einfaches chroot hinaus: Es schirmt auch die Sicht auf Prozesse und optional das Netzwerk vom restlichen System ab, was ein blosses chroot nicht leistet.

Ein Jail wird in /etc/jail.conf als benannter Block mit Parameterzuweisungen deklariert, zum Beispiel:

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) dokumentiert path, host.hostname, ip4.addr/ip6.addr und exec.start/exec.stop als die Parameter, die der Reihe nach das Wurzelverzeichnis, den Hostnamen, die Adressen sowie die Start- und Stopp-Befehle des Jails festlegen. mount.devfs stellt dem Jail ein eingeschränktes /dev bereit. $name und ${host.hostname} sind Beispiele für die Variablensubstitution, die das Format unterstützt.

Warum es wichtig ist

Ein Jail wird für die laufende Verwaltung vom Host aus administriert und nicht wie eine separate Maschine per Login betreut. Deshalb sind die Werkzeuge auf der Host-Seite ebenso wichtig wie die Konfiguration des Jails selbst. jls(8) listet alle aktiven Jails (oder eines, angegeben per JID oder Name) mit Adressen und Pfaden auf – der schnellste Weg, um zu prüfen, was tatsächlich läuft. jexec(8) führt vom Host aus einen Befehl in einem bestehenden Jail aus. Das ist der übliche Weg zu einer interaktiven Shell für die Fehlersuche, ohne dass ein SSH-Daemon im Jail erreichbar sein muss. Ressourcenlimits werden unabhängig von der Konfiguration des Jails mit rctl(8) gesetzt. Die Beispiele im Handbook begrenzen CPU, Prozessanzahl, offene Dateien und Speicher pro Jail, etwa mit rctl -a jail:classic:pcpu:deny=80. rctl funktioniert nur, wenn in /boot/loader.conf der Tunable kern.racct.enable=1 gesetzt ist (eine Einstellung, die beim Booten gelesen wird). Mit rctl -a hinzugefügte Regeln gehen beim Neustart verloren, sofern sie nicht zusätzlich in /etc/rctl.conf stehen.

So wird es angewendet

• Mit jail.conf beginnen statt mit wiederholten Aufrufen von jail(8) auf der Kommandozeile, damit die Konfiguration nachvollziehbar und reproduzierbar bleibt. sysrc jail_enable=YES startet die konfigurierten Jails beim Booten, service jail start <name> startet eines sofort.
• Vor und nach jedem Neustart des Hosts oder eines Jails jls verwenden, um zu bestätigen, dass die erwarteten Jails mit den erwarteten Adressen laufen.
• Für Wartungsarbeiten ein Jail mit jexec <jail> <command> betreten, statt Dienste mit netzwerkseitig erreichbarem Shell-Zugang darin zu betreiben.
• Ressourcenintensive Jails mit rctl-Regeln pro Jail-Name begrenzen (jail:<name>:<resource>:deny=<amount>), damit ein Jail weder den Host noch benachbarte Jails aushungern kann.

Stolpersteine

• Ein Jail als vollwertige Sicherheitsgrenze zu betrachten, die einer virtuellen Maschine entspricht: Ohne rctl-Limits kann ein einzelnes Jail weiterhin hostweite Ressourcen wie Speicher oder Dateideskriptoren erschöpfen.
• Zu vergessen, dass exec.start/exec.stop die eigenen rc-Skripte des Jails ausführen: Die rc.conf des Jails unter path muss die Dienste genauso aktivieren wie bei einem vollständigen Host, sonst startet beim Start des Jails nichts.