Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – II – Vorüberlegungen zur Virtualisierung

Ich widme mich in dieser der Verschlüsselung eines Laptops unter Opensuse Leap 15.0. Das ist nicht nur technisch interessant. Eine wichtige Motivation sind Auflagen, die ich als Freelancer gegenüber Auftraggebern erfüllen muss, um der DSGVO “auf dem Stand der Technik” gerecht zu werden. Da ich regelmäßig mit personenbezogenen Daten der Unternehmen konfrontiert bin, gab es hier keine Ausnahmeregelungen für KMU. Bei einer Analyse der technischen Anforderungen merkt man schnell, dass sich die Sicherheit sensibler Daten auf der Ebene der Datenhaltung nicht allein durch die Bereitstellung von verschlüsselten Containern oder einzelner Partitionen/Volumes erreichen lässt. Im letzten Beitrag

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen

hatte ich daher einige Argumente für eine Voll-Verschlüsselung zusammengestellt. Ein Punkt, auf den ich dabei noch nicht eingegangen bin, ist das Thema Virtualisierung: Ein moderner Laptop kann selbstverständlich auch als Host für virtualisierte Gastsysteme eingesetzt werden.

Ein typischer Anwendungsfall für einen Freelancer, der primär auf Linux setzt, ist die Virtualisierung von MS-Windows-Gastsystemen. (Leider braucht man für die effiziente Kooperation mit den meisten Kunden ja weiterhin MS-Windows Programme 🙁 ) Weil wir gerade dabei sind: Als Linux-Profi ist man sich hoffentlich der Tatsache bewusst, dass virtualisierte Windows-10-Clients in Standardausführung zumindest potentiell eine Bedrohung der gesamten Geheimhaltungskette darstellen können (https://www.lda.bayern.de/media/windows_10_report.pdf; Heise Artikel zum Bundesclient). Wir werden dieser Problematik im Rahmen der Artikelserie noch mal gesondert Raum widmen müssen.

Virtualisierung ist aber auch ein gutes Mittel zur Separation von Arbeits- und Kunden-Domänen. Das betrifft einerseits eine getrennte Haltung und Bearbeitung der Daten spezifischer Kunden; es betrifft aber auch die Kommunikations- und Netzwerkfähigkeiten der kundenbezogenen Gastsyteme: Man kann die Netzwerk-Kommunikation von Gastsystemen für den kundenbezogenen Einsatz auf ganz bestimmte Server – z.B. die des Kunden – einschränken und entsprechende ausgehende und eingehende Verbindungen überwachen.

Web-Browsing und den nicht kundenbezogenen Mail-Verkehr verlagert man dagegen auf einen anderen abgegrenzten Gast des Laptop-Hosts mit minimaler Ausstattung. Nebenbei: Die Abtrennung von Prozessen und Daten von Gästen gegeneinander und gegenüber dem Host ist bei KVM/QEMU-Vollvirtualisierung deutlich besser gewährleistet als bei Containern.

Voll-Virtualisierung bietet also zusätzliche Möglichkeiten, die Sicherheit der Interaktion mit Kundensystemen insgesamt zu verbessern. Man sollte das Thema deshalb im Kontext einer Verschlüsselungsstrategie berücksichtigen. Ich gehe im vorliegenden Beitrag allerdings nur auf einige Aspekte des Themas “Virtualisierung und Verschlüsselung” ein. Ich bezeichne dabei – wie im letzten Beitrag – sowohl LVM-Volums als auch echte Partitionen als “Volumes”. Das root-Filesystem kürze ich mit “/”-FS ab.

Continue reading

Laptop – SSD mit dm-crypt/Luks – Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen

Eine Verschlüsselung von Daten auf Laptops ist in Zeiten der DSGVO Pflicht, da Laptops verloren gehen oder gestohlen werden können. Mein in die Jahre gekommener Laptop benötigt eh’ eine neue SSD. Zudem muss ich auf Opensuse Leap 15 wechseln. Gute Anlässe, einmal die Verschlüsselung von Betriebssystem- und Daten-Partitionen unter Opensuse Leap 15 zu testen.

Die meisten Linux-Profis setzen die Kombination “dm-crypt/LUKS” zur Verschlüsselung von Partitionen oder Volumes ein. Dabei spielen verschiedene Parameter eine Rolle, für die unter Opensuse normalerweise der YaST-basierte Partitioner Default-Werte vorgibt.
Ich nahm mir allerdings die Freiheit, die LUKS-Partitionen selbst mit eigener Parameter-Setzung vorzubereiten. Danach wurde das ganze Unternehmen unerwartet abenteuerlich und es taten sich etliche Falltüren auf. Es gab u.a. Probleme mit dem SuSE-Installer; nicht mehr bootfähige Systeme, nicht funktionales Kryptographie-Setup, Dracut-Probleme sind nur einige Stichworte. Man glaubt, man hat eine Lösung und schon zieht ein Neuinstallieren des Bootloaders über YaST alles wieder in den Abgrund.

Ich denke, das Thema “Voll-Verschlüsselung eines Linux-Laptops” ist einige Blog-Posts wert … Viele der angestellten Überlegungen und Vorgehensweisen können auch auf Desktops oder einfache Server übertragen werden.

Der ganze Themenkreis erfordert neben praktischen Installations- und Konfigurations-Schritten einige “theoretische” Vorüberlegungen. Verschlüsselung allein bietet keine hinreichende Sicherheit … man muss u.a. auch an Konsequenzen für den praktischen Betrieb des Systems denken – besonders im falle von Laptops. Zudem kann man sehr verschiedene Wege bzgl. des System-Layouts einschlagen. Einige wichtige unter vielen Variationsmöglichkeiten ergeben sich etwa aus der Beantwortung folgender fragen:

  • Vollverschlüsselung unter Einschluss des root-Filesystems oder Einsatz von Daten-Containern?
  • Vollverschlüsselung des Hosts oder nur darunter virtualisierter Systeme?
  • LVM on LUKS oder LUKS on LVM?

Die entsprechende System-Konfiguration erfordert meist Entscheidungen im Vorfeld der praktischen Installation. Ich beginne die Artikelserie deshalb it einer Reihe grundsätzlicher Überlegungen, die praktische Auswirkungen auf die Sicherheit der Daten haben.

Um eine ständige Unterscheidung zwischen LVM-Volumes und Partitionen zu vermeiden, spreche ich nachfolgend generell von “Volumes“. An den Stellen, wo die Unterscheidung wichtig wird, werde ich sie explizit treffen. “Betriebssystem” kürze ich im Weiteren mit OS ab. Das root-Filesystem kürze ich mit “/”-FS ab.

Ich setze ein grundlegendes Verständnis der Arbeitsweise von LUKS voraus. Für Grundlagen können Interessierte einen Blick in frühere Blog-Posts werfen; dort sind auch Links zu weiterführender Literatur im Internet angegeben:
dm-crypt/Luks – Begriffe, Funktionsweise und die Rolle des Hash-Verfahrens – I
dm-crypt/Luks – Begriffe, Funktionsweise und die Rolle des Hash-Verfahrens – II

Unterscheidung Vollverschlüsselung – Teilverschlüsselung

Wir unterscheiden im Folgenden zwischen Voll- und Teil-Verschlüsselung. Unter einer Voll-Verschlüsselung verstehe ich einen Ansatz, in dem

  • sowohl das Volume für das OS, mit dem auf die zu schützenden Daten zugegriffen wird,
  • als auch separate Volumes zur Lagerung der zu schützenden Daten,
  • als
    auch Swap-Volumes

verschlüsselt werden. Bei Abweichungen spreche ich von Teil-Verschlüsselung.

Continue reading

Libreoffice 6.0 und 6.1 Draw unter KDE/Plasma und Gnome – mit gtk3-Unterbau viel zu langsam

Einer meiner treuen Begleiter war Libreoffice Draw. Aber nach dem Upgrade auf Opensuse Leap 15 hatte ich damit beim Arbeiten mehr Frust als Lust. Ich muss z.Z. Skizzen einer Art neuronaler Netzwerke erstellen. Da kommen mal schnell 50 bis zu über hundert Einzelobjekte zusammen, die in großer Anzahl durch “Verbinder” aneinander gekoppelt werden müssen.

Das aktuelle Draw der Libreoffice Versionen 6.0 und 6.1 ist unter einem KDE-System mit GTK3 dafür aber viel zu langsam:

Klickt man auf das Symbol für “Verbinder” in der Leiste für Zeichnungstools, so dauert es auf hochauflösenden Schirmen (2K bis 4K) und bei komplexen Zeichnungen zwischen 4,5 und 8 Sekunden, bis die Zeichnung auf eine Darstellung mit allen Connector-Punkten der Objekte wechselt.

Ich habe nun wahrlich kein langsames System; auch die Speichereinstellungen für LO habe ich bereits (mühsam; s.u.) nach oben gesetzt. Während des Darstellungswechsels für Verbinder geht die Belastung des genau einen CPU-Kerns, den LibreOffice leider nur nutzt, kurzzeitig auf 100%.

Bei einer normalen “LO 6”-ImplementierungInstallation ist das Paket “libreoffice-gtk3” installiert; GTK3 wird dann automatisch gezogen. Ein gezielter Start für GTK3 ist im Terminal mit “SAL_USE_VCLPLUGIN=gtk3_kde5 libreoffice &” möglich. Nun kann man sich zusätzlich das Paket “libreoffice-gtk2” installieren und den Aufruf zu “SAL_USE_VCLPLUGIN=gtk_kde5” abändern.

Ein nachfolgender Test zeigt, dass die Zeiten beim Einsatz von GTK2 im Bereich von 2-3 Sek. liegen! Damit kann ich gerade noch leben. Weitere Tests offenbaren Folgendes:

Die Geschwindigkeit, mit der Draw die Anzeige von Connector-Punkten aller Objekte auf den Schirm bringt, hängt vom Zoomfaktor ab, mit der man sich das odg-Dokument anzeigen lässt; kleine und große Zoom-Faktoren machen den Umgang mit Verbindern bisweilen deutlich schneller.

Wer also große Diagramme mit vielen Objekten und Verbindern zeichnen will, sollte im Umgang mit Libreoffice 6.1 auf GTK3 verzichten. Zumindest unter KDE. Das kann man dort entweder durch den Aufruf

SAL_USE_VCLPLUGIN=gtk_kde5 libreoffice &

erreichen, oder aber indem man das Paket libreoffice-gtk3 deinstalliert und dafür das Paket “libreoffice-gtk2” installiert (neben libreoffice-qt5). Ein Verzicht auf gtk2 und gtk3 sowie eine alleinige Installation von libreoffice-qt5 führt vom Layout her übrigens in die GUI-Steinzeit. Ob das so richtig ist, mag ich im Moment nicht einmal recherchieren.

Nun habe ich auch das Rendern über OpenGL ausprobiert – funktioniert leider nicht => Schwarze Menüs. Ansonsten wäre der Aufbau der Zeichnung selbst etwas schneller …
Tests unter Gnome und LXDE brachten leider die gleichen Ergebnisse.

Ich hoffe auf Updates – und darauf, dass sich die LO-Entwickler endlich mal Gedanken darüber machen, an welchen Stellen sich Multithreading lohnen würde. Der Umgang mit Verbindern wäre da ein erstes gutes Betätigungsfeld. So wie der Stand im Moment im Zusammenspiel von Draw mit GTK3 aussieht, sind LO 6.0 und 6.1 jedenfalls eine Enttäuschung.

P.S. zum Thema Menü-Änderungen: Hinzu kommt der sich auch unter Kontact/Kmail ausbreitende Ehrgeiz von Maintainern, bewährte Menüpunkte für Programm-Einstellungen, die die Performance und die RAM-Nutzung einer Applikation beeinflussen, aus dem normalen Menübereich in eine völlig unübersichtliche und undokumentierte globale Parameter-Konfiguration zu verbannen. So geschehen bei Kmail; so geschehen bei LO.

Liebe Leute: Seit wann bieten wir dem User unter Linux weniger Optionen an?
Und seit wann wird Bewährtes und Verständliches in der Menüstruktur zugunsten unverständlicher und undokumentierter Parameter-Kaskaden aufgegeben? Bitte liebe LibreOffice-Teams: Hört mit diesem falschen Ehrgeiz an Options-Verlagerung und -Vernichtung auf … und kümmert euch lieber mal um die Performance.

Nachtrag 19.10.2018 zur Performance: Es ist inzwischen insgesamt ein wenig besser geworden (LO 6.1.3); dennoch geht das Arbeiten mit Verbindern in DRAW unter GTK2 immer noch schneller von der Hand als unter GTK3.