Re: jail und Resourcen

Am 09.09.2002 um 03:34:22 schrieb Peter Ross:

Hallo Peter,

> Restricted shells etc. sind mir dafuer zu schwach, vorallem wenn die
> Kunden Hosting inklusive Skripts wollen.

sofern Du Dinge wie php, cgi etc. anbietest habe ich bisher nichts gefunden,
was das Problem ähnlich zufriedenstellend wie jail löst. Der secure-mode bei
php und SUexec Wrapper für cgi o.ä. sind immer einzelne Lösungen für jedes
Problem und jede neue Funktion, jedes neue Modul erfordert neue Überlegungen,
neuen Aufwand, neue Workarounds und birgt neue Risiken.
Die potentielle Gefährdung des Hosts macht Dich auch weit weniger flexibler,
auf spezielle Wünsche eingehen zu können.
Mit Jail hast Du mehr Möglichkeiten als mit virtuellen Hosts, bei einzel-
nen Websites problematischere Software/Module/Konfigurationen einzusetzen, die
dann eben nicht gleich den ganzen Host gefährden, sondern nur diese eine Site.

> Gerade der Apache ist in seiner Konfiguration sehr komplex und es ist
> sehr leicht moeglich, da etwas zu uebersehen. So halte ich es fuer besser,
> ein zuverlaessiges, uebersichtliches Tool wie Jails zu konfigurieren (evt.
> tut es aber auch eine chroot-Umgebung, das sei hier auch erwaehnt)

wobei Du hier allerdings Gefahr läufst, in allen jails den selben
Konfigurationsfehler zu machen.

> Die Betriebssystem-Sicherheit ist nicht esoterisch und ein
> wesentlich besserer Schutz als Restriktionen auf Applikationsebene. Ganz
> sicher "verhaeltnismaessig" eingesetzt.

Der initiale Aufwand bei Verwendung von jails ist natürlich nicht zu
unterschätzen und für billiges Massenhosting aufgrund des erhöhten
Ressourcenverbrauchs sind jails wohl nicht der Weisheit letzter Schluss.
Für die von Dir angesprochenen 50 vhosts
ist es aber sicher eine Überlegung wert, sofern Du pro vhost einige kbyte oder
je nach Verwendung von Modulen MByte RAM investieren kannst.

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