Re: Jail Konzept

At 16:23 08.02.2003 +0100, you wrote:
>Gistolero <gistolero(at)gmx.de> wrote:
> > [Jails per read-only-NFS replizieren]
>
>Das wurde hier schon mehrfach mit seinen Vor- und Nachtei-
>len diskutiert. Das Prinzip ist ja auch recht naheliegend.
>Ich verwende es auf mehreren Servern.
>
>Eine verwandte Alternative wäre, anstelle von NFS vn-Nodes
>zu verwenden (bzw. md unter FreeBSD 5). Hat den Vorteil,
>daß der NFS-Overhead wegfällt -- obgleich dieser bei Loop-
>back-NFS recht gering ist --, allerdings braucht man ten-
>denziell mehr RAM, da kein Sharing zwischen den Textpages
>der verschiedenen Jails stattfindet.

Um solche Hinweise und Alternativen zu bekommen, habe ich an die Liste
geschrieben :-)

>Am Ende kommt es immer auf den konkreten Einsatzzweck und
>die Anforderungen an, um zu entscheiden, was für ein Kon-
>zept man verwendet.
>
> > - Die Einrichtung der Jail Umgebung ist relativ aufwendig. Man verbringt
> > viel Zeit damit, Lib-Abhaengigkeiten etc. zu verfolgen.
>
>Naja, wenn man das geschickt anfängt und die Möglichkeiten
>nutzt, die FreeBSD bietet, kann man das auch recht einfach
>machen, ganz ohne Sharing via NFS oder was auch immer. Bei
>einem Update des Gesamtsystems macht man einfach ein »make
>installworld« in jedes Jail hinein. Ebenso bei den Ports:
>Entweder installiert man jeden Port per $PREFIX in jedes
>Jail hinein, oder (weil $PREFIX leide rnicht bei allen
>Ports funktioniert) man macht bei jedem Port einmal »make
>package« und in jedem Jail dann »pkg_add«. Das alles läßt
>sich mit einem einfach Skript soweit automatisieren, daß
>man es bei einem Update nur anstoßen muß, und alles andere
>läuft von alleine. Das ist weder aufwendig noch komplex.
>FreeBSD hat ja bereits das notwendige Framework.
>
>Das Platzargument bleibt natürlich bestehen. Wie gesagt,
>es kommt auf die jeweiligen Anforderungen an.

Du gehst davon aus, immer ein komplettes System in jedes Jail zu
installieren. Wie ich bereits in meiner vorherigen Mail schrieb, sehe ich
keinen Sinn darin, die gleiche Datei mehrfach auf einem System zu
installieren, wenn ich Sie auch problemlos sharen kann. Aber das ist
wahrscheinlich Geschmackssache.

> > [NFS]
> > Nachteile dieses Verfahrens:
> > - Ein Angreifer, dem es gelingt in ein Jail einzudringen, hat alle
> Binaries
> > des Systems zur Verfuegung.
>
>Hat er ohnehin, ist also eher kein Argument.

Ich bin davon ausgegangen, dass nur die vom entsprechenden Dienst
benoetigten Dateien innerhalb des Jails installiert werden. Dann hat der
Angreifer nur wenige Binaries zur Verfuegung.

[...]

> > - Da permanent NFS Zugriffe erfolgen, benoetigt man ein entsprechend
> > performantes System.
>
>Nö. Probier's mal aus. Der Overhead von Loopback-NFS ist
>sehr gering, und es skaliert sehr gut. Auch tausend Mounts
>auf einem Rechner sind kein Problem.

Hoert sich gut an :-)

> > Vorteile des Verfahrens:
> > - Die Einrichtung von Jails beschraenkt sich auf das Anpassen eines
> Skripts
> > und die Installation der benoetigten Ports. Es muessen keine
> > Lib-Abhaengigkeiten etc. verfolgt werden.
>
>Um ganz ehrlich zu sein, das würde ich in keinem Fall
>machen, egal ob mit oder ohne NFS. Ich würde in ein Jail
>grundsätzlich ein komplettes System hineininstallieren,
>dann muß man sich um Libs keine Gedanken machen. Ich
>würde höchstens (per Skript) ein paar Dinge entfernen,
>von denen ich weiß, daß sie keinesfalls gebraucht werden,
>z.B. überflüssige Locales und TZs, die Compiler-Toolchain,
>Includes, statische Libraries, perl u.ä.

Sinnvoll. Einige Leute aus meinem Umfeld betreiben da aber deutlich mehr
Aufwand.

> > - Fast alle Dateien und Verzeichnisse werden read-only gemountet.
>
>Das kann man auch ohne NFS. Und davon abgesehen gibt es
>auch noch chflags + Secure-Level. Das hatten wir hier
>neulich schonmal ...

Ok, auch wenn es je nach Einsatzgebiet vielleicht bessere Loesungen als das
vorgeschlagene Verfahren gibt, stelle ich aber fest, dass ich keinen groben
Denkfehler in Bezug auf Sicherheit gemacht habe. Oder?

Auf jeden Fall danke ich Euch schon mal fuer die Anregungen.

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 - 17:25:06 CET