Sicherheit bei Jails und gleicher UID

[Daemotron]

Moin,

ich hätte da mal eine Frage an die Kernelhacker hier im Forum: Wie groß schätzt ihr das Risiko ein, dass es zu einer Kompromittierung kommen kann, wenn in zwei unterschiedlichen Jails Prozesse mit derselben UID laufen? Sichtbar sind sie ja erst mal nicht füreinander, aber wie sieht das mit Shared Memory und ähnlichen Scherzen aus? Ich weiß, dass das bei Linux chroot ein nicht unerhebliches Problem ist; allerdings werden da ja nicht komplette Prozesse gejailed wie bei FreeBSD.

Viele Grüße,
Ogion

 

[Yamagi]

Null. Unter der Bedingung, dass es keinen Fehler im Kernel gibt, was nach so vielen Jahren (fast 10) der Nutzung doch recht unwahrscheinlich ist. Die Sache ist ganz simpel gesagt so, dass jeder Prozess eine "Jail ID" zugeordnet hat. Nur Prozesse mit gleicher Jail ID können überhaupt direkt zusammenkommen, sei es per Shared Memory, IPC oder anderem schönen Kram. Ein simples chroot hat keinen so ausgefeilten Mechanismus, auch unter FreeBSD nicht. Daher kann es dort zu Ausbrüchen kommen.

Es gibt nur eine praxisrelevante Sache, über die man einen Ausbruch aus dem Jail konstruieren kann. Dateideskriptoren. Hält ein Prozess A im Jail 1 eine Datei geöffnet und ich kopiere die Datei einfach aus dem Jail heraus, gelangt der Deskriptor unter Umständen in den Host. Prozess A kann nun das Jail 1 über diesen verlassen und ist frei. Der Grund, weshlab man niemals aus dem Host heraus in laufenden Jails herumdoktern sollte und bitte auch keinen Platz sparen, indem man Daten zwischen Jails hardlinked. Mit klassischen Jails ist dies leider nicht zu beheben, mit vimage würde es gehen. Aber keine Ahnung, ob vimage zu Beginn schon genug Kernelkomponenten virtualisiert, damit dies auch gleich gelingt.

 

[Daemotron]

Danke, dann kann ich es mir also getrost sparen, für jedes Jail separate UID-/GID-Nummernkreise zu verwenden (zumindest aus sicherheitstechnischer Sicht - aus administrativer Sicht wäre es vielleicht eine Überlegung wert, da man dann schon im Host an der UID erkennen kann, zu welchem Jail ein Prozess gehört).

Der Hinweis auf die Dateideskriptoren ist gut, da werde ich drauf achten, dass nicht irgendwelche Backup-Skripte wild herumkopieren. Da bei mir jedes Jail ein eigenes FS bekommen soll, sind Hardlinks zwischen Jails eigentlich ausgeschlossen und damit (hoffentlich) auch kein Sicherheitsthema.

 

[Yamagi]

Backups kannst du über Snapshots laufen lassen, die ja leider unter UFS2 recht träge sind. Ein Snapshot referenziert zwar die Inode einer Datei, ist aber aus technischer Sicht ein neues Dateisystem und öffnet daher neue Dateideskriptoren. Von ihnen zu backupen ist daher sicher.

 

[Kamikaze]

Sind denn Nullfs Mounts wenigstens sicher? Die habe ich immer ohne Bedenekein eingesetzt, wenn ich mit Jails hantiere.

 

[troll]

Null. Unter der Bedingung, dass es keinen Fehler im Kernel gibt, was nach so vielen Jahren (fast 10) der Nutzung doch recht unwahrscheinlich ist. Die Sache ist ganz simpel gesagt so, dass jeder Prozess eine "Jail ID" zugeordnet hat. Nur Prozesse mit gleicher Jail ID können überhaupt direkt zusammenkommen, sei es per Shared Memory, IPC oder anderem schönen Kram.

Sicher?
Zumindest sehen kann man sie aus der Jail, was ja streng genommen schon eine Verletzung darstellt. Um System V ipc innerhalb der Jail nutzen zu können musste man doch auch security.jail.sysvipc_allowed auf eins setzen, was dann auch den Zugriff erlaubt?

 

[Yamagi]

Sind denn Nullfs Mounts wenigstens sicher? Die habe ich immer ohne Bedenekein eingesetzt, wenn ich mit Jails hantiere.

Ja. Denn Nullfs ist ein neues Dateisystem, welches neue Vnodes generiert. Jeder Mount wird für sich allein betrachtet, an dem Ort, an welchem er sich befindet. Das gilt übrigens auch für Unionfs und Symlinks. Kritisch sind nur direkte Zugriffe und Hardlinks.

Zumindest sehen kann man sie aus der Jail, was ja streng genommen schon eine Verletzung darstellt. Um System V ipc innerhalb der Jail nutzen zu können musste man doch auch security.jail.sysvipc_allowed auf eins setzen, was dann auch den Zugriff erlaubt?

