Apache 2 chroot

[onkel-tobi]

Hallo zusammen,

bin gerade bei dem Versuch meinen Apache 2 zu "chrooten".
Bin dabei nach folgender Anleitung vorgegangen:

http://www.debian.org/doc/manuals/securing-debian-howto/ap-chroot-apache-env.de.html

Das Problem fängt dann beim editieren der /etc/init.d/apache2 an.
Da passt das nicht mehr, da alles mit Variablen gehandlet wird.
Kann mir da jemand Hilfe geben?

Vielen Dank im Voraus,

Tobi

[derRichard]

hi!

ja dann musst du halt schauen, wo die variablen angelegt werden und sie anpassen.

btw: warum machst du es nicht mit mod_security?

//richard

[nopes]

oder gleich virtualisieren, denn so der bringer ist eine chroot-Umgebung nicht (http://www.little-idiot.de/ChrootEntkommen.pdf)...

[onkel-tobi]

Hi,

danke für eure Antworten.
Ich werde denke ich eh nun eine xen VM erstellen.
Würdet ihr dann aufs chroot verzichten?

Gruß,

Tobi

[derRichard]

Hi,

danke für eure Antworten.
Ich werde denke ich eh nun eine xen VM erstellen.
Würdet ihr dann aufs chroot verzichten?


chroot ist kein sicherheits-feature.
und schon gar kein gefängnis.

als root kann man immer ausbrechen und als normaler user "sperrt" es auch nur auf dateisystem-ebene ein.

sicherheit durch eine vm ist auch so eine sache.
es gibt laufend lücken, dass man aus einer vm ausbrechen kann.
egal ob nun vmware, xen, kvm, etc...

hth,
//richard

[onkel-tobi]

ist schon klar. Eine 100%ige Sicherheit wird es im Internet eh nicht geben.
Wichtig ist denke ich, dass die security updates aktuell sind und man es vor allem script robotern nicht zu einfach macht.
Im Apache alle nicht benötigten Sachen abschalten, oder was schlägst du noch vor?

Tobi

[derRichard]

oder was schlägst du noch vor?


keinen webentwicker an das ding lassen. ;-)

meistens ist ein rottiges php-skript schuld wenn ein webserver aufgemacht wird.
aber du kannst beispielsweise php als cgi unter einer anderen userid laufen lassen.
dann kannst du auch mit selinux und ähnlichen geschützen arbeiten...


hth,
//richard

[nopes]

...
sicherheit durch eine vm ist auch so eine sache.
es gibt laufend lücken, dass man aus einer vm ausbrechen kann.
egal ob nun vmware, xen, kvm, etc...

Sicherheit kann sein ja, aber sie in keinem Fall schlechte als die von chroot. Der eigentliche Clou bei der Virtualisierung ist aber die leichtere wartung. Es ist halt "ein echter" Rechner, im extrem Fall Dienst=VM, als Admin nen Traum, kein nerviges anlegen von chroots mehr, kein kopfzerbrechen darüber, wie man updates vom Wirt in den Knast bringt... :) [aktuell wäre wohl KVM eine gute Wahl s.a. http://www.heise.de/open/artikel/Die-Woche-Xen-hat-KVM-vorbeiziehen-lassen-1261765.html]

Ansonsten, ein sehr schöner Leitfaden bzw. schöne Referenz zu sicherheitsrelevanten Dingen unter Linux ist hier: http://www.debian.org/doc/manuals/securing-debian-howto/

Ansonsten brain.bin ;)

[derRichard]

Sicherheit kann sein ja, aber sie in keinem Fall schlechte als die von chroot.


abgesehen davon, dass chroot per definition kein sicherheitsfeature ist, kann man mit virtualisierung sehr viel schlimmere sicherheitsprobleme bekommen.

das schlimmste was bei chroot passieren kann ist, dass man auf die äußeren pfade zugreifen kann.
der angreifer hat nach dem "ausbruch" aber noch immer die selben rechte/userid, etc...

bei einer virtuellen maschine ist es sehr oft der fall, dass man den hyperviser übernehmen kann und somit root-zugriff auf _alle_ anderen virtuellen maschinen bekommt...

//richard

[peppie]

bei einer virtuellen maschine ist es sehr oft der fall, dass man den hyperviser übernehmen kann und somit root-zugriff auf _alle_ anderen virtuellen maschinen bekommt...

//richard

Ich weiß das ist jetzt OFF-Topic, dennoch würde mich interessieren wie man aus einer virtuellen Maschine den Hypervisor übernommen können sollte.

Die VM simuliert doch eine Komplette Rechnerarchitiktur, so das man aus der virtuellen Maschine gar nicht sieht, dass es eine Virtuelle Maschine ist.

Meine frage dazu ist, wie ich von einer VM Zugriff auf den Hypervisor kriegen sollte, da die VM ja ein "insichgeschlossenes System" ist. Oder sehe ich das falsch?

