debianforum.de

Habe da so ein paar Gedanken, wo ich gerne mal andere Meinungen zu einholen möchte.
Ich denke man könnte (sollte?) ein System mittels QEMU/KVM ähnlich QubesOS als Debian-Option zusammenbasteln.
Dazu einige Gedanken: Mittels KVM versch. virtuelle Maschinen aufsetzen um z.B. TOR, I2P, Freenet, aber auch SchmuddelWeb (Facebook/Google/etc.pp) und eine besonders gesicherte virt. Maschine fürs 'sichere' Surfen (eMails holen, berufliches Surfen [ohne private Spuren] usw.)
So hört sich das alles noch ziemlich nach QubesOS an, aber halt, wir sind auf Debian, und da hätte ich es gerne 'etwas' anders.
z.B. sollten die virt. Maschinen nicht nur in einem Fenster laufen, sondern auch die Möglichkeit haben ihrem eigenen X-Server haben auf ihrem eigenen 'Terminal', also nicht auf 'F7' sondern z.B. auf <Strg><Alt><F8> bis <Fn>, denn das dieses möglich ist weis ich noch aus PentiumII MMX Zeiten: da hatte ich daheim 4 Siemens Primergy so genutzt, mit nur einem Monitor/Tastatur/Maus Kombo. Also die Fähigkeiten von X11 übers Netz umzuleiten (ähnlich wie X2Go bzw. Vnc).
Der Vorteil wäre daß man ein 'full screen Desktop' neben den 'Hypervisor-Desktop' fahren könnte.So hätte ich dann z.B. Tor auf Strg-Alt-F8, Schmuddelweb auf Strg-Alt-F9 und hyper dooper sicheres Surfen auf Strg-Alt-F10 z.B.
Aber halt, da hört es noch nicht auf.
Der Unix-Dateibaum ist nicht ohne Grund so 'unübersichtlich'. Früher war es üblich das Maschinen nur das notdurftigste zum Booten auf der eigene Platte hatten, und der Rest (/home, /usr usw.) per NFS importierten.
Unsere virt. Maschinen könnten z.B. fast alles vom 'Hypervisor' erhalten. Per chroot könnte man sogar den Kernel und die binaries alle aus derselben Quelle beziehen, und /home , /usr, usw per NFS importieren, denn die virt. Maschinen sind schließlich per Bridge mit dem Hypervisor in ein virt. Netzwerk. Falls das mit chroot so funktioniert, wurde man erheblich Platz sparen & ein Update des Systems wäre erheblich einfacher, denn nur der Hypervisor-OS muß geupdatet werden, alle virt. Maschinen beziehen ja ihre Daten von dort. Gemountet wird dann natürlich nur 'read only' (außer /home/ natürlich), was sogar Manipulationen vorbeugt. Natürlich sollte die 'Schmuddelmaschine' nicht /home importieren, damit Browserangriffe nicht auf die andere Maschinen übergreifen können.
Und jetzt noch 'n paar Worte zu Festplattenverschlüsselung: Das finde ich äußerst unpraktisch. Es bringt nichts /boot, /bin & /usr zu verschlüsseln, denn die dort liegende Daten sind millionenfach weltweit einsehbar. /home Verschlüsseln und /var/tmp etc. kann ich noch verstehen, aber ALLES??? Da sehe ich keinen Sinn drinn, außer Resourcenverschwendung (Rechenzeit zum entschlüsseln bei JEDEM Zugriff).

So, das wäre so im großen und ganzen was mich zZ so beschäftigt. Ich hoffe es ist ersichtlich, das man keine neue Distro machen muß um in den Genuß eines 'sicherstes OS' (O-Ton Qubes) zu kommen.
Gerne hätte ich dazu die Meinung von Experten und versierte Admins dazu gehört.
MfG. Fusin

Wenn dir soviel an Sicherheit liegt, dann solltest als allererstes den Xserver aus der Gleichung nehmen. Denn das ist mit Abstand einer der massivsten Schwachpunkte. Hinzu kommt, dass offenbar unterschätzt wie lange es gedauert hat, ein heutiges QubesOS zu entwickeln, damit das alles derart zusammenspielt und dabei noch ansatzweise normal nutzbar ist. In Eigenregie ist das mehr als nur aufwändig.

Was spricht gegen ein reguläres Debian mit entsprechender Systemhärtung? Zuallererst sollte das ganze System in Segmente unterteilt werden, die später problemlos als read-only gemountet werden können. Auch Mountoptionen wie, nodev, noexec und nosuid gehören dazu, und müssen je nach Volume klug gewählt werden. Dann gehört das ganze System verschlüsselt, um sowohl die Daten zu schützen als auch Manipulationen am System selbst zu unterbinden. Eine SSD und die Hardwarebeschleunigung, reduzieren den Overhead der Systemverschlüsselung dramatisch. Schon auf moderner Hardware, liegt das nur im 1-2% Bereich.

Ein Gnome-Desktop mit Wayland wäre ratsam, da das Gnome-Projekt mit Abstand am weitesten ist, elementares Sandboxing anzuwenden. Auch sind mittlerweile alle Gnome-Programme als Flatpak erhältlich, und somit standardmäßig in einer Sandbox. Weitere Programme lassen sich problemlos z.B. via Firejail isolieren, wie Browser und Vergleichbares. Selbst ganze VMs zusätzlich zur Virtualisierung.

Den Browser selbst kann man auch mit Erweiterungen sicherer machen, ob nun mit uBlock, uMatrix oder auch NoScript, um die Angriffsfläche deutlich zu reduzieren. Mittels Firejail lassen sich auch mehrere differenzierte Nutzungsprofile etablieren.

Und letztendlich kann man auch fertig konfigurierte VMs aufsetzen, für jeweils unterschiedliche Zwecke, oder alternativ LXC -bzw. Docker-Container. Wenn auch das noch nicht reicht, bleiben nach wie vor noch SELinux und AppArmor übrig. Nebenbei erwähnt, gewährt eine VM standardmäßig, keinerlei Zugang zum regulären Dateisystem, womit hier auch nichts übergreifen kann.

Die Erreichbarkeit via Tastenkombination, lässt sich über den Desktop selbst realisieren, wenn mehrere VMs oder Container aktiv sind. Schon die Nutzung von Wayland, macht aus jedem Fenster eine eigene isolierte Instanz.

Fusin hat geschrieben:

08.01.2018 20:40:31

Ich denke man könnte (sollte?) ein System mittels QEMU/KVM ähnlich QubesOS als Debian-Option zusammenbasteln.
Dazu einige Gedanken: Mittels KVM versch. virtuelle Maschinen aufsetzen

Da stellt sich zunächst die Frage, ob du die Host-CPU durchreichen, oder eine CPU für die VM emulieren willst.
Den ersten Fall wird man normalerweise bevorzugen, weil das deutlich performanter ist, aber es ist dabei einfacher, aus der VM auszubrechen. Noch weniger abgeschottet wäre man, wenn man auch noch den Host-Kernel direkt in die VM durchreicht, wi z.B. bei einem chroot.

Fusin hat geschrieben:

08.01.2018 20:40:31

um z.B. TOR, I2P, Freenet, aber auch SchmuddelWeb (Facebook/Google/etc.pp) und eine besonders gesicherte virt. Maschine fürs 'sichere' Surfen (eMails holen, berufliches Surfen [ohne private Spuren] usw.)

Deinen Ansatz finde ich gut, aber nicht zuende gedacht.

Eine einzelne VM für den ganzen Schmuddelkram hilft für sich genommen nicht viel weiter, weil du dort viele persönliche Daten lassen wirst (Standortdaten bei Google, Klostatusmeldungen bei Facebook), die sich alle miteinander verschneiden lassen. Ob das auf deinem Host oder in einer VM passiert ist dabei relativ egal. Bevor du die Trennung technisch umsetzt, muss sie in deinem Kopf stattfinden. Du musst dich fragen, welche Daten du Dienst A aber nicht Dienst B anvertrauen willst und andersrum. Wenn du dafür eine Antwort hast, dann kannst du dich an die technische Trennung machen, aber die eigentliche Herausforderung wird immer in deinem Kopf sein, beides nicht doch wieder miteinander zu mischen.

Eine einzelne "sichere" Maschine halte ich auch nicht für ausreichend. Wenn ich mir anschaue, was auf meiner beruflichen Mailadresse für Spam aufläuft, weil manche meiner Kollegen eine digitale Hygiene wie im sprichwörtlichen Schweinestall pflegen, dann möchte ich das nicht mit meinem Banking-Account mischen.

