Kannst du per "chroot" auch unterschiedliche Betriebssystem laufen lassen? Kannst du per "chroot" ohne Gefrickel ohne persistente Arbeitsumgebung z.B. für das Onlinebanking einrichten? Kannst du per "chroot" eine Umgebung einrichten, die nur einen bestimmten Teil der Resourcen des Systems (z.B. RAM) zugewiesen bekommt? usw.
Das wir uns nicht falsch verstehen :
"chroot" ist nützlich und für viele Fälle absolut ausreichend, aber eine VM kann trotzdem deutlich mehr.
Mh, dazu muss ich ja nun mal etwas sagen. chroot ist nicht für Sicherheit da und hat nichts mit BSD oder Solaris chroot zu tun. Man kann innerhalb einer Applikation das chroot verlassen, also auf das Haupt / zugreifen. Ich sehe das als tödlich an. Xen&Co sind idR zwar auch nicht auf Sicherheit getrimmt und ich rate mal, das uns da noch einiges erwartet, aber die Basis Hüuerde liegt erstmal hoeher.....nunja, es gibt andere Gruende chroot einzusetzen.
Bei bedarf kann ich nochmal eine Quelle suchen. Ich meine in der KernelDoco steht dazu etwas.
Gleichzeitig sehe ich es aber auch so, das Virtualisierung da der falsche Ansatz ist. wahrscheinlich wäre so etwas wie vserver oder ähnliches der bessere Ansatz.
weil wir keinen Bock und keine Zeit haben, uns um bugfreie Software und Sicherheit zu kümmern (und auch zu blöd dafür sind) ziehen wir einen zusätzlichen Layer ein. Die zusätzliche Komplexität gibt uns ein bis zwei Jahre Luft, bis die bösen Jungs uns wieder eingeholt haben. Und dann ziehen wir einen neuen Layer ein ....
Ich würde eher sagen: Das Mantra der modernen Software-Branche. Nenne mich altbacken, aber vor 20 Jahren wäre es schlicht undenkbar Software an Kunden als Alpha auzuliefern, so wie sie jetzt als Stable verkauft wird. Und dabei denke ich nicht mal an die Spiele-Branche, denn die lebt was Qualität anbetrifft offenbar in einem eigenen Universum. Ist aber ein anderes Thema.
Aus einem chroot kannst Du leicht ausbrechen, besonders wenn Du innerhalb UID 0 bist. Andere Systeme (nicht Linux) bieten wohl teilweise eine etwas bessere Abschottung des chroot nach außen, das ist aber nicht die Aufgabe eines chroot. Es soll es Dir z.B. ermöglichen, Pakete relativ zu / zu bauen, wenn Du auf / nicht zugreifen darfst oder willst, es kann auch praktischer und übersichtlicher sein, einem Prozess nur genau so viel / zur Verfügung zu stellen wie er braucht, dass dabei, besonders für nicht-UID-0, auch die Sicherheit etwas erhöt wird, ist mehr ein nettes Nebenprodukt, VMs leistet aber im Allgemeinen wesentlich mehr (abschottung der Prozesse (Gast, Host) voneinander, Zuteilung von Ressourcen...), was auch in einer wesentlich höheren Sicherheit resultiert (ebenso BSD-Jails, die sind dann auch für Sicherheit gedacht). Dass man auch aus einer VM ausbrechen kann, ist natürlich wahr, dass sie nur minimal sicherer als chroot ist, nicht.
Nein, aber virtualisieren ist gerade "modern". Besser wäre sicher ein Security Framework (wie RSBAC) oder Kernel Erweiterungen (wie SELinux), etc. einzusetzen.
Aber das ist dem typischen EDV-Fachmann zu aufwändig bzw. zu kompliziert (wo sind nur die unbestechlichen "Admins" geblieben :). Außerdem ist es seit jeher ein betriebswirtschaftlicher Grundsatz für Sicherheit kein Geld auszugeben, zumindest nicht für Arbeitszeit und Dienstleistungen.
Und Du hälst es für weniger aufwendig, alle Dienste in eigenen VMs zu pflegen und die Kommunikation dieser sicherzustellen als ein Framework wie SELinux einzusetzen? Ich weiß nicht... Besser ist jedenfalls beides zusammen
Beides zusammen ist lediglich komplizierter und langsamer. Durch unnötig erhöhte Komplexität gewinnt man meistens keine Sicherheit, eher das Gegenteil.
Wie stark die VMs zu pflegen sind, wird man erst sehen. Kommt in erster Linie auf die Implementierung an.
Wäre nicht schon etwas gewonnen, wenn jede (in Anführungszeichen) Anwendung als eigener Benutzer läuft und nur Lese/Schreibrechte in bestimmen nur für die Anwendung zugänglichen Verzeichnissen erhält? Könnte man sich dann den VM-Quark nicht sparen?
Es gibt immer Anwendungen die _zuviele_ Rechte benötigen. Div. Kernelmodule, Paketmanager, Firewalls etc. Die kannst Du nur beschränkt kastrieren, der Weg über eine eigene VM ist daher deutlich sicherer.
Dennoch: wenn der Dom0 mal kompromittiert ist, dann ist's vorbei. Und wenn selbst ich für Xen 4.0 innerhalb von 60 Minuten ein local exploit schreiben kann, schaut die Welt weiterhin düster aus...
> Es gibt immer Anwendungen die _zuviele_ Rechte benötigen.
Man kann ein System nur bis zu dem Punkt sicherer machen, an dem es nicht mehr funktioniert.
400 MB RAM sind ein hoher Preis für die Absicherung eines Systems, das an sich schon sehr sicher ist. Klassische Methoden wie Backup, Kiosk und vor allem Schulung sind in den meisten Fällen besser als irgendwelche technologische Wundermittel wie dieses hier. Natürlich nur dann, wenn sie konsequent und qualifiziert angewendet werden.
Letztlich sehe ich hier nur ein weiteres Beispiel für das alte Marketingkonzept: "unsere Technik gibt Ihnen ultimative Sicherheit ohne dass Sie selbst etwas tun oder lernen müssen."
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 10. Apr 2010 um 15:34.
"Und wenn selbst ich für Xen 4.0 innerhalb von 60 Minuten ein local exploit schreiben kann, schaut die Welt weiterhin düster aus..." Also laut Frau Rutkowska (http://qubes-os.org/files/doc/arch-spec-0.3.pdf , S. 41 "Potential bugs in the hypervisor") würdest du dir damit in 60 Minuten eine ganze Menge Respekt verschaffen können. Die Idee hinter der Virtualisierung in Qubes ist nicht nur die Abschottung von Programmen voneinander (das kann das normale OS auch), sondern dass man den Code, der diese Abschottung durchsetzt, möglichst klein hält. In 50k LOC für nen schlank gemachten Hypervisor (zugegeben, Xen hat was das angeht noch einiges vor sich) verstecken sich wahrscheinlich weniger Bugs als in x Millionen des Linuxkernels. Gibt natürlich schon andere Ansätze dafür (Stichwort Microkernel); das Nutzen der Virtualisierungsmöglichkeiten des Prozessors (insbes. VT-d) bringt dabei neben etwas Performance vor allem Rückwärtskompatibilität -- man muss alte Treiber u. Software nicht neu schreiben.
ich habe das mal ausprobiert..... installation kein problem, aber dann nix läuft ... es werden benötigte dateien nicht erzeugt... schade ich halte es für eine gute und relativ sichere Sache..
Von me@life:~$ make sense am Sa, 10. April 2010 um 20:24 #
Wie es auf modernen Betriebssystemen Prozesshierarchien gibt, werden wir bei den Laufzeitumgebungen von morgen über VM-Hierarchien sprechen, die jeweils ihre eigene Prozesshierarchie haben. Und natürlich werden auch diese Systeme nicht unverletzlich sein.
Nur mal so:
Heise.de war deutlich schneller!
Was chroot nicht einsperren kann das bekommt man mit ner VM auch nur minimal sicherer hin.
Nur daß ersteres einen Overhead von vieleicht 500kB hat, letzteres eher 500MB.
Ich bin wohl der Einzige der dazwischen ein himmelweiten Unterschied sieht.
dann erkläre ihn uns oder war das ironie?
Kannst du per "chroot" auch unterschiedliche Betriebssystem laufen lassen? Kannst du per "chroot" ohne Gefrickel ohne persistente Arbeitsumgebung z.B. für das Onlinebanking einrichten? Kannst du per "chroot" eine Umgebung einrichten, die nur einen bestimmten Teil der Resourcen des Systems (z.B. RAM) zugewiesen bekommt? usw.
Das wir uns nicht falsch verstehen :
"chroot" ist nützlich und für viele Fälle absolut ausreichend, aber eine VM kann trotzdem deutlich mehr.
golem.de war noch schneller (=Quelle für viele Heise-News)
Mein chroot kann Onlinebanking. YMMD!
Mh, dazu muss ich ja nun mal etwas sagen.
chroot ist nicht für Sicherheit da und hat nichts mit BSD oder Solaris chroot zu tun.
Man kann innerhalb einer Applikation das chroot verlassen, also auf das Haupt / zugreifen. Ich sehe das als tödlich an. Xen&Co sind idR zwar auch nicht auf Sicherheit getrimmt und ich rate mal, das uns da noch einiges erwartet, aber die Basis Hüuerde liegt erstmal hoeher.....nunja, es gibt andere Gruende chroot einzusetzen.
Bei bedarf kann ich nochmal eine Quelle suchen. Ich meine in der KernelDoco steht dazu etwas.
Gleichzeitig sehe ich es aber auch so, das Virtualisierung da der falsche Ansatz ist. wahrscheinlich wäre so etwas wie vserver oder ähnliches der bessere Ansatz.
nunja, schoenes WE noch
Wudo
Tja,
das ist das Mantra der Software-Branche:
weil wir keinen Bock und keine Zeit haben, uns um bugfreie Software und Sicherheit zu kümmern (und auch zu blöd dafür sind) ziehen wir einen zusätzlichen Layer ein. Die zusätzliche Komplexität gibt uns ein bis zwei Jahre Luft, bis die bösen Jungs uns wieder eingeholt haben. Und dann ziehen wir einen neuen Layer ein ....
Ich würde eher sagen: Das Mantra der modernen Software-Branche. Nenne mich altbacken, aber vor 20 Jahren wäre es schlicht undenkbar Software an Kunden als Alpha auzuliefern, so wie sie jetzt als Stable verkauft wird. Und dabei denke ich nicht mal an die Spiele-Branche, denn die lebt was Qualität anbetrifft offenbar in einem eigenen Universum. Ist aber ein anderes Thema.
Aus einem chroot kannst Du leicht ausbrechen, besonders wenn Du innerhalb UID 0 bist. Andere Systeme (nicht Linux) bieten wohl teilweise eine etwas bessere Abschottung des chroot nach außen, das ist aber nicht die Aufgabe eines chroot. Es soll es Dir z.B. ermöglichen, Pakete relativ zu / zu bauen, wenn Du auf / nicht zugreifen darfst oder willst, es kann auch praktischer und übersichtlicher sein, einem Prozess nur genau so viel / zur Verfügung zu stellen wie er braucht, dass dabei, besonders für nicht-UID-0, auch die Sicherheit etwas erhöt wird, ist mehr ein nettes Nebenprodukt, VMs leistet aber im Allgemeinen wesentlich mehr (abschottung der Prozesse (Gast, Host) voneinander, Zuteilung von Ressourcen...), was auch in einer wesentlich höheren Sicherheit resultiert (ebenso BSD-Jails, die sind dann auch für Sicherheit gedacht).
Dass man auch aus einer VM ausbrechen kann, ist natürlich wahr, dass sie nur minimal sicherer als chroot ist, nicht.
Moin,
was reitet ihr alle auf chroot herum?
Dies ist eine "sicherheitsanhebende" Lösung zur Trennung der Anwendungen.
Es ist aber nicht absolut Crackersicher und auch nicht Methoden wie z.B. Solaris Zonen zu vergleichen.
Dafür existiert unter Linux aber vergleichbares, z.B. OpenVZ.
Gruß
sumsi
Ist da wirklich so viel gewonnen?
Nein, aber virtualisieren ist gerade "modern". Besser wäre sicher ein Security Framework (wie RSBAC) oder Kernel Erweiterungen (wie SELinux), etc. einzusetzen.
Aber das ist dem typischen EDV-Fachmann zu aufwändig bzw. zu kompliziert (wo sind nur die unbestechlichen "Admins" geblieben :). Außerdem ist es seit jeher ein betriebswirtschaftlicher Grundsatz für Sicherheit kein Geld auszugeben, zumindest nicht für Arbeitszeit und Dienstleistungen.
lg unreal
Und Du hälst es für weniger aufwendig, alle Dienste in eigenen VMs zu pflegen und die Kommunikation dieser sicherzustellen als ein Framework wie SELinux einzusetzen? Ich weiß nicht... Besser ist jedenfalls beides zusammen
Beides zusammen ist lediglich komplizierter und langsamer. Durch unnötig erhöhte Komplexität gewinnt man meistens keine Sicherheit, eher das Gegenteil.
Wie stark die VMs zu pflegen sind, wird man erst sehen. Kommt in erster Linie auf die Implementierung an.
> Wie stark die VMs zu pflegen sind, wird man erst sehen.
Im Wesentlichen wie ein normales OS auch.
Ich sprach von der Virtual Machine und deren Beschränkungen (welche im Artikel erwähnt werden).
Wäre nicht schon etwas gewonnen, wenn jede (in Anführungszeichen) Anwendung als eigener Benutzer läuft und nur Lese/Schreibrechte in bestimmen nur für die Anwendung zugänglichen Verzeichnissen erhält? Könnte man sich dann den VM-Quark nicht sparen?
Es gibt immer Anwendungen die _zuviele_ Rechte benötigen. Div. Kernelmodule, Paketmanager, Firewalls etc. Die kannst Du nur beschränkt kastrieren, der Weg über eine eigene VM ist daher deutlich sicherer.
Dennoch: wenn der Dom0 mal kompromittiert ist, dann ist's vorbei. Und wenn selbst ich für Xen 4.0 innerhalb von 60 Minuten ein local exploit schreiben kann, schaut die Welt weiterhin düster aus...
> Es gibt immer Anwendungen die _zuviele_ Rechte benötigen.
Man kann ein System nur bis zu dem Punkt sicherer machen, an dem es nicht mehr funktioniert.
400 MB RAM sind ein hoher Preis für die Absicherung eines Systems, das an sich schon sehr sicher ist. Klassische Methoden wie Backup, Kiosk und vor allem Schulung sind in den meisten Fällen besser als irgendwelche technologische Wundermittel wie dieses hier. Natürlich nur dann, wenn sie konsequent und qualifiziert angewendet werden.
Letztlich sehe ich hier nur ein weiteres Beispiel für das alte Marketingkonzept: "unsere Technik gibt Ihnen ultimative Sicherheit ohne dass Sie selbst etwas tun oder lernen müssen."
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 10. Apr 2010 um 15:34."Und wenn selbst ich für Xen 4.0 innerhalb von 60 Minuten ein local exploit schreiben kann, schaut die Welt weiterhin düster aus..."
Also laut Frau Rutkowska (http://qubes-os.org/files/doc/arch-spec-0.3.pdf , S. 41 "Potential bugs in the hypervisor") würdest du dir damit in 60 Minuten eine ganze Menge Respekt verschaffen können.
Die Idee hinter der Virtualisierung in Qubes ist nicht nur die Abschottung von Programmen voneinander (das kann das normale OS auch), sondern dass man den Code, der diese Abschottung durchsetzt, möglichst klein hält. In 50k LOC für nen schlank gemachten Hypervisor (zugegeben, Xen hat was das angeht noch einiges vor sich) verstecken sich wahrscheinlich weniger Bugs als in x Millionen des Linuxkernels. Gibt natürlich schon andere Ansätze dafür (Stichwort Microkernel); das Nutzen der Virtualisierungsmöglichkeiten des Prozessors (insbes. VT-d) bringt dabei neben etwas Performance vor allem Rückwärtskompatibilität -- man muss alte Treiber u. Software nicht neu schreiben.
ich habe das mal ausprobiert..... installation kein problem, aber dann nix läuft ...
es werden benötigte dateien nicht erzeugt...
schade ich halte es für eine gute und relativ sichere Sache..
Wie es auf modernen Betriebssystemen Prozesshierarchien gibt, werden wir bei den Laufzeitumgebungen von morgen über VM-Hierarchien sprechen, die jeweils ihre eigene Prozesshierarchie haben. Und natürlich werden auch diese Systeme nicht unverletzlich sein.