Re: jail und Resourcen

On Sun, Sep 08, 2002 at 11:59:20PM +0200, Clemens Hermann wrote:
> Am 08.09.2002 um 19:46:48 schrieb Matthias Teege:
>
> Hallo Matthias,
>
> > Ich bin der Meinung,
> > daß man die Installation komplizierter Konstrukte zur Übertünchung
> > der Schwachstellen eines Programms zu Gunsten einer einfachen
> > Software vermeiden sollte.
>
> immer vorausgesetzt diese Alternative steht überhaupt zur Verfügung oder
> lässt sich mit dem vorgegebenen Budget/Zeirahmen realisieren.

Manchmal ist ja auch vollkommen OK mit Kanonen auf Spatzen zu schiessen.

> > Vermutlich benötigen die meisten Kunden
> > überhaupt kein PHP, Perl, SSL, FastCGI oder CGI.
>
> das halte ich für unwahrscheinlich. Es lässt sich heute wohl schwer vermitteln,
> warum der Einsatz von PHP nicht möglich ist.

Das steht da doch gar nicht.
Natürlich kann man PHP machen und mitunter auch im Jails, wenn mans
braucht.
Aber die Kunden, die kein CGI oder PHP brauchen kann man aussen vor
lassen - die Maschine wirds einem mit Performance Danken.

> > Beim Einsatz einer
> > dem konkreten Problem angemessenen Software, kann ich auf jails
> > verzichten.
>
> man kann grundsätzlich immer auf Jails verzichten, wie auf jede andere Art
> von Sicherheitskonzepten. Das ist nur eine Frage der persönlichen
> Schmerzgrenze und es gibt einige Situationen, bei denen sich die Benutzung
> von Jails absolut anbietet.

Und der Verhältnissmäßigkeit.

> > > Imho ist jail duchaus recht gut dazu geeignet, um u.a. Software der man
> > > nicht ganz vertraut (und der apache gehört sicher nicht als letzter in
> > > diese Kategorie) vom host zu trennen.
> >
> > Ja, Du schließt Software der Du nicht traust mit mehr Software der
> > Du nicht trauen kannst ein
>
> falsch. Der Implementierung von jail traue ich um Größenordnungen mehr als
> der Implementierung des apache.
> jail ist 49 Zeilen C-Code lang, abzüglich der Kommentare, zzgl. der includes. Weiterhin
> wurden afaik ca. 200 Zeilen im Systemcode geändert, was aber unabhängig davon ist,
> ob ich jail verwende oder nicht.

Wow - 249 Zeilen Flickwerk an etliche tausend Zeilen Kernelcode.
Meist du nicht, das da mal schnell was übersehen werden kann?
Du musst bei der Komplexität nicht die Änderung, sondern das Gesammt-
werk betrachten.

> Wenn Du Dir dahingegen die Codebase vom apachen nebst Modulen anschaust, ist
> allein durch die Codemenge klar gesagt, wo langfristig mehr Sicherheitsprobleme
> zu erwarten sind.

Mag ja sein, aber den hast du ja trotzdem noch.
Du magst argumentieren, daß ja nur ein Jail betroffen ist, aber der
Apachebug wäre ja dann identisch in allen Jails vorhanden.

> auch bei Betrachtung der Sicherheitsgeschichte wird klar, dass jail weitaus
> vertrauenswürdiger ist als der apache (von jail wurde imho bis heute kein
> Problem bekannt, beim apachen sieht das anders aus, liegt wie gesagt zum Teil
> in der Natur der Sache).

Die Software ist immer noch zusätzlich + Workarounds.

> > und verwendest weitere nicht vertrauenswürde
> > Software um die Features der ersten Software wieder herzustellen.
> > Jetzt mußt Du Bugtraq nicht nur nach Exploits für Apache und PHP
> > filtern sondern auch noch nach jail, nfsd, portmap, mountd und
> > rpc.statd.
>
> so gesehen sollte man keine Paketfilter einsetzen, weil sie neben der
> möglichen zusätzlichen Sicherheit zwingend auch ein Risiko mit sich
> bringen.

Packetfilter benutzt man oftmals sowieso nur um Mängel dahinter zu
verbergen.
Wenn ich einen Server betreibe, dann sind die Services in der Regel
öffentlich, warum sollte ich dann also einen Packetfilter davorsetzen?
Für eine ordendlich aufgesetzte Maschine macht auch ein Packetfilter
keinen Sinn, sondern erhöht nur die Ausfallwahrscheinlichkeit.

> da portmap/mountd/nfsd sowohl als server, als auch als client _nur_ auf dem host
> laufen ist das zusätzliche Risiko sehr gering, da der host ja (dank jail)
> von aussen nicht direkt erreichbar ist.

Das die von außen nicht ereichbar sien müssen ist klar, aber wieso das
der Verdienst vom Jail ist leuchtet mir nicht ein.