Dinge wie SysV-IPC, Rawsockets und so weiter müssen ja erst expiliziet durch den Nutzer erlaubt werden, da sie es halt ermöglichen, aus der Jail auszubrechen. Daher sollte man sie nur dann zulassen, wenn man nicht drum herum kommt und auch dann nur, wenn man weiß, was man dort treibt.
Prozesse des Host und anderer Jails sollte man eigentlich auch einer Jail heraus nicht sehen können. Zumindest kann ich es hier nicht, unter 6.2 und 7.0. Vielleicht ist das aber auch nur an security.bsd.see_other_uids gebunden. Der Host hingegen kann natürlich die Prozesse der Jails sehen, da er selbst keine JailID besitzt. Er kann sie sogar manipulieren, was allerdings keine Gefahr darstellen sollte, da ihr Jailzuordung nicht beeinflusst wird. Wenn das trotzdem quer im Magen liegt, einfach jexec(8) nutzen

 

[troll]

Hi Yamagi, ich meine nicht die Prozesse, sondern die shared memory Segmente:

[root@flegel ~]# ipcs
Message Queues:
T           ID          KEY MODE        OWNER    GROUP   

Shared Memory:
T           ID          KEY MODE        OWNER    GROUP   
m       196608            0 --rw-------   martin   martin
m        65537            0 --rw-------   martin   martin
m        65538            0 --rw-------   martin   martin
m        65539            0 --rw-------   martin   martin
m        65540            0 --rw-------   martin   martin
m        65541            0 --rw-------   martin   martin
m        65542            0 --rw-------   martin   martin
m        65543            0 --rw-------   martin   martin
m        65544            0 --rw-------   martin   martin

Semaphores:
T           ID          KEY MODE        OWNER    GROUP   

[root@flegel ~]# jexec 1 su -
jspr# ipcs
Message Queues:
T           ID          KEY MODE        OWNER    GROUP   

Shared Memory:
T           ID          KEY MODE        OWNER    GROUP   
m       196608            0 --rw-------     1001     1001
m        65537            0 --rw-------     1001     1001
m        65538            0 --rw-------     1001     1001
m        65539            0 --rw-------     1001     1001
m        65540            0 --rw-------     1001     1001
m        65541            0 --rw-------     1001     1001
m        65542            0 --rw-------     1001     1001
m        65543            0 --rw-------     1001     1001
m        65544            0 --rw-------     1001     1001

Semaphores:
T           ID          KEY MODE        OWNER    GROUP

 

[Yamagi]

Ach so, das erklärt einiges. Ja, also die IPC-Segemente kann er sehen. Aber ohne das das entsprechende Sysctl gesetzt ist, kann er sie nicht nutzen. Hmm... Ich muss das noch mal im Code anschauen.

 

[troll]

Ach so, das erklärt einiges. Ja, also die IPC-Segemente kann er sehen. Aber ohne das das entsprechende Sysctl gesetzt ist, kann er sie nicht nutzen. Hmm... Ich muss das noch mal im Code anschauen.

Ja, das ist so. Mein Einwand kam, weil die Frage oft mit einem Dienst verbunden ist, der Semaphoren nutzt - meist PG - und dafür muss dann SYS V ipc erlaubt werden. Und es wurde halt extra nach sm gefragt...

Summasumarum
security.jail.sysvipc_allowed=0 -> secure
else

 

[Yamagi]

Jau, ich habe es noch einmal nachgeschaut. Es ist wirklich wie du sagst, um SysV IPC nutzen zu können, muss das Sysctl gesetzt sein. Wird IPC erlaubt, kann man Daten aus dem Jail heraus in andere Jails oder den Host schreiben, woraus sich zumindest theoretisch ein Ausbruch konstruieren lässt. Wie praxisrelevant der nun ist wage ich nicht einzuschätzen, da mir die nötige Erfahrung fehlt.

 

[troll]

Für mich der grösste Wermutstropfen im Jailkonzept.
Die Möglichkeit eines Ausbruchs hängt von der verwendeter Software ab, die Möglichkeiteen für DoS-Atacken sind recht vielfältig.

Die bsdforen haben sich wirklich geändert. Vor ein paar Jahren hab ich mal Kloppe bekommen, weil ich mich aus diesem Grund gegen die Installation von Postgres in einer Jail ausgesprochen habe. Klasse, dass man inzwischen unaufgeregt über sowas diskutieren kann! :-)

 

[Columbo0815]

... weil ich mich aus diesem Grund gegen die Installation von Postgres in einer Jail ausgesprochen habe. Klasse, dass man inzwischen unaufgeregt über sowas diskutieren kann! :-)

Ich verstehe von der Diskussion eigentlich gar nichts, finde sie dennoch interessant. Ich brauche jetzt keine tiefgehende Erklärung (ich würde sie vermutlich nicht verstehen). Aber: ist denn eine Installation von Postgres die nicht in einer Jail läuft sicherer?! Oder meinst du damit, dass der "Sicherheitsgewinn" innerhalb der Jail nur "security by obscurity" ist und für dich deshalb nicht relevant?

 

[troll]