Z.T. trenne ich verschiedene Nutzungsszenarien bereits in verschiedenen VBox-VMs. Ich habe z.B. eine Banking-VM, eine Youtube-VM, eine Berufs-VM und eine Google-VM. Begrenzt wird das ganze durch den verfügbaren RAM.

Fusin hat geschrieben:

08.01.2018 20:40:31

Gemountet wird dann natürlich nur 'read only' (außer /home/ natürlich)

Ein gemeinsames Home in mehrere chroots/VMs zu mounten führt nur zu Chaos, weil Daten und Einstellungen nicht sauber voneinander getrennt werden. Dedizierte Austauschordner sind ok, aber man sollte nicht das Home dafür missbrauchen.

Fusin hat geschrieben:

08.01.2018 20:40:31

Und jetzt noch 'n paar Worte zu Festplattenverschlüsselung: Das finde ich äußerst unpraktisch. Es bringt nichts /boot, /bin & /usr zu verschlüsseln, denn die dort liegende Daten sind millionenfach weltweit einsehbar.

Das ist ein Trugschluss. Keiner weiß, was du in deinem verschlüsselten /bin hast. Natürlich kann man vermuten, dass da irgendwo ein Browser und eine Textverarbeitung rumliegen, aber da liegt auch Spezialsoftware, die viel über dich verraten kann.
Viel wichtiger ist aber, dass jeder der deinen Rechner in die Finger kriegt dein /bin manipulieren kann, wenn es nicht verschlüsselt ist - im schlimmsten Fall ohne dass du es mitbekommst.

Soweit ich weiß, kann man /boot nicht verschlüsseln, da sonst das System nicht bootfähig ist. (Das mag aber veraltet sein.) Ein unverschlüsseltes /boot lässt sich aber ebenfalls durch Dritte manipulieren, z.B. mit einem kompromittierten Kernel. Daher wäre es für deine Idee wichtig, dein /boot auf einem externen Datenträger zu lagern den du nie aus den Augen lässt und dessen Backup-Ort nur dir bekannt ist.

hikaru hat geschrieben:

09.01.2018 10:35:43

Ich habe z.B. eine Banking-VM, eine Youtube-VM, eine Berufs-VM und eine Google-VM.

Eine Google-VM und Youtube-VM? Wo ist denn hier der Unterschied?

hikaru hat geschrieben:

09.01.2018 10:35:43

Soweit ich weiß, kann man /boot nicht verschlüsseln, da sonst das System nicht bootfähig ist. (Das mag aber veraltet sein.) Ein unverschlüsseltes /boot lässt sich aber ebenfalls durch Dritte manipulieren, z.B. mit einem kompromittierten Kernel.

Das geht schon längere Zeit, zumal Grub seit Version 2.0 Kryptovolumes öffnen kann. Allerdings muss man das meist manuell nach der Installation tun. Diverse Linux-Distributionen wie Manjaro, die auf Calamares als Installer setzen, machen das wenn ich mich recht erinnere schon automatisch.

breakthewall hat geschrieben:

09.01.2018 19:24:03

Eine Google-VM und Youtube-VM? Wo ist denn hier der Unterschied?

In der einen schaue ich nur Youtube-Videos, in der anderen lade ich allgemein Webseiten, die nicht ohne Google-Inhalte auskommen (hauptsächlich Maps). Die Youtube-VM läuft recht häufig (ich schaue manche Kanäle, wie Andere Fußball im Fernsehen schauen), die Google-VM vielleicht einmal pro Monat.
Ich bilde mir ein, Google die Profilbildung etwas zu erschweren indem die häufig verwendete VM wirklich nur eine Aufgabe erfüllt.

breakthewall hat geschrieben:

09.01.2018 19:24:03

hikaru hat geschrieben:

09.01.2018 10:35:43

Soweit ich weiß, kann man /boot nicht verschlüsseln, da sonst das System nicht bootfähig ist. (Das mag aber veraltet sein.) Ein unverschlüsseltes /boot lässt sich aber ebenfalls durch Dritte manipulieren, z.B. mit einem kompromittierten Kernel.

Das geht schon längere Zeit, zumal Grub seit Version 2.0 Kryptovolumes öffnen kann. Allerdings muss man das meist manuell nach der Installation tun. Diverse Linux-Distributionen wie Manjaro, die auf Calamares als Installer setzen, machen das wenn ich mich recht erinnere schon automatisch.

Danke für die Info!