Login
Newsletter
Werbung

Thema: »Qubes OS«: Sicherheit für Linux durch Virtualisierung

24 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von jemand am Fr, 9. April 2010 um 21:24 #

Nur mal so:
Heise.de war deutlich schneller!

[
| Versenden | Drucken ]
  • 0
    Von Crass Spektakel am Fr, 9. April 2010 um 21:48 #

    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.

    [
    | Versenden | Drucken ]
    • 0
      Von bimbo am Fr, 9. April 2010 um 22:41 #

      Ich bin wohl der Einzige der dazwischen ein himmelweiten Unterschied sieht.

      [
      | Versenden | Drucken ]
      • 0
        Von s3rs am Fr, 9. April 2010 um 23:11 #

        dann erkläre ihn uns oder war das ironie? 8)

        [
        | Versenden | Drucken ]
        • 0
          Von glasen am Sa, 10. April 2010 um 00:17 #

          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.

          [
          | Versenden | Drucken ]
          0
          Von Wudo am Sa, 10. April 2010 um 20:13 #

          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

          [
          | Versenden | Drucken ]
      0
      Von Anonymous am Fr, 9. April 2010 um 23:10 #

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

      [
      | Versenden | Drucken ]
      • 0
        Von MoMo am Sa, 10. April 2010 um 00:27 #

        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.

        [
        | Versenden | Drucken ]
      0
      Von kamome am Sa, 10. April 2010 um 07:24 #

      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.

      [
      | Versenden | Drucken ]
      • 0
        Von sumsi am Di, 13. April 2010 um 09:41 #

        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

        [
        | Versenden | Drucken ]
0
Von analüstiker am Fr, 9. April 2010 um 22:43 #

Ist da wirklich so viel gewonnen?

[
| Versenden | Drucken ]
  • 0
    Von unreal am Sa, 10. April 2010 um 07:11 #

    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

    [
    | Versenden | Drucken ]
    • 0
      Von kamome am Sa, 10. April 2010 um 07:29 #

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

      [
      | Versenden | Drucken ]
    0
    Von kanuba am Sa, 10. April 2010 um 11:50 #

    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?

    [
    | Versenden | Drucken ]
    • 0
      Von champus am Sa, 10. April 2010 um 14:31 #

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

      [
      | Versenden | Drucken ]
      • 0
        Von zettberlin am Sa, 10. April 2010 um 15:33 #

        > 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.
        [
        | Versenden | Drucken ]
        0
        Von HdP am So, 11. April 2010 um 12:54 #

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

        [
        | Versenden | Drucken ]
0
Von dl8zad am Sa, 10. April 2010 um 08:48 #

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

[
| Versenden | Drucken ]
0
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.

[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung