Wie man Jails in FreeBSD konfiguriert und benutzt

© FFernando Gregory, 123RF

Sicher hinter Gittern

Heute, wo IT-Sicherheit eine immer größere Rolle spielt, findet ein Feature von FreeBSD besondere Beachtung: die Jails. Worin das Sicherheitsplus besteht, das sie versprechen, beleuchtet dieser Artikel.
Obwohl Linux als freie Software kostenlos verfügbar ist, setzen viele beim Unternehmenseinsatz auf Enterprise-Distributionen mit Support. Wo die Stärken der ... (mehr)

Die Verwaltung der Zugriffsrechte unter UNIX und damit auch unter FreeBSD kennt im Grunde genommen zwei Typen von Benutzern: User mit und User ohne Administrator-Privilegien. Dieses Modell stößt aber an seine Grenzen, wenn zum Beispiel ein Web-Administrator angelegt werden soll. Er benötigt Berechtigungen, um bestimmte Konfigurationsdateien ändern zu dürfen oder den HTTP-Daemon neu zu starten – soll aber die Systemkonfiguration nicht ändern können. Eine Lösung dieses Problems bestünde in einer höheren Granularität der Zugriffsrechte. In FreeBSD gibt es dafür die Möglichkeit mit File Access Control Lists (FACL) zu arbeiten oder das Capability- und Sandboxing-Framework Capsicum einzusetzen. Doch leider erhöht dies den Verwaltungsaufwand nicht unerheblich, was sich wiederum negativ auf die Sicherheit auswirken kann.

Als ein Ausweg aus diesem Dilemma wurde einst die Chroot-Umgebung erfunden, die unter Sicherheitsgesichtspunkten jedoch Mängel aufweist. Beispielsweise sind bei einem FTP-Server, der anonymen Zugriff gestattet, Möglichkeiten bekannt geworden, aus der Chroot-Umgebung auszubrechen. Im Laufe der Zeit kamen einige Verbesserungen hinzu, aber Probleme wie das Beeinflussen von Prozessen außerhalb von Chroot, wurden letztlich nicht behoben.

Das Konzept der Jails

Hier kommt nun das Konzept der Jails ins Spiel: Es nutzt die positiven Eigenschaften von Chroot und bietet gleichzeitig einen absoluten Schutz vor der Manipulation von Prozessen außerhalb der Jail. Da eine Jail auf einem Unterverzeichnisbaum aufsetzt, ist es einem Prozess innerhalb der Jail nicht mehr möglich, auf Verzeichnisse und Dateien außerhalb zuzugreifen. Weiterhin ist es einem Prozess in einer Jail nicht mehr möglich, manipulierend auf Prozesse des Hosts einzuwirken. Damit bieten sich Jails an, um in ihnen Netzwerkdienste laufen zu lassen.

Allerdings erhöht ein Jail nicht die Sicherheit eines Daemons selbst. Wenn ein FTP-Daemon eine Sicherheitslücke aufweist, dann hat er sie auch in der Jail. Ein Angreifer könnte diese Lücke ausnutzen und sich so Zugang zur Jail verschaffen und dort womöglich sogar Root-Rechte erlangen. Dennoch bliebe ein großer Sicherheitsvorteil bestehen, denn der Angreifer könnte nur in der Jail sein Unwesen treiben. Er hätte keinerlei Zugang zum Hostsystem! Dabei erhöht sich anders als bei einer fein granulierten Zugriffsverwaltung der Aufwand nur moderat. Das Ausbrechen von Prozessen oder die Beeinflussung anderer Prozesse außerhalb einer Jail sind nicht mehr möglich.

In einer Jail gibt es wieder einen Root-User, allerdings mit etwas eingeschränkten Möglichkeiten. Unter anderem hat er keine Chance, den Host oder die IP-Adresse der Jail zu manipulieren. Durch bestimmte Sysctl-MIBs lassen sich die Befugnisse von root innerhalb der Jail noch weiter einschränken. Es ist möglich, einer Jail keine oder mehrere IPv4- beziehungsweise IPv6-Adressen zuzuordnen, was sie zu einer Routing-fähigen Jail macht. Die Adresse wird beim Start der Jail mit angegeben. Auch die Loopback-Adresse 127.0.0.1 und ihr IPv6-Pendant ::1 dürfen mit einer Jail verknüpft werden. Man spricht dann von einer internen Jail.

Innerhalb einer Jail steht dem Benutzer ein komplettes FreeBSD zur Verfügung. Damit bieten Jails auch eine Art von Virtualisierung wie VMware oder Xen. Seit FreeBSD 8 besteht sogar die Möglichkeit, in einer Jail weitere Jails anzulegen (Hierachical Jails). Das mit FreeBSD 4 eingeführte Konzept der Jails hat vor einiger Zeit auch einen anderen Betriebssystemanbieter überzeugt: Sun Microsystems (heute Oracle). In Solaris heißen die Jails Zones.

Beschränkungen

Innerhalb einer Jail gibt es aufgrund der Implementierung wichtige Einschränkungen. Remote-Procedure-Calls (RPC) funktionieren im Jail-Betrieb aus Sicherheitsgründen nicht mehr. Daher gibt es keine Möglichkeit, NFS innerhalb einer Jail zu nutzen. Daemon-Prozesse auf dem Host müssen sehr sorgfältig konfiguriert sein, damit es nicht zu Adresskonflikten zwischen Jail und Host kommt. Das Laden oder Entladen von Kernelmodulen ist innerhalb einer Jail genauso unterbunden wie das Erstellen von Device-Nodes. Das Mounten und Unmounten von Dateisystemen ist nicht möglich. Das Modifizieren der Netzwerkkonfiguration, der Netzwerkadressen oder auch der Routing-Tabellen ist verboten. Der Zugriff auf sogenannte Raw-Sockets des Hostsystems ist nicht mehr möglich, aber innerhalb der Jail besteht die Möglichkeit, auf diesen Typ von Sockets zuzugreifen. Ebenso ist es nicht gestattet, Semaphoren des Hostsystems anzusprechen.

Aus den meisten dieser Einschränkungen resultiert bei genauer Betrachtung ein Sicherheitsgewinn im Vergleich zu einer Chroot-Umgebung.

comments powered by Disqus

Artikel der Woche

Loadtests ohne Server

Für Loadtests der eigenen Server bietet sich die Cloud an, denn kurz getaktet lassen sich dort viele Rechnerinstanzen starten, die das eigene Budget nur wenig belasten. Noch flexibler, günstiger und besser skalierbar sind Tests mit einer Serverless-Infrastruktur wie AWS Lambda. Wir führen vor, wie Sie dort mit Serverless Artillery eigene Loadtests starten. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite