Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – III – Zugriffs-Layer

In den letzten Beiträgen dieser Serie

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

hatten wir Vorüberlegungen zur Verschlüsselung eines Laptops angestellt. Wie in den früheren Beiträgen auch bezeichne ich nachfolgend sowohl Partitionen als auch LVM-Volumes als "Volumes". Wenn eine Unterscheidung notwendig ist, werde ich die explizit treffen. Für das root-Filesystem benutze ich die Abkürzung "/"-FS.

Das wichtigste Ergebnis unserer bisherigen Überlegungen war, dass wir das System, auf dem wir mit den zu schützenden Kundendaten arbeiten, voll verschlüsseln müssen. Das bedeutet, dass wir sowohl das Volume für das "/"-FS, als auch den SWAP sowie auch alle Volumes für Daten verschlüsseln. Es reicht nicht, mit Datencontainern zu arbeiten.

Unser zweites Ergebnis war: Wir sollten diesen Ansatz auf einem Virtualisierungs-System (LVM/QEMU, LXC) zur Sicherheit sowohl auf die Volumes anwenden, die der Host selbst nutzt, als auch auf alle Volumes, die von den Betriebssystemen der Gäste genutzt oder zusätzlich gemountet werden. Sprich: Auch der Virtualisierungshost muss voll-verschlüsselt werden (Root-Filesystem, Swap (!), Daten-Volumes). Es gibt zu viele Faktoren, durch die Inhalte der Gastsysteme auf Host-Filesysteme geraten können.

Wir hatten ferner diskutiert, dass im Prinzip sowohl das Host-System auf dem Laptop als auch die Gast-Systeme selbst ihren Teil zur Verschlüsselung beitragen können. Dieses Thema hat nicht zuletzt auch mit der Schichtung der Zugriffsverfahren auf Storage-Devices und Filesysteme zu tun: Jeder, der mit Linux professionell arbeitet, nutzt früher oder später LVM, um bzgl. der Anpassung der Größe von Filesystemen für Hosts und Gäste flexibel zu werden. Wie bringt man LVM mit der LUKS-Verschlüsselung zusammen? Wie stellt sich das im Fall von Virtualisierung dar?

Ein anderer für die Praxis wichtiger Punkt ist die Kompatibilität von Verschlüsselungsverfahren für Volumes mit Boot-Managern und auch systemd. Kann der unter Linux wohl hauptsächlich eingesetzte Grub2-Manager mit verschachtelten LVM/LUKS- oder LUKS/LVM-Strukturen auf Block-Devices umgehen?

Der nachfolgende Artikel geht aus grundlegender Perspektive auf diese Fragestellungen ein. Spätere Artikel widmen sich dann der praktischen Umsetzung.

Weiterlesen

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.

Weiterlesen

Bumblebee auf Optimus-Notebooks und Laptops mit Opensuse 13.1 / 13.2 / Leap 42.1

Da mein früherer Artikel zu diesem Thema
https://linux-blog.anracom.com/2015/06/11/bumblebee-auf-laptops-mit-opensuse-13-1-13-2/
etwas veraltet ist und zu einer nicht mehr funktionierenden Schalterfunktion für die Nvidia-Karte führt, hier eine neue Zusammenstellung der Schritte, mit denen ich Bumblebee auf Optimus-Systemen zum Laufen gebracht habe. Getestet habe ich das auf einem Laptop mit "i7-3632QM" Prozessor mit integrierter Intel HD 4000 Grafikkarte; ferner existiert eine zusätzliche Nvidia GT 645M. Ich erläutere die Installation für Opensuse 13.1; für 13.2 und Leap 42.1 geht alles ganz analog (und funktioniert auch) - nur sind andere Repositories zu wählen.

Installation und Einrichtung von Bumblebee

Folgende RPM-Repositories sollte man der SW-Verwaltung unter YaST für Opensuse 13.1 Installationen verfügbar machen:
http://download.opensuse.org/repositories/X11:/Bumblebee/openSUSE_13.1/
http://download.opensuse.org/repositories/home:/Bumblebee-Project:/Bumblebee/openSUSE_13.1/
http://download.opensuse.org/repositories/home:/Bumblebee-Project:/Bumblebee3/openSUSE_13.1/
http://download.opensuse.org/repositories/home:/Bumblebee-Project:/nVidia:/364.19/openSUSE_13.1/

Unter Opensuse 13.2 bzw. Leap 42.1 ist "13.1" in den Adressen natürlich jeweils durch "13.2" bzw. "LEAP_42.1" zu ersetzen.

Will man eine neueren Nvidia-Treiber nutzen, findet man eine Auswahl an entsprechenden Repositories unter
http://download.opensuse.org/repositories/home:/Bumblebee-Project:/nVidia:/

In meinem Fall habe ich einen Mix aus verschiedenen Versionen der notwendigen Pakete aus den oben genannten Repositories verwendet. Vorsichtigere Menschen sollten sich aber konsequent für konsistente Pakete aus dem Bumblebee3 Repository entscheiden. Das dkms-Paket nehme ich allerdings immer aus dem Repository für den Nvidia-Treiber.

Man muss halt schauen, ob es Probleme gibt. U.U. funktioniert z.B. das Schließen von Anwendungen nicht ganz richtig, etc..
Interessant ist es nach einer Installation auch immer, komplexere 3D- Anwendungen wie z.B. Alienarena mal mit

primusrun alienarena

und danach mit dem Aufruf

optirun alienarena

zu starten. Beides sollte funktionieren; tut es aber bei manchen Kombinationen der Paketversionen nicht. (Off Topic: Alienarena nimmt ungefragt Verbindungen zu einem Server im Internet auf, auch beim Single Player Modus; wer das nicht mag, kann es über Nutzen von "Host Server" im Menü unterbinden, eine Firewall nutzen oder schlicht das Netzwerk deaktivieren.)
Es bleibt einem halt leider nur auszuprobieren, welche Zusammenstellung von Paketversionen auf seinem eigenen System korrekt läuft.

Bei mir ist mit den Paketen aus dem Bumblebee3-Repo alles in Ordnung; folgende Versionen habe ich konkret installiert:
bumblebee1
bumblebee2

Entscheidend ist die Installation des Nvidia-Kernel-Modules "nvidia" über das Paket "X11-video-nvidia" aus dem 4-ten Repository. Während der Installation wird die erforderliche Kompilation für den aktuellen Kernel vorgenommen.

Blacklisten des nouveau-Treibers

Nach einer Neuinstallation von Opensuse auf einem Laptop mag es sein, dass der Nouveau-Treiber installiert ist. Ich habe Bumblebee bislang nicht mit dem Nouveau-Treiber ausprobiert, sondern aus verschiedenen Gründen immer den proprietären Nvidia-Treiber (erfolgreich) genutzt. Damit dies möglich wird, muss der Nouveau-Treiber, soweit auf dem Laptop-System vorhanden, deaktiviert werden. Ich habe ihn deshalb zur Sicherheit in eine Blacklist für Kernelmodule aufgenommen. Die Dateien "/etc/modprobe.d/50-blacklist-nouveau.conf" und auch "/etc/modprobe.d/50-blacklist.conf" enthalten somit folgende Statements:

blacklist nouveau
options nouveau modeset=0

Keine Installation des proprietären Nvidia-Treibers über das Linux-Installationsprogramm von der Nvidia-Web-Seite!

Versucht weder während der Opensuse-Erstinstallation noch später den proprietären Treiber von Nvidia mit den Installationsroutinen von der Nvidia Webseite zu installieren! Das wird in einer Optimus-Konfiguration zu keinem Erfolg führen! Der proprietäre Nvidia-Treiber sollte auf Optimus Laptops statt dessen immer aus dem oben genannten "Bumblebee-Project:/nVidia"-Repository geladen werden.

KMS nicht abschalten!

KMS (Kernel mode setting; s. http://de.wikipedia.org/wiki/Mode-Setting) wird für das "i915"-Modul (also den Treiber für die Intel Graka) zwingend benötigt - DKMS sollte man also (im Gegensatz zu früheren Desktop-Installationen mit Nvidia-Karten) nicht über Kernelparameter wie "nomodeset" beim Starten des Systems deaktivieren.

Ferner gilt: Das Opensuse Community Repository für Nvidia Treiber sollte deaktiviert sein; keines der Nvidia RPMs - sprich kein Nvidia-Treiber-Paket - aus diesem Community Repository sollte installiert sein oder werden.

Welche Services sind zu aktivieren?

Folgende Services müssen für den Systemstart unter systemd ggf. noch explizit aktiviert werden:

systemctl enable bumblebeed.service
systemctl enable dkms.service

Desktop-User als Mitglied der Gruppe "bumblebee" einrichten

Zudem muss der User, unter dem man den Desktop nutzt, Mitglied der ggf. neu anzulegenden Gruppe "bumblebee" werden.

xorg.conf-Datei

Es lohnt sich ein Blick in das Verzeichnis /etc/bumblebee": Dort befindet sich eine spezielle Datei "xorg.conf.nvidia", die von Bumblebee genutzt wird. Eine evtl. vorhandene "/etc/X11/xorg.conf" im Verzeichnis "/etc/X11" sollte man entfernen !

Neustart des Systems - KDE Desktop mit 3D Effekten über den Intel Grafikkartentreiber

Sind alle Voraussetzungen geschaffen, startet man das System am besten neu. Man sollte dann auf der gewohnten Desktop-Oberfläche landen. Diese wird vom Intel Treiber - in meinem Fall vom kernel-Modul "i915" - gesteuert. KDE-3D-Effekte lassen sich auch über die Intel-Grafikkarte nutzen; dafür reicht deren Performance allemal.

"lsmod" sollte folgende Module anzeigen, die im Zusammenhang mit Grafik von Bedeutung sind:

i915 710403 8
bbswitch 13943 0
drm 313440 11 i915,drm_kms_helper
drm_kms_helper 56806 1 i915
video 19507 1 i915
button 13952 1 i915
thermal_sys 36646 5 x86_pkg_temp_thermal,intel_powerclamp,thermal,video,processor
 
videobuf2_core 44595 1 uvcvideo
videodev 141701 2 uvcvideo,videobuf2_core
videobuf2_vmalloc 13216 1 uvcvideo
videobuf2_memops 13362 1 videobuf2_vmalloc

Start von 3D-Anwendungen

Spezielle 3d-Applikationen, wie etwa Spiele (z.B. "alienarena")oder OpenGL-Anwendungsprogramme, die mehr Rechenpower erfordern, kann man dann als Desktop-User über

optirun alienarena

oder

primusrun alienarena

starten.

bumblebee4

"primusrun" reduziert die Framerate der Graka auf die Schirmrate, wenn keine weiteren Parameter angegeben werden. Frame- und vertikale Bildschirmfrequenz werden also synchronisiert. Für volle Performance muss man

vblank_mode=0 primusrun alienarena

benutzen.

Folgender Artikel liefert ein paar Hinweise zum ursprünglichen Unterschied zwischen "primusrun" und "optirun": http://www.webupd8.org/2012/11/primus-better-performance-and-less.html
Faktisch sind die aktuellen Performance-Unterschiede zwischen "primusrun" und "optirun" auf meinem System jedoch minimal.

"lsmod" zeigt nach dem Starten einer 3d-Applikation dann folgende zusätzlichen Module an:

nvidia 8370147 37
drm 313440 11 nvidia,i915,drm_kms_helper

Aufruf des Tools nvidia-settings

Übrigens: Das Tool "nvidia-settings" ruft man wie folgt auf:

optirun -b none nvidia-settings -c :8

Ab- und An-Schalten der Nvidia-Karte im normalen Desktop-Betrieb

"optirun" und "primusrun" aktivieren die Nividia-Karte bei Bedarf selbständig und deaktivieren sie auch wieder - wenn die geladenen Pakete richtig zusammenarbeiten. Zum gezielten Abschalten der Nvidia-Karte im normalen Desktop-Betrieb benutzt man als root-User dagegen folgendes Kommando:

tee /proc/acpi/bbswitch <<< OFF

Anschalten geht über

tee /proc/acpi/bbswitch <<< ON

Der Laptop zeigt die Aktivität der Nvidia-Graka i.d.R. über eine LED an. Ein gezieltes Anschalten im normalen Desktop-Betrieb kann dann nützlich sein, wenn man - wie in meinem Fall - durch ein erratisches Anspringen des Laptop-Lüfters gerade bei zu kühlem Zustand des Laptops genervt wird. Manchmal hilft die zusätzliche Abwärme der Nvidia-Graka im Leerlauf, einen kontinuierlichen Lüfterbetrieb zu erzwingen.

Startbedingungen zum An- und Abschalten der Nvidia Graka legt man über entsprechende Parameter in der Datei "/etc/modprobe.de/50-bbswitch.conf" fest:

options bbswitch load_state=0 unload_state=1

Was ist nach einem Kernelupdate und Neustart des Systems zu tun ?

Nach einem Kernelupdate läuft der "intel915" Treiber ja typischerweise noch. Man gelangt dadurch auf die grafische Oberfläche. Am einfachsten ist dann eine Deinstallation und anschließende Neuinstallation der oben dargestellten Pakete aus den Bumblebee Repositories - u.a. dkms, dkms-nvidia, bbswitch, vor allem aber "X11-video-nvidia". Der Nvidia-Treiber wird dabei neu kompliert.