Qubes Linux OS

[debiator]

Ja guten Abend!

Ich habe ja schon lange darauf gewartet, wann macht die Linuxcommunity den Sprung nach vorne, was den Sicherheitskonzept der Betriebsysteme angeht.
Das Konzept der gängigen Linux Distributionen ist sicherlich mit Abstand die beste Sicherheit, die man bisher haben konnte.
Debian ist mit seiner gut gemeinten "konservativen" Stabilität ist da durchaus ein gutes Beispiel.
Doch die Zeit schläft nicht und auch dieses Konzept wird irgendwann überholt sein.

Jetzt kam ja Anfang Oktober die Meldung über Qubes OS und da dachte ich mir: "JA! Das ist etwas wirklich Neues!"
Dass es auch davor VMs gab etc., das ist klar. Doch ein Gesamtpaket für User war bisher nicht da.

Das Konzept mit getrennten VMs, die in der Art miteinander kommunizieren ist wirklich genial und zukunftsweisend!
Ich warte auf die neue Version, die bereits Ende Oktober rauskommen soll. Dann haue ich mir das Ding mal aufn Zweitrechner drauf.

Hat jemand Erfahrung mit Qubes OS??

[gehrke]

Ich evaluiere gerade: http://linux-club.de/forum/viewtopic.php?f=104&t=120625

@df.de: Bitte nicht sauer sein, möchte den User nicht 'abwerben', nur informieren!

[debiator]

vielen Dank!
Ich bin schon sehr gespannt auf die neue Version Ende Oktober, die würde ich dann auch testen.
Bis die Sache aber eine gewisse Massen- bzw. Alltagstauglichkeit erreicht, wird es wohl noch einwenig dauern.

[owl102]

http://linux-club.de/forum/viewtopic.ph ... 20#p769156

Polen ist nicht Russland.

Außerdem lohnt es sich, nach Joanna Rutkowska [1] im Internet zu suchen (anstatt FUD zu verbreiten), es gibt einige sehr interessante Interviews und Talks mit der Dame.

[1] https://de.wikipedia.org/wiki/Joanna_Rutkowska

[gehrke]

Polen ist nicht Russland.

OK, mein Fehler. Habe das korrigiert.
TNX

[owl102]

Habe das korrigiert.

Aber auch nur halb. Wer kommt denn nun aus Russland? Alle drei "Architects and Core Developers" kommen aus Polen. Beide "Proprietary Code Developers" ebenso. Die "Contributors to Open-source Code" sind ein bunter Haufen aus allen möglichen Ländern.

[gehrke]

Ich glaube, dass damit ausreihend deutlich geworden ist, dass die ursprüngliche Befürchtung Unsinn war (was ich übrigens zuvor auch schon als diskussionswürdig angemerkt hatte).

[debiator]

buhuuu! Die bösen Russen! *tztzz
ist doch egal woher das Zeug kommt.
Man muss die Sachen aus Europa um so mehr unter die Lupe nehmen, weil hier alles Große in den Händen der USA liegt.
Da sind die Russen zumindest momentan noch unbedenklicher, da es dort keine totalitären Pläne gibt.

Aber Politik hin oder her. Das Ding ist open source und ist der Zusammenstellung nach das Inovativste, was ich bis jetzt mitbekommen habe!

[gehrke]

Aber Politik hin oder her. Das Ding ist open source

Das ist openssl auch. Und trotzdem gab es Heartbleed...
Quelloffen ist das eine, aber solange das nicht effektiv auch qualifiziert gereviewed wird, ist alles möglich.

[debiator]

Das ist klar und ich gehe sogar davon aus, dass in komplexen open source Programmen doch Hintertüren sind.
Aber was gibt es da für eine Alternative? open oder closed, da ist also open natürlich um Welten besser und man kann nur hoffen, dass genug qualifizierte Menschen drüber schauen.

[gehrke]

Die Hoffnung stirbt zuletzt...

Fakt ist: Man könnte es reviewen, was schon mal sehr gut ist und auch meine persönliche Präferenz. Ich kann das aber leider nicht und die Organisation, für die ich nach einem solchen Werkzeug suche, kann das auch nicht.

Wenn sich hier keine neuen Aspekte ergeben, dann wird das eine Bauch-Entscheidung:
*Pro: OpenSource mit der Option zum Review. Insbesondere weil dieser spezifische Anwenderkreis schon sehr sicherheits-affin (sollte ich sagen paranoid?) ist , steigt IMHO die Wahrscheinlichkeit, dass da genauer draufgeschaut wird.
*Pro: Die Hauptbestandteile (Xen, Linux...) sind große OSS-Projekte, bei denen man schon davon ausgehen kann, dass das gereviewed wird. Beispielsweise kann ich mir nicht vorstellen, dass Xen nicht mindestens von dem großen Weltkonzern genauestens betrachtet wird, der damit seine Cloud-Infrastruktur betreibt und Milliarden-Umsätze macht.
*Contra: Gerade weil das kein 08/15-System ist und nur ein bestimmter Anwenderkreis auf die Idee kommt, so etwas einzusetzen, könnten Angreifer dies für ein lohnenswertes Ziel halten...

Damit bin ich genau so klug wie vorher. Aber klar ist, Deine Frage nach den besseren Alternativen kann ich nicht beantworten.

[owl102]

Und trotzdem gab es Heartbleed...

...von einem Deutschen eingebaut.

[debiator]

@gehrke:

ja.. das ist eine ziemlich verzwickte Sache, aber, wie Du sagst, keine Alternativen.

[gehrke]

Nun, eine Alternative ist sicherlich, so weiterzumachen wie bisher.Beispielsweise jeweils ein eigenes System pro Security-Kontext - entweder mit dedizierter Hardware oder via MultiBoot/USB-Sticks. Ist halt aufwendig, teuer und unhandlich. Und wenn etwas unhandlich ist, dann neigen die User zu potentiell gefährlichen Workarounds.

Der besondere Charme von Qubes ist halt, dass es verspricht, alles gleichzeitig machen zu können. Ich sehe die Hauptfragen darin, ob das erstens praktikabel genug funktioniert und zweitens ausreichend isoliert.

Die erste Frage versuche ich für mich persönlich zu klären, indem ich es ausprobiere. Bei der zweiten Frage kann ich mich nur auf meinen Bauch und die Meinung der Leute verlassen, die mehr davon verstehen als ich.

[catdog2]

Nun, eine Alternative ist sicherlich, so weiterzumachen wie bisher.Beispielsweise jeweils ein eigenes System pro Security-Kontext - entweder mit dedizierter Hardware oder via MultiBoot/USB-Sticks. Ist halt aufwendig, teuer und unhandlich. Und wenn etwas unhandlich ist, dann neigen die User zu potentiell gefährlichen Workarounds.

Sicherheit ist halt immer eine Gesamtrechnung. Der Faktor Mensch der das tolle Konzept torpediert weil er sonst nicht mehr arbeiten kann wird gerne übersehen.

[gehrke]

@catdog2: Genau das meine ich.

[DeletedUserReAsG]

Sehe ich das richtig, dass das betreffende System sich in erster Linie dadurch abheben möchte, dass sie verschiedene Sachen nach Sicherheitskontext gruppiert in verschiedene VMs unter Xen steckt? Ich meine, sowas kann man ja auch unter $beliebigerDistri mit VMs oder eigenem Xen-Setup realisieren, was dann natürlich Nachteile in der Nutzerfreundlichkeit/Nutzbarkeit mit sich bringt (Datenaustausch der Programme untereinander, externe Datenträger, u.U. Performance [bei RT-Anwendungen, etwa], Ressourcenbedarf, Zugriff auf externe Hardware, etc.) – gibt es bei Qubes dafür Lösungen, oder verhält es sich wie mit etwa 3D-Beschleunigung (sinngemäß aus der Doku: „zugunsten der Sicherheit wirst du drauf verzichten müssen“)? Und wie sieht’s mit Dualboot aus, wenn man etwa auch mal Hardwarefeatures für ein System benötigt, welche die Virtualisierung nicht bereitstellen kann? Ist dann nicht die Sicherheit, die ja mehr oder weniger absolut davon abhängt, dass das Hostsystem nicht kompromittiert werden kann, weg? Oder benötigt man dann halt eine weitere physische Maschine für solcherlei Sachen?

Beim schnellen Drüberschauen sieht’s für mich auch so aus, als hätte man letztlich eine Art verteiltes Fedora, andere Systeme könnte man wieder in eine eigene VM tun – inwiefern hätte denn ein nativer, langjähriger Debiannutzer, der sich auch nun nicht unbedingt in Fedora einarbeiten möchte, überhaupt Vorteile von Qubes? So ganz erschließt sich mir noch nicht, wozu das gut sein soll – mag mir jemand auf die Sprünge helfen?

[gehrke]

@niemand: Ich kann Dir leider nicht alle Fragen beantworten, weil ich mich da auch gerade erst einarbeite. Ich versuche mal grob, das zusammenzufassen, was ich bislang verstanden habe. Ich hoffe, dass man mich freundlicherweise korrigiert, wenn ich Unsinn erzähle.

