Re: Jail Konzept

From: Oliver Fromme <olli(at)secnetix.de>
Date: Sat, 8 Feb 2003 23:12:46 +0100 (CET)

Ich antworte mal auf mehrere Mails gesammelt, um die Mail-
Zahl ein wenig in Grenzen zu halten ...

Gistolero <gistolero(at)gmx.de> wrote:
> At 16:23 08.02.2003 +0100, you wrote:
> > 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.

Ja, davon gehe ich grundsätzlich erstmal aus. Wie gesagt,
diese Thema hatten wir gerade kürzlich in einem anderen
Thread.

Man gewinnt keine reale Sicherheit dadurch, daß man das in-
stallierte System mühselig auseinandersortiert. Man han-
delt sich damit nur unnötigen Aufwand ein.

> 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.

Das kannst Du ja durchaus, wenn Du das möchtest (Sharing
per Hardlinks, Loopback-NFS, vn-Filesystem o.ä.).

Wenn ich nur ein oder zwei Jails brauche, würde ich auf
das Sharing pfeifen und einfach in beide Jails ein »make
installworld« hineinmachen. In dem Fall ist auch die
Platzersparnis ziemlich Wurscht: Ein FreeBSD-Basissystem
ohne die Development-Teile belegt gerade mal 50 Mbyte.

Wenn ich dagegen auf einem Rechner fünfhundert Shell-
Accounts habe, die voneinander separariert sein sollen,
würde ich fünfhundert Jails aufsetzen und ein Sharing der
Binaries machen (in dem Fall am besten mit Hilfe von Hard-
links, da dies aus Sicht des VM-Systems günstiger ist).

> wahrscheinlich Geschmackssache.

Eine Frage der Anforderungen.

> > > [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.

Das kann ein Trugschluß sein. Siehe jener Thread von vor
ein paar Tagen.

Wenn man mühselig Binaries, Libs und sonstige Dateien in
einem Jail auseinandersortiert, macht man nur sich selbst
(bzw. den anderen Admins) das Leben unnötiger schwerer,
ohne einen potentieller Angreifer wirklich wirksam aufzu-
halten. Man erschwert sich die Pflege der Systeme, und
man vermehrt die potentiellen Fehlerquellen verlängert die
Downtime im Falle von Störungen, weil man sich bei jedem
Problem fragen muß: Hm, was fehlt denn jetzt wieder? Und
beim nächsten Update kann das wieder ganz was anderes sein.

> > 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.

Ich bin der Meinung, daß man den Aufwand besser an anderen
Stellen investieren sollte, beispielsweise in ein verläß-
liches IDS.

> > 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?

Prinzipiell hast Du recht (wenn Du die Sache mit dem read-
only-NFS meinst).

Man sollte sich nur von der Annahme lösen, daß, wenn man
z.B. den Compiler löscht, ein Eindringling nichts mehr com-
pilieren kann. Oder daß er nichts mehr editieren kann,
wenn man vi und ed löscht. Oder daß er keine Dateien über-
tragen kann, wenn man scp/rcp/ftp etc. löscht. Oder daß er
keine Shellkommandos ausführen kann, wenn man sh und csh
löscht. Und so weiter. Das sind nämlich alles gefährliche
Trugschlüsse.

Angreifer finden immer wieder Möglichkeiten, an die ein
Admin nicht gedacht hat. Es ist nur ein Frage des Ein-
fallsreichtums, und/oder der Hartnäckigkeit. Daher sollte
man sein Sicherheitskonzept auf Dingen aufbauen, die sich
leichter unter Kontrolle bringen und festnageln lassen.
Dazu gehört ein unabhängiges IDS (Netz- und Host-IDS),
remote Logging, ein geeigneter Firewall-Setup und so wei-
ter. Und ein Plan, welchen Umgebungen man trauen kann und
welche man potentiell als Feindesland betrachten muß.

> [...]
> Alternativ kannst Du natuerlich ein komplettes System in jedes Jail
> installieren. Aber ich frage mich wirklich, warum ich jedes Binary x-fach
> auf einem System installieren muss, wenn es auch anders geht.

Wie gesagt: Eine Frage der Anforderungen. Wenn man nur
zwei oder drei Jails braucht, ist das einfacher aufzuset-
zen. Der zusätzliche Plattenplatz ist vernachlässigbar.

> Wenn ich die
> entsprechenden Verzeichnisse aus dem System heraus in alle Jails mounte,
> bin ich mir hundert prozentig sicher, dass ich ueberall die gleiche
> Umgebung habe.

Das kannst Du auch sein, wenn Du ein installworld in den
Jails machst.

> [...]
> Natuerlich wird es im wirklichen Betrieb nicht RW gemountet. Dient nur zum
> Installieren, dann fliegt RW wieder raus.

Überflüssige Komplizierung und mögliche Fehlerquelle, IMO.

> [...]
> At 18:19 08.02.2003 +0100, you wrote:
> >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.

Nein, finde ich überhaupt nicht einleuchtend. Was ist da-
ran perfekt? Riesenaufwand ohne realen Nutzen.

> > 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.

Muß man auch nicht -- das macht man nur einmal.

Typischerweise unetrscheiden sich die Jails, wenn man viele
davon hat, nur durch wenige Kleinigkeiten. Auf der erwähn-
ten Shell-Box zum Beispiel hat jedes Jail eigene passwd-
und group-Dateien sowie ssh-Hostkeys, aber sonst sind die
identisch.

Du kannst auch /etc als Teil des read-only-Mounts (oder was
auch immer) nehmen, und die Dateien, die variabel sein
müssen, per Symlinks woanders hin verlegen.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"All that we see or seem is just a dream within a dream" (E. A. Poe)
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 - 23:12:49 CET

search this site