[derRichard]

Die VM simuliert doch eine Komplette Rechnerarchitiktur, so das man aus der virtuellen Maschine gar nicht sieht, dass es eine Virtuelle Maschine ist.


was ist aber wenn dieser "simulator" fehlerhaft ist?

interessant sind auch angriffe auf die iommu:
http://theinvisiblethings.blogspot.com/2011/05/following-white-rabbit-software-attacks.html

hth,
//richard

[peppie]

was ist aber wenn dieser "simulator" fehlerhaft ist?

interessant sind auch angriffe auf die iommu:
http://theinvisiblethings.blogspot.com/2011/05/following-white-rabbit-software-attacks.html

hth,
//richard

Interessanter Ansatz, daran hab ich bisher gar nicht gedacht.

Danke für die Info.

Grüße
peppie

[derRichard]

so richtig lustig wird es, wenn man nichts-ahnend server in einer cloud mietet
und jemand anders über den hyperviser root-zugriff auf deine server bekommt.
ist alles schon vorgekommen...

//richard

[peppie]

so richtig lustig wird es, wenn man nichts-ahnend server in einer cloud mietet
und jemand anders über den hyperviser root-zugriff auf deine server bekommt.
ist alles schon vorgekommen...

//richard

Ich bin kein Fan der "Wolke", aber "lustig" ist es wohl immer wenn eine unberechtigte Person root-Zugang hat. ;)

[Iluminat23]

ich will diesen Thread hier nicht kapern, aber darauf musste ich einfach mal antworten.


oder gleich virtualisieren, denn so der bringer ist eine chroot-Umgebung nicht (http://www.little-idiot.de/ChrootEntkommen.pdf)...
was in dem link geschrieben ist, ist teilweise grober unfug. Man kann als normaler user keine SUID-root binaries auf einen server kopieren. beim anlegen der Datei verweigert das betriebsystem das setzen des SUID-Bits und dass die datei dem user root gehört.

und deinen schluß, dass chroot nicht so der bringer ist, lässt sich für mich aus dem link auch nciht ableiten. der author schreibt

Überhaupt sollte man alle Dämonen unter Linux generell in eigenen CHROOT() - Umgebungen laufen lassen.

achja, es wird auch oft angenommen, dass man aus virtuellen maschienen nicht ausbrechen könnte. dies ist auch eine grobe fehleinschätzung. somit müsste man deiner logik folgen zwingend jeden diest auf separater HW in speziell abgeschiermten netzen laufen lassen (ambesten ganze ohne netz ...)

so nun genug OT, wenn aber weiterer diskusionsbedarf besteht gibt es ja noch die möglichkeit einen separaten thread auf zu machen.

gruß iluminat23

[nopes]

...
und deinen schluß, dass chroot nicht so der bringer ist, lässt sich für mich aus dem link auch nciht ableiten. der author schreibt...


Ich wollte mit meiner Antwort nicht implizieren, dass chroot schlecht ist (der Autor, wie festgestellt, ja auch nicht)! Mir kommt es lediglich darauf an, dass man sehr ähnlich Ergebnisse (die Idee beim chrooten ist es ja, den Dienst bzw. das Programm vom restlichem System zu trennen) mit Virualisierung erreicht und das ist inzwischen halt leichter, was neben dem Admin auch den Chef freut, da weniger Zeit gebraucht wird; oder man wählt eine Distri, wo das chrooten zur Philosophie gehört. Meine Erfahrungen mit chroots unter Debian (damals 2.0 mit 2.2er Kernel), waren jedenfalls immer sehr fummelig und arbeitsaufwändig mit einem nur noch schwer warten baren Root-Käfig am Ende, weswegen ich die eher meide als liebe...

Alle anderen Aussagen kann bzw. möchte ich nicht bewerten; aber bitte auch dran denken, dass der Artikel aus 2.4er Zeiten stammt, k.A. ob das heute besser geworden ist, seiner Zeit war es so, das konnte man auch prima nachvollziehen, ist ja haarklein beschreiben. Bitte auch nicht Virtualisierung mit CC (Cloud Computing - gegen das auch ich Abneigungen habe) vergleichen, das hat nun wahrlich nicht viel gemeinsam.

[kreol]

Ich kenne chrooting unter 2.2 nicht und unter 2.4 nur wenig. Unter 2.6 ist es aber nun wirklich kein Hexenwerk, solange man den Überblick behalt, was in den jail rein muss.

Bei anwendungsübergreifenden Apps (man denke z.B. an Mailserver) wird es tatsächlich etwas fummelig. Da ist eine Virtualisierung aber auch nicht immer die Endlösung. a) Imho nicht wesentlich leichter zu konfigurieren und b) Ressourcenhungrig.

Einen Tod muss man halt sterben...

Kreol