Soweit ich das sehe, werden da tatsächlich 'nur' schon lange bestehende Technologien so zusammengesteckt, dass ein gut isolierendes Gesamtsystem entsteht. Vermutlich könnte man das alles auch mit eigenen Mitteln nachbauen, aber wahrscheinlich liegt der Teufel hier im Detail.
Xen dient als Virtualisierungslösung/Hypervisor mit einer Fedora-basierten dom0, welche das Hostsystem bildet. Dieses ist aber schon auf das absolute Minimum herunter gebrochen, um möglichst wenig Angriffsvektoren zu bieten (beispielsweise gibt es dort kein Netz).
Es gibt unprivilligierte domU's (VMs) für Netz, Firewall und Storage, darüber wird dann der Traffic nach aussen abgebildet bzw. auch der VM's untereinander, was aber erst mal verboten ist.

Dann werden als veränderbarer Default mehrere Sicherheitskontexte definiert (Disposable (nicht persistent), Untrusted, Personal, Work, Banking...), welche auch eine gewisse Hierarchie haben: Datenverkehr wie beispielsweise über das Clipboard wird nur aus der Richtung Sicher nach Unsicher zugelassen.

Für jeden Sicherheitskontext wird bei Bedarf eine domU/VM im Hintergrund gestartet (es wird also gesammelt). Der User sieht davon auf dem Desktop die jeweiligen Fenster mit einem farblich markierten Rahmen, woran er die Zonen klar auseinander halten kann. Zusätzlich einen Manager, der die laufenden Kontexte/VMs anzeigt inklusive der Ressourcen-Verbräuche.
Wenn man also beispielsweise malocht, dann sollte man mehrere 'Work'-Fenster offen haben, welche alle zu der einen Work-VM gehören. Daneben vielleicht noch einen Thunderbird-Fenster aus 'Personal', um die privaten Mails im Auge zu behalten und vielleicht ein Browser in 'Untrusted' oder 'Disposable', für Recherche im Internetz. Es ist ein wichtiger Bestandteil des Konzeptes, dass dem Anwender immer transparent ist, was da läuft und wozu es gehört.

Die Basis dieser domU's ist frei wählbar, default ist Fedora. 2 oder 3 andere werden noch mitgeliefert, alles andere muss sich AFAIK selbst bauen. Die persönlich präferierte Linux-Distro oder BSD sollte also möglich sein, ebenso Windows (letzteres aber nicht paravirtualisiert).

Ein paar Deiner Einzelpunkte:
* 3D-Beschleunigung: Für die dom0 ja, für die domU's nein. Hier sagen die Entwickler, dass das Risiko einer Kompromittierung der höheren Schichten zu groß sei.
* DualBoot wird nicht verhindert. Ich habe eine Installation getestet, in der Qubes neben openSUSE liegt in einer LUKS/LVM-Partitionierung.
*Ich sehe auch keine Möglichkeit, das Booten von externen Systemen auf der Hardware zu verhindern. So etwas kann eine Linux-Installation AFAIK nicht, ohne sich massiv in UEFI einzuklinken. UEFI wird derzeit nicht unterstützt.
* Qubes ist kein Multiuser-System.

Wie gesagt, bin selbst noch in der Einarbeitung! Das ist mein momentaner Kenntnisstand...

[The Hit-Man]

kein system ist sicher und wer sich überwachen läß ist selber schuld

[owl102]

Sehe ich das richtig, dass das betreffende System sich in erster Linie dadurch abheben möchte, dass sie verschiedene Sachen nach Sicherheitskontext gruppiert in verschiedene VMs unter Xen steckt? Ich meine, sowas kann man ja auch unter $beliebigerDistri mit VMs oder eigenem Xen-Setup realisieren

Ja und jein. Qubes OS bringt schon auch eigenen Code mit, z.B. für das "GUI virtualization subsystem", einen "Qubes X Wrapper", eigene Patches an Xen usw. Aber das ist Open Source, und ließe sich sicherlich portieren.

Die Grundidee ist es, aufbauend auf den oben von dir genannten Sicherheitskonzept eine fertige Lösung anzubieten. Qubes OS sagt selber von sich: "Is Qubes just another Linux distribution? If you really want to call it a distribution, then it’s more of a “Xen distribution” than a Linux one. But Qubes is much more than just Xen packaging. It has its own VM management infrastructure, with support for template VMs, centralized VM updating, etc. It also has a very unique GUI virtualization infrastructure."

Siehe auch:
http://blog.invisiblethings.org/2012/09 ... -from.html
https://www.qubes-os.org/en/doc/user-faq/

Wenn man einen Überblick darüber bekommen möchte, was denn nun Qubes OS eigener Code ist:
https://github.com/QubesOS

Und wenn ich schon Links poste, dann möchte ich auch ganz gerne diese hier loswerden:

https://www.youtube.com/watch?v=CqONg8w5nkw (LinuxCon + CloudOpen Europe 2014 - Qubes OS - Joanna Rutkowska)

http://www.tomshardware.com/reviews/joa ... ,2356.html (Exclusive Interview: Going Three Levels Beyond Kernel Rootkits)

