Re: Re[1]: jail und Resourcen

From: Bernd Walter <ticso(at)cicely5.cicely.de>
Date: Sun, 8 Sep 2002 18:37:29 +0200

On Sun, Sep 08, 2002 at 06:03:03PM +0200, Clemens Hermann wrote:
> Am 08.09.2002 um 16:02:37 schrieb Matthias Teege:
>
> Hallo Matthias,
>
> > Ganz genau. Bei der ganzen Jailerei sollte man nämlich sehr genau
> > wissen, was man eigentlich vor wem beschützen möchte. Wenn ich den
> > Apache Webserver für nicht vertrauenswürdig halte, sollte ich ihn
> > nicht einzetzen.
>
> nach der Logik sollte man überhaupt keine Computer Verwenden, da kein
> System/Programm grundsätzlich vertrauenswürdig ist.
> 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.

> > Im Falle eines Sicherheitsloches muß ich ihn sowieso
> > in allen 50 Jails deaktivieren.
>
> 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
> und per NFS in die jeweiligen jails zu mounten. Neben der enormen Platzersparnis
> musst Du real auch nur ein jail patchen, wenn was auftritt.

Die Platzersparniss hast du »nur« auf der Platte, was zwar bei einer
großen Jailanzahl nicht unwesentlich ist, aber die Speicherersparrniss
bei Hardlinks durch shared memory ist bedeutender.
Wir reden hier immerhin von einigen hundert kByte pro Apache.
Meiner (ohne php) ist ca 400k groß - macht auf 50 Jails schon aleine
25M aleine dafür - der Workset mag geringer sein, aber mit PHP gleicht
sich das schnell wieder aus.
Ja - man braucht nur einmal zu aktualisieren, wobei man natürlich auch
das Kopieren automatisieren sollte - sofern man denn wirklich Kopien
haben muss.

> > Möchte ich nur verhindern, daß die
> > Kunden während eines Remote Logins oder Dateiuploads durch das
> > Filesystem browsen, reicht unter Umständen auch eine restricted
> > shell.
>
> die sich ja durchaus auch im jail anbietet.

Naja - Shellzugriff sollte man nun wirklich in ein Jail packen.
restricted Shells als Schutz wirken auf mich ein wenig dünn.

> > Für diesen Fall muß der Webserver nicht in einer Jail laufen
> > und ich muß nicht versuchen, die vorhandenen Features durch Workarounds
> > wieder herzustellen.
>
> Welches feature funktioniert beim apache im jail nur mit workaround und auf
> dem host hingegen direkt?

Z.B. die besagten virtual hosts mit Einzel-IP.
Du musst dafür dann einen Proxy laufen lassen und dieser schiebt dann
aufwendig die Daten von der Platte in den Kernel, von dort zur
Anwendung und von Anwendung in den Kernel, per TCP/IP zur nächsten
Anwendung, zurück in den Kernel und dann erst aufs Netz.
Die Schritte der ersten Anwendung lassen sich zwar dank sendfile & Co
reduzieren - der Rest jedoch nicht.
Wenn hingegen alle einzelne IPs haben ist das auch bedenklich.
Schließlich hat jeder für sich ein Verbindungslimit.
Angenommen alle 50 lassen 100 Verbindungen zu, dann kann ich als
DoS aleine damit 5000 Verbindungen aufmachen und die Maschine stark
belasten.
Bei gängigen Konfigurationen entspricht 1 Connect einem httpd.
5000 aktive httpd sprechen für sich.

> der apache ist aus diversen anderen Gründen noch ein Kandidat für jails, so ist
> jail z.B: auch sehr wirkungsvoll, um Leute daran zu hindern per cgi/php etc.
> auf dem Rechner oder auch in Webverzeichnissen anderer Benutzer zu stöbern.

Ja - wobei meiner Erfahrung nach die wenigsten diese Features benötigen
und man dann auch nur diese in ein Jail packen sollte.

> > Ob ein Angreifer, durch die Ausnutzung eines
> > Loches nun den Webserver innerhalb oder außerhalb einer jail zum
> > Absturz bringt, dürfte egal sein.
>
> 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).

Ja - ist ja ohne Jail auch nicht besser.

-- 
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
Received on Sun 08 Sep 2002 - 18:37:45 CEST

search this site