Re: Jail Konzept

At 18:19 08.02.2003 +0100, you wrote:
>Andreas Braukmann wrote:
>>On Sat, Feb 08, 2003 at 05:09:18PM +0100, Gistolero wrote:
>>
>>>>Also ich habe mir ein ~/bin/sysupdate script erstellt, dass nach einem
>>>>make buildworld die benötigten Dateien in die Jails installiert.
>>>>Dadurch sind die Jail-Binaries vom System unabhängig. Kann man sehen,
>>>>wie man will, aber ich denke, die "Verschwendung" von 200K auf einer
>>>>40G Platte ist echt vernachlässigbar.
>>>
>>>Dann hast Du weiterhin das Problem, dass Du bei jeder neuen Jail
>>>anfaengst, die Lib Abhaengigkeiten zu verfolgen.
>>Diesen Einwand habe ich jetzt nicht verstanden.
>
>Ich auch nicht. Ich verwende eine eigene make.conf für die Jails, die z.B.
>nicht alle Compiler enthalten, kein Bind, ... - Und ich mounte alle /bin,
>/usr ... für alle Jails von einem Filesystem, allerdings RO.

Also nochmal: Ich denke es ist einleuchtend, dass eine "perfekte"
Chroot/Jail Umgebung wirklich _ausschliesslich_ die Dateien und
Verzeichnisse enthaelt, die von dem jeweiligen Dienst benoetigt werden. So
eine Umgebung zu erstellen, ist relativ aufwendig, da man genau ermittlen
muss, welche Binaries und Libs von den Programmen benoetigt werden. Das
habe ich gemeint und nichts anderes! Ich bin nicht davon ausgegangen, dass
man ein eigenes (von mir aus auch durch make.conf eingeschraenktes) System
innerhalb der Jails installiert.

>>>entsprechenden Verzeichnisse aus dem System heraus in alle Jails mounte,
>>>bin ich mir hundert prozentig sicher, dass ich ueberall die gleiche
>>>Umgebung habe.
>>Es stellt sich die Frage, ob man wirklich in jedem Jail die gleiche
>>Umgebung haben moechte.
>
>Also ich nicht - daher hat jedes Jail sein eigenes etc/-verzeichnis, die
>ich mit mergemaster problemlos aktuell halten kann. Da ich nicht jeden Tag
>update, hält sich der Aufwand auch in Grenzen.

Normalerweise haben alle Jails eine identische Basis. Wie Du selbst
schreibst mountest Du /bin, /usr, ... aus Deinem eigenen Jail-Filesystem.
D.h. in allen Jails sind diese Verzeichnisse gleich. Das meine ich mit
gleicher Umgebung. Das mit der eigenen /etc ist mir hingegen zu
umstaendlich. Genau darum geht es mir naemlich, dass ich keine Lust habe
auf allen Server x-mal mergemaster laufen zu lassen. Da ist meiner Meinung
nach ein union Mount, ob nun vom Host-System selbst oder von einem
Master-Jail die adminfreundlichere Wahl.

[...]

>>>>>Nachteile dieses Verfahrens:
>>>>>- Ein Angreifer, dem es gelingt in ein Jail einzudringen, hat alle
>>>>>Binaries des Systems zur Verfuegung.
>>Ich wuerde in einem Jail niemals Teile des Host-Systems zur Verfuegung
>>stellen. Das Host-System ist ausschliesslich fuer den Administrator
>>erreichbar (nach Moeglichkeit ueber einen dedizierten Zugang [serielle
>>Konsole, oder ein Interface in einem Admin-LAN]).
>>Die Binaries, die in den Jails (egal, ob ueber NFS-RO-Mounts oder Hard-
>>links oder, oder) verwendet werden sollen, liegen in einer Master-Jail-
>>Installation.
>
>Genau. Das Host-System liegt auf einer privaten Adresse und die
>installierte ipf-Konfiguration lässt von ext->privat oder ext->local nix
>durch. Dadurch kann dann auch niemand irgendwelche NFS-Bugs ausnutzen,
>wenn er/sie das Jail gehackt hat.

Das Ganze mal zusammengefasst, wendet Ihr im in etwa das gleiche Konzept
an, wie ich es vorgeschlagen hatte, bis auf folgende Unterschiede:

- Ihr legt eine Master-Jail an, von der Ihr anschliessend Eure
Verzeichnisse mountet.
- Um flexibel in der Konfiguration zu sein, werden Config-Verzeichnisse wie
/etc fuer jedes Jail einzeln erstellt.

Auch wenn dadurch natuerlich das Host-System nochmal einen Schritt weiter
isoliert und somit an Sicherheit gewonnen wird, so gehen diese Massnahmen
doch auf Kosten der Administrierung. Mein Ziel ist es, ein relativ sicheres
System aufzubauen, das mit _minimalem_ Aufwand administriert werden kann.
"Mehr" Sicherheit ist immer moeglich, aber irgendwo muss jeder sein eigenes
Ziel definieren. Dass Euer Fokus eindeutig im Hardcore-Security Bereich
liegt, habe ich inzwischen verstanden :-)

Gruss,

Simon

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sat 08 Feb 2003 - 20:40:21 CET