(Einen Link mit einem Interview, wo es mehr um Qubes OS geht, deren Konzepte, wozu und für wen Qubes OS überhaupt gedacht ist usw. finde ich leider auf die Schnelle nicht mehr wieder. Vielleicht finde ich dieses Wochenende noch ein wenig mehr Zeit zum Suchen. Ich meine mich aber daran erinnern zu können, daß Qubes OS auch eine Machbarkeitsstudie ist: Was ist jetzt schon in dieser Richtung machbar, wie (gut) ist es machbar, und wie anwenderfreundlich/praxistauglich ist es? Überhaupt habe ich bei Frau Rutkowska den Eindruck, daß es nicht darum geht, den Wahren Weg zu verkünden und/oder zu vermarkten, sondern Möglichkeiten auszuloten und aufzuzeigen. Sie sieht Qubes OS auch als Diskussionsgrundlage, und als Angebot bzw. mögliche Inspirationsquelle für andere.)

was dann natürlich Nachteile in der Nutzerfreundlichkeit/Nutzbarkeit mit sich bringt

Natürlich.

Ist dann nicht die Sicherheit, die ja mehr oder weniger absolut davon abhängt, dass das Hostsystem nicht kompromittiert werden kann, weg?

Ja. Da müsste man selber etwas dagegen tun, Qubes OS ist keine Wunderlösung, die alle Sicherheitsprobleme abdeckt.

[killbill]

Ich habe mir die Tage auch mal Qubes installiert und finde die Geschwindigkeit auch einigermaßen erträglich zum Arbeiten.
Was mich persönlich zurzeit am meisten stört ist, dass er zum Herunterfahren bei mir immer 2-3 Minuten benötigt, das Hochfahren geht deutlich schneller, schätze mal so um die 45 Sekunden, müsste ich aber nochmal nachmessen.
Mein Manko ist halt, dass ich es auf einer HDD installiert habe und zurzeit nur 4GB Ram habe, da ist also nach zwei VMs dann schon Schluss und sonst ist das Starten von VMs eher zäh, aber mal sehen wie das läuft, wenn ich meinen zweiten 4GB Ram Arbeitsspeicher wieder eingebaut habe.
Edit: Weiß zufällig jemand wie ich Qubes neben Windows installieren kann, als ich das das erste mal gemacht habe konnte ich nur noch Qubes und nicht mehr Windows starten. Jetzt läuft eben Windows auf der SSD und Qubes auf der Festplatte, daher kann ich die voneinander unabhängig starten, aber lieber wäre es mir schon mal Qubes auf der SSD zu testen.

[owl102]

Edit: Weiß zufällig jemand wie ich Qubes neben Windows installieren kann, als ich das das erste mal gemacht habe konnte ich nur noch Qubes und nicht mehr Windows starten.

os-prober ist zwar unter Fedora per default installiert, aber nicht ntfs-3g. Vielleicht ist es bei Qubes OS genauso. Wenn ja, wäre die Abhilfe, ntfs-3g zu installieren, und anschließend grub zu aktualisieren, dann sollte das Windows erkannt und in grub eingetragen werden.

[killbill]

ok danke werde ich dann bei Gelegenheit nochmal testen und dann berichten.

[gehrke]

Edit: Weiß zufällig jemand wie ich Qubes neben Windows installieren kann, als ich das das erste mal gemacht habe konnte ich nur noch Qubes und nicht mehr Windows starten. Jetzt läuft eben Windows auf der SSD und Qubes auf der Festplatte, daher kann ich die voneinander unabhängig starten, aber lieber wäre es mir schon mal Qubes auf der SSD zu testen.

Notfalls sollte es wohl ein entsprechender Eintrag unter /etc/grub.d/40_custom tun:

Code: Alles auswählen

menuentry "Windows" {
	insmod chain
	insmod ntfs
	set root=(hd0,1)
	chainloader +1
}

Die Zeile mit dem 'set root...' müsste angepasst werden und danach die GRUB2-Konfiguration bauen lassen (grub2-mkconfig).

[gehrke]

Fakt ist: Man könnte es reviewen, was schon mal sehr gut ist und auch meine persönliche Präferenz. Ich kann das aber leider nicht und die Organisation, für die ich nach einem solchen Werkzeug suche, kann das auch nicht.
[...]
*Pro: Die Hauptbestandteile (Xen, Linux...) sind große OSS-Projekte, bei denen man schon davon ausgehen kann, dass das gereviewed wird. Beispielsweise kann ich mir nicht vorstellen, dass Xen nicht mindestens von dem großen Weltkonzern genauestens betrachtet wird, der damit seine Cloud-Infrastruktur betreibt und Milliarden-Umsätze macht.

http://www.golem.de/news/pagetable-sich ... 17219.html
Die Lücke in Xen ist demnach seit 7 Jahren unentdeckt...