Darüber kann man vortrefflich diskutieren. Das Hauptproblem besteht _für mich_ darin, dass ich für eine PG-Installation innerhalb einer Jail System V IPC für alle Jails erlauben muss. Somit haben alle Jails Zugriff auf den Speicher der Sharedmemory-Segmente der anderen Jails _und_ des Hostsystems.

Aus jeder anderen Jail herraus kann dadurch PG angegriffen werden und natürlich auch jede andere Anwendung der Jails und des Hosts, die sm nutzen.

Im Falle PG halte ich so viel von der Software, dass ich es sinnvoller finde sie im Hostsystem laufen zu lassen, da ich die Wahrscheinlichkeit, dass jemand über pg Rootrechte erhält und somit die anderen Jails übernehmen kann geringer einschätze, als die Gefahr, die über ipc kommt.
Der Kernpunkt ist der, dass pg Semaphoren braucht, um zu laufen und ich für die Lauffähigkeit von pg in einer Jail die Kommunikation zwischen allen jails inc. Hostsystem erlauben muss.

 

[Yamagi]

Das Problem ist, dass Jails in ihrer derzeitigen Form ein reichlich primtiver Mechanismus sind. Technisch gesehen ist so ein Jail nichts anderer als ein "gepimptes" chroot, in die ursprüngliche Implementation von Poul-Henning Kamp hatte nur etwa 800 Zeilen C-Code. Mit der Zeit ist dies ein wenig gewachsen, aber es hat sich konzeptionell nichts geändert. Jails waren und sind lediglich ein Mechanismus, um Prozesse anhand einer Identifizierung in der Prozesstabelle in zueinander unabhängige Gruppen teilen zu können. Nicht mehr und nicht weniger. Dies Konzept berücksichtigt viele Dinge nicht, dazu gehören der Netzwerkstack und eben auch die SysV-Konzepte wie MSG (Messages), SHM (Shared Memory) und die SEM (Semaphoren). Auch die Integration der Jails on VFS ist, wie oben bereits gesagt, eher schlecht.

All dies ist bekannt und daher kommt nun im Zeitalter der Virtualisierung etwas neues: vimage. Ursprünglich war vimage eine Technik um den Netzwerkstack zu virtualisieren. Sprich mehrere Stacks auf einem System. Das war zu zeiten von 4.x. Man fand es interessant und die FreeBSD Foundation kaufte den Entwickler Marko Zec per Sponsoring ein, um das Konzept auf FreeBSD 6 zu portieren. Er tat es, aber die Netzwerkstack-Jungs wollten keinen Import des Ergebnisses, zu groß war die Angst etwas wirklich kaputt zu bekommen. Es folgte ein Review-Prozess, in dem sich andere Entwickler und auch Außenstehende zu Wort meldeten. Das waren Entwickler der Threading-Biblioteken (libthr), der Jails, usw. Gemeinsam entwickelten sie vimage weiter und es wurde viel mehr. Statt nur den Netzwerkstack zu virtualisieren, entwickelte es sich zu einem kompletten Framework für virtuelle Kernelsubsysteme.
Was im Moment in einem komplizierten Prozess in -CURRENT importiert und sicherlich erst in einigen Monaten vollständig enthalten sein wird, ist nur ein erster Ansatz. FreeBSD 8.0 wird vimage selbst enthalten, also virtualisierte Netzwerkstacks und das Framework dazu. Außerdem will man das von James Gritton geschriebene neue Jail-System importieren. Später, in weiteren Ausbauschritten, kann man dann aber praktisch alles virtualisieren. Das VFS, Ressourcenmanagement einbauen, den ganzen SysV-Kram... Die Möglichkeiten sind zumindest auf dem Papier praktisch unbegrenzt. Dazu kommt, dass der neue TTY-Layer eine ganze Reihe Probleme der jails entlich löst, z.B. die Zombie-Jails. ZFS wiederum erlaubt ein sauberes Dateisystemmanagement aus Jails heraus, dann sind dort die schon in 7.1 teilweise erhaltenen Arbeiten an NFS. vimages sind außerdem hierachisch, Jails in Jails werden möglich.

Kurz gesagt, dort ist viel im Kommen, was Jails grundlegend modernisieren wird. Was aber auch zu einem Problem führt, wie soll das ganze heißen? "vimage" wäre naheliegend, doch aus Marketinggründen wird das Ergebnis wohl wieder "Jails" heißen, im Userland repräsentiert durch neue Tools, welche jail(8), jexec(8), jls(8) und co ersetzen. Der Trend ist wohl, FreeBSD 8.0 mit alten Jails und vimage parallel auszuliefern und erst mit FreeBSD 9.0 in ferner Zukunft die alten fallen zu lassen,

EDIT:
Ein paar Info gibt es hier. Meines Wissen ist der Prozess im Moment irgendwo zwischen Stufe 2 und Stufe 3: http://wiki.freebsd.org/Image/Notes200808DevSummit

 

[troll]

Jepp und genau darauf warte ich auch schon brennend. Hier ist einer der Punkte, wo FreeBSD momentan den anderen Systemen hinterherhinkt. Allerdings gehöre ich auch zu den Leuten, die das KISS der Jails nicht missen möchten. Um mal eben nen kleinen Dienst einzusperren ist das verdammich gut!