Re: jail und Resourcen

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.

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

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

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

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

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

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.

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

> > > Filesystem browsen, reicht unter Umständen auch eine restricted
> > > shell.
> >
> > die sich ja durchaus auch im jail anbietet.
>
> Ja, aber man muß sich das doch einmal genauer ansehen. Auf einen
> Webserver gehören HTML Dateien, die sowieso veröffentlicht werden
> sollen. Ob jemand nun via Webbrowser surft oder ls bevorzugt ist
> doch nur eine Geschmacksfrage.

die sich in der Praxis selten stellt, weil der Wunsch, eine z.B. auf cd,ls und cat
beschränkte Shell zu bekommen selten gestellt wird.
Ich würde auch nicht soweit gehen, dass man mit jail allgemein shell-Zugang
an jedermann delegieren kann, auch wenn das durchaus gemacht wird.

> Natürlich muß das System und der
> Host geschützt werden und selbstverständlich gehört die Datenbank
> mit den Bestell- und Kundendaten nicht auf den Webserver

eine Partitionierung in Hardware ist natürlich immer die beste Lösung,
immer vorausgesetzt das Budget gibt's her.

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

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

Grüße

/ch

-- 
Wieviele Mitarbeiter von Microsoft benoetigt man fuer das auswechseln
einer defekten Gluehbirne? Keine, Microsoft erklaert die Dunkelheit zum
Marktstandart.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message