> > > nicht unbedingt. Wenn Du wirklich 50 Jails für apache Webhosting einsetzt,
> > > wäre es weitaus einfacher, große Teile des userlands nur einmal vorzuhalten
> >
> > Das ist eine rethorische Aussage keine technische. :-)
>
> nein
>
> > Fakt ist,
> > Du fährst die Software runter, mit oder ohne jail. Wäre das Ziel
> > des Angreifers, den Service Deiner Kunden lamzulegen, hätte er es
> > in diesem Moment erreicht.
> > Löse das Problem!
>
> wenn Du keine Jails verwendet, hat er evtl. sogar ALLE dein 50 vhosts
> geschossen, da ja nur ein apache läuft. Bei Jails bleibt der Schaden auf die
> angegriffenen jails begrenzt.

Die Ansicht teile ich nicht.
Wenn ich einen Apache abschiessen kann, dann bestimmt auch alle
anderen - ist ja die gleiche Software in gleicher Umgebeung.
Aber das ist auch nicht das Risiko, da der Apache forkt und man
bestenfalls einen Child abschiesst.
Dummerweise ist das Ergebniss eine erhöhte Last, die auf der gesammten
Maschine zu spüren ist.
Und das, obwohl die Maschine sowieso schon durch die jails stärker
belastet ist.

> Die Problemlösung ist bei Verwendung eines Jails mitnichten schwieriger oder
> sonst mit Nachteilen behaftet. Du musst mit und ohne jail den Webserver für
> eine gleich lange Zeitspanne deaktivieren und einmal patchen.
>
> > > und per NFS in die jeweiligen jails zu mounten. Neben der enormen Platzersparnis
> > > musst Du real auch nur ein jail patchen, wenn was auftritt.
> >
> > Ja, das genau meine ich mit zusätzlicher Komplexität.
>
> ein lokaler NFS mount? Es hat niemand behauptet, dass jails einfach zu benutzen
> sind, aber der meist mäßige Aufwand lohnt sich in vielen Fällen.

Ich sehe den Nutzen eher in den wenigsten Fällen.
Ich habe schon FreeBSD Maschinen mit einigen tausend virtuellen
Servern konfiguriert - mit Jails wäre die Hardware erheblich teurer.
Den Preis für den IMHO immer noch fraglichen Aufwand musst du dem
Kunden gegenüber erst mal argumentieren.

> > aber einen
> > wirklich sehr großen Teil kann man mit Benutzern, Gruppen und Flags
> > abdecken. Wie schützen sich die Kunden denn vor dem Systemadministrator?
>
> garnicht. Bei Unix (und Windows und den meisten anderen) gibts omnipotente superuser,
> sie können per Definition alles. Das macht es schwierig, mit einem Sysadmin zu arbeiten,
> dem man nicht traut, zumal ja er Mechanismen installieren müssen, die den
> Benutzer vor ihm schützen, da beisst sich die Katz' in Schwanz.

Das ist dem Kunden mitunter egal - er kann eh nichts kritisches
deponieren, da er die Vertrauenswürdigkeit der Admins meist nicht
einschätzen kann.
Fazit: Wenn jemand anders an die deponierten Daten kommt ist das
für den vorsichtigen Kunden eh kein Problem, da er das Risiko ja
Prinzipbedingt sowieso mitgekauft hat.
Ich kenne im Gegenteil eher den Fall, daß man Performance ausreizen
sollte, da das den Kunden als erstes auffällt - ein Jail ist da
kontraproduktiv.

> > > jail erhebt ja auch nicht den Anspruch, vor "Abstürzen" zu schützen, sondern
> > > lediglich einen Teil des Systems vom Rest abzuschotten (oder eher umgekehrt).
> >
> > Selbstverständlich schützt eine jail nicht vor Abstürzen. Genau das
> > ist doch mein Argument.
>
> verstehe ich leider nicht. Weil ein jail nicht auch noch vor Abstürzen schützt (was es
> auch nie wollte :) setzt Du es nicht ein?
>
> > Die jail ist aber die letzte (bzw. die
> > erste, je nach Blickrichtung) Linie die man einziehen sollte. Vorher
> > sollte man seine Hausaufgaben gründlich erledigen
>
> ack. Ein Jail ist natürlich nur eine zusätzliche Schutzschicht.
>
> > und so ein System
> > ist auch ohne jail schon eine harte Nuß.
>
> Selbst wenn man ein System perfekt plant und alles up2date hält, kann man kaum ausschliessen,
> dass ein exploit vor dem Patch bekannt wird und dann hat man ohne jail verloren.
> Auch ist mir kein ähnlich schöner Weg bekannt, ein System für verschiedene Zwecke zu
> partitionieren.

Siehe oben, ob 50 Jails oder eine »normale« Maschine gehacked werden
macht keinen wirklichen Unterschied.

-- 
B.Walter              COSMO-Project         http://www.cosmo-project.de
ticso(at)cicely.de         Usergroup           info(at)cosmo-project.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message