Nvidia: 2 Sicherheitslücken im Linux-Treiber

Zwei Sicherheitslücken sind im NVIDIA GFX-Kartentreiber für Linux enthalten, wenn Ihr noch nicht die brandaktuellste Version haben solltet, was schwierig sein dürfte.

Nvidia: 2 Sicherheitslücken im Linux-Treiber

Laut der Bugbeschreibung bei Nvidia, handelt sich dabei bei einer Lücke um einen Bug in der IPC Communication API, was man braucht um Daten zwischen einzelnen Prozessen hin und her zu schicken. Dieser Fehler kann dazu genutzt werden um mit erweiterten Rechten eingeschleusten Code auszuführen.

CVE-IDs
Addressed
Software ProductOperating SystemDriver BranchAffected VersionsUpdated Versions
CVE‑2020‑5963
CVE‑2020‑5967
GeForceLinuxR450All versions prior to 450.51450.51
Quadro, NVSLinuxR450All versions prior to 450.51450.51
R440All versions prior to 440.100440.100
R390All versions prior to 390.138390.138
TeslaLinuxR450All R450 versionsAvailable the week of June 29, 2020
R440All versions prior to 440.95.01440.95.01
R418All versions prior to 418.152.00418.152.00

Die zweite Schwachstelle ist dann schon schwieriger auszunutzen, da eine RACE Condition ist, es kämpfen also zwei Prozesse um eine Ressource. Der Gewinn des RACE würde einen DOS erlauben. Was ein Angreifer auf einem DesktopPC davon haben würde die Grafikkarte zu crashen, naja. Ist trotzdem gut, daß es gefixt wurde.

Für Fedora lautet die Treiberversion für meine GFX-Karte 440.82 und muß daher aktualisiert werden. Da diese aus dem Repo von RPMFusion stammt, dürfte der Verbreitungsgrad und damit der Updatezwang unter Fedora/Centos/RHEL Benutzern entsprechend hoch sein. Wie das zu Problemen führen kann und was man das machen muß, lest Ihr hier: Nvidia, Fedora, RPMFusion und der Bug, der nicht sein soll.

Bei RPMFusion habe ich heute schon angeklopft, daß Updates benötigt werden.

Quelle: https://nvidia.custhelp.com/app/answers/detail/a_id/5031

Vollversagen bei OpenSSH: Is a directory

Nehmt es mir nicht übel, aber anders als ein komplettes Versagen auf ganzer Linie kann man den Fall bei OpenSSH nicht bezeichnen, zumal es um einen kleinen, aber sinnvollen Bugfix geht.

Vollversagen bei OpenSSH: „Is a directory“

Damit Ihr versteht um was es geht, müssen wir zurückreisen ins Jahr 2010. Damals wurde ein Bugreport im Bugtracker von OpenSSH veröffentlicht: https://bugzilla.mindrot.org/show_bug.cgi?id=1768

Von dem wußte ich aber nichts, als ich 2015 über das Problem gestolpert bin. Das Problem sieht wie folgt aus:

scp testdatei user@servername:/topdir/subdir/

Wenn es „subdir“ als Directory gibt, dann wird testdatei dahin kopiert und alles ist gut. Wenn es „subdir“ aber nicht gibt, dann würde man ja wohl erwarten, eine Fehlermeldung zu bekommen, aus der genau das hervorgeht, oder? Tja, wie soll ich sagen, ähm…nein!

Actual results:

scp: /usr/doesnotexist/: Is a directory

Wow.. oder? Das komplette Gegenteil von dem was man annehmen würde 🙂 Diese Aussage bekommt jeder, der sich OpenSSH selbst aus den original Sourcen kompiliert, denn, obwohl der Fehler schon 2010 gemeldet wurde und 2015 Jakub Jelen von Red Hat einen kompletten Patch geschrieben hat und das seit Fedora 20 und RHEL8 an alle „Nutzer“ in einem „Feldtest“ ausgerollt wurde, sieht sich das Projekt hinter OpenSSH nicht dazu in der Lage.

Eingeführt wurde der Bug übrigens um das Jahr 2005 herum. Damit sind es streng genommen schon 15 Jahre, die der Bug da vor sich hin dümpelt. Da ich Fedora nutze, habe  ich das Problem nicht mehr und viele andere Distros haben den RH Patch übernommen, aber traurig ist das schon, oder?

Leider mußte ich gerade feststellen, daß die neue Fehlermeldung auch nicht gerade viel besser als die alte ist:

scp: /tmp/ugdjkfh/: Not a directory

Das stimmt zwar inhaltlich, gibt aber den wahren Ursprung meiner Meinung nach nur unzureichend wieder 😉 Daher war ich mal so frei, Jakub darauf hinzuweisen, zumal ich den Bug da auch bei RH reportet hatte, vielleicht bekommt man nach 10 Jahren dann doch nochmal ein „Does not exist“ 😀 Wobei man als Server ja unterscheiden können muß zwischen „directory gibts nicht“ und „Du User, darfst da nicht reinschreiben“ unterscheiden wenn so eine Anfrage kommt, sonst könnte ein User niedriger Privilegierung die Verzeichnisstruktur einfach durchtesten. Ok, er könnte das viel einfach, wenn er eingeloggt wäre, aber ggf. hat der Account nur SFTP Zugang, ohne Interaktiven Shellzugang zu haben. Wäre ja denkbar.

Wie man sieht, doch nicht ganz trivial so eine saubere Fehlermeldung 😉

Wenn Ihr jemanden im OpenSSH Team kennt, könnt Ihr Ihn ja mal auf dieses Problem ansprechen. Übrigens erinnert mich das ganz stark an meinen Bugreport an ProFTP, weil deren 20 Jahre alte CHROOT Anweisung den Fall, daß da einer das Ziel per Symlink umgeleitet hat, nicht abgedeckt hatte. Das wurde auch Jahrelang geblockt bis es dann doch wer geschafft hatte, die Entwickler umzustimmen. Leider durfte ich mit dem 20 Jahre Bug-Jubiläumsvortrag nicht auf dem CCC sprechen. Dabei wollte ich nur son 15 Minuten Vortragsfenster im Nebenraum haben. Ich hatte denen sogar einen Patch für das Problem geschickt. Das wäre bestimmt lustig geworden, wenn die ProFTP Devs sich auf der Vortragsliste gesehen hätten 😀 Vielleicht packe ich Euch den Vortrag als PDF mal auf die Seite.

Es war einmal ein Sambashare …

und dann kam Fedora 31 daher. Ich habe Zuhause diverse Geräte, die sich von meinem PC Videos in die Küche, ins Bad, ins hiesige Bett oder ins Hotelbett nach Paris ziehen können, falls NetFlix ausfällt 🙂

Es war einmal ein Sambashare …

Nun ist da ein älteres AOS4 Gerät dabei, welches außer Emails eigentlich nur als Unterhaltungsquelle für NetFlix oder meine eigene Videothek dient. Das liegt daran, daß es praktisch nichts wiegt und der Akku trotz des Alters lange hält. Die Rechenleistung reicht auch genau noch dafür aus, bei FHD wirds schon schwierig bis geht gar nicht mehr.

Jetzt stand der Wechsel auf Fedora 31 wegen Fedora 30 EOL sowieso an, also habe ich das 7.000 Schritte Update gestern mal gemacht. Das lief technisch gut, aber sehr lange und das trotz SSD. Nach dem Reboot gabs dann das von Windows schon bekannte Durchbooten ohne Bildschirm zucken. Wers mag, bitte. Bis auf ein VNC Problem in Python, das sich durch rustikales Nachinstallieren mit Gewaltandrohung von alten Paketen lösen lies, gab es keine nennenswerten Probleme.

Heute wollte ich dann in der Küche beim Mittag mal etwas laufen lassen, aber das bislang genutzt Programm meinte nur so, daß kein Server da wäre. Also habe ich nachgesehen, aber der Server war da. Das gleiche Programm, aber mit AOS5 als Basis, konnte den Sambaserver auch finden und nutzen, aber die AOS4 Version davon nicht. Das finde ich jetzt schon so komisch, daß ich dem Dev da mal eine Email geschrieben habe. Leider gabs noch keine Reaktion, falls die jemals kommen wird.

Also habe ich etwas geforscht und der Unterschied zu Fedora 30 war bei Samba, daß es dort noch Version 4.10.15 war und jetzt 4.11 ist. Mit 4.11 wurde per default NT1 aka Samba 1 deaktiviert. Nach sehr viel rumraten, weil Lösungen aus dem Netz dafür verliefen alle samt im Sande, hatte ich dann doch einen Weg gefunden:

[global]


client min protocol = NT1
server min protocol = NT1
security = user
ntlm auth = ntlmv1-permitted

Wenn man obiges in die /etc/samba/smb.conf einträgt und neustartet, dann geht auch wieder mit AOS4 Programmen 😉

Wenn Ihr das mal selbst testen müßt: smbclient -L //IP.ADDR/

Wenn da was angezeigt wird und in eurem Programm nicht, dann liegts an Eurem Programm 😉

 

Die kleine Zicke von Nebenan

Ihr habt doch noch Coronapause, da wird Euch dieser kleine Bericht aus der HP Plotterwelt bestimmt gelegen kommen 🙂

Die kleine Zicke von Nebenan

Gestern zog im Raum nebenan ein neuer HP Plotter T830 MFP ein. Nachdem man sich begrüßt hatte, sprach der Hauseigentümer: „Das Gerät sollte sich eigentlich leicht installieren lassen, ist doch von HP.“ sprachs und verschwand um die Ecke. Nun, „Konfigurieren“ war tatsächlich am Gerät möglich und daher bekam der HP die gleiche IP wie der alte Plotter.

Damit wäre die Sache technisch eigentlich erledigt, denn die Plotter sind befehlskompatibel; „Plotten“ hätte also funktionieren müssen und tatsächlich tat es das auch. „Na HP, dann lass uns doch dem Druckerserver mal erklären, daß Du einen anderen Plotter bist.“. Das hätte man den Drucker lieber mal nicht androhen sollen 🙂

Zwei, Drei Sachen noch erledigt und schon konnte man sich auf dem Druckerserver einloggen und das CUPS Interface aufrufen. Suchen wir doch mal nach dem neuen Drucker… waiting… da meinte CUPS: „Keinen neuen Drucker gefunden.“ .. „Kann doch nicht sein, der wurde doch von dem Testpc gefunden.“  … Hmm, vielleicht sucht er ja nicht auf Geräte-IPs die er schon kennt, also alten Drucker gelöscht. „Such CUPS! SUCH!“ … waiting… CUPS: „Kein neuer Drucker gefunden!“  .. nochmal!  „Nein heißt NEIN!“ …. ?????

… versuchen wir doch mal HPLIP

„Hmm.. als CUPS findet den nicht… versuchen wir mal das HP eigene HPLIP System“ … kurz installiert:

dnf -y install hplip hplib-gui

und „hp-setup“ gestartet.. Da wählt man dann „im Netzwerk suchen“ aus und schon … „N.Ö.P.E.!“ … auch das Tool findet den Drucker nicht. Das kann doch nicht sein! Oder doch? Plotter vielleicht gestorben? Netzwerk tod?

„OK Plotter… HARD RESET“

Ein „Strom aus“ später … „… und so startete der Plotter neu… und der Admin fand im TCPDUMP auch jede Menge HP Drucker Kommunikation, die vorher nicht da war 😀 Einen NMAP Scan später, meinte die tote IP vom Plotter plötzlich jede Menge Dienste anbieten zu müssen.  „OH“ sagte der Admin und lies „hp-setup“ nochmal suchen! … „NÖPE! KEINE HP DRUCKER IM NETZ!“.

„WTF!“ .. und was jetzt kommt, kann ich nur rational wiedergeben, sonst stirbt wer: Die lustige HP Software kontaktiert den Drucker nicht mal auf den richtigen Ports, selbst wenn man die exakte IP angibt und das Protokoll auswählt. Es schlägt knallhart vor, daß die Firewall wohl Schuld sei, welche testweise aus war (nur um ganz sicher zu gehen).

„OK.. lass doch jetzt wo der Drucker wieder lebt, CUPS mal nachsehen“ gedacht, getan und oh Wunder! CUPS findet den Drucker … einmal… zweimal … dreimal!  Vermutlich für jeden der angebotenen Dienste ist da vermutlich ein Treffer vorhanden.

„Besser drei Treffer als Null!“

Ok, Plotter eingerichtet, Testseite gedruckt…. GEHT!  Statt aus dem Papierfach A3 zu drucken, plöttelte der Plotter das brav von der großen Rolle ( A0 ), obwohl das anders eingestellt ist. Da experimentieren wir noch ein bisschen.

Den Grund für das Such-Fiasko wird man vermutlich im Energiesparmodus finden, der sich nämlich nicht ausstellen läßt und einen 15 Minuten Timeout eingestellt hatte. Das werden wir morgen nochmal testen.

Merke

Wenn Du einen Drucker von HP nimmst, löscht die HP Druckersoftware!

Schwachstelle in Thunderbird < 68.7

Es ist eigentlich schon gute Tradition, daß Thunderbird zwei-drei Tage nach Firefox aktualisiert werden muß. Ratet mal, es ist mal wieder soweit 🙂

Schwachstelle in Thunderbird < 68.7

Wer jetzt Updaten möchte, hier ist das FC30 Paket:

https://kojipkgs.fedoraproject.org//packages/thunderbird/68.7.0/1.fc30/x86_64/thunderbird-68.7.0-1.fc30.x86_64.rpm

Es handelt sich (natürlich) um die gleichen Lücken im Javascript, die auch im Firefox < 75.0 drin waren.

Security Update: Firefox 75 ist da

Da hatten wir quasi gestern erst die Meldung, daß wir uns 74.0.1 updaten müßten und schon müssen wir auf Firefox 75.0 updaten, weil auch in der 74.0.1 ein Sicherheitsloch von der Größe New Yorks klafft 🙁

Security Update: Firefox 75 installieren

Hier könnt Ihr Euch vorab die Firefox Versionen für Eurer Fedora ziehen:

https://kojipkgs.fedoraproject.org//packages/firefox/75.0/1.fc30/x86_64/firefox-75.0-1.fc30.x86_64.rpm

https://kojipkgs.fedoraproject.org//packages/firefox/75.0/1.fc31/x86_64/firefox-75.0-1.fc31.x86_64.rpm

https://kojipkgs.fedoraproject.org//packages/firefox/75.0/1.fc32/x86_64/firefox-75.0-1.fc32.x86_64.rpm

Die Installation ist dann ganz einfach, wenn Ihr mit der Konsole im Downloadverzeichnis seid:

sudo dnf update ./firefox-75*rpm

Ein Doppelklick per Dateiexplorer geht natürlich auch, dann öffnet sich die Softwareverwaltung und fragt Euch nach dem Rootpasswort und schon wird es auch so installiert.

Der erste Eindruck ist leider „AAAAARGGGS!“ weil die Adressleiste wird jetzt abartig groß! Das sieht so dämlich aus!

Fedora 30 Firefoxupdate 74.0.1 verfügbar

Mit dem Security-Update von Firefox auf 74.0.1 gab es eine Probleme beim Bau des Paketes, die konnten heute endlich ausgeräumt werden.

Fedora 30 Firefoxupdate 74.0.1 verfügbar

Wer sich gleich das Update saugen möchte, weil er/sie/es zu recht nicht mehr warten kann, der kann dies hier tun:

https://kojipkgs.fedoraproject.org//packages/firefox/74.0.1/3.fc30/x86_64/firefox-74.0.1-3.fc30.x86_64.rpm

Die FC31/32/33 Version davon ist bereits im Stable gepusht worden, so daß Ihr diese bereits habt. Was da das Problem war, wurde leider nicht mitgeteilt.

Installiert bekommt man das Update so :

sudo dnf update ./firefox-74.0.1-3.fc30.x86_64.rpm

wenn Ihr im gleichen Verzeichnis wie Eure Downloaddatei seid 😉

Nvidia, Fedora, RPMFusion und der Bug, der nicht sein soll.

Diese Geschichte fängt an mit: „Es war einmal eine Grafikkarte“.

„Nvidia, Fedora, RPMFusion und der Bug, der nicht sein soll“

Wie Ihr wisst, gibt es von Nvidiatreibern verschiedene Versionsnummern, z.b. 340,390,440. 440 ist der aktuelle Treiber für GTX1050 Karten.

Jetzt wirft dieser Treiber beim Systemboot eine Fehlermeldung wie folgt:

[ 222.363327] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 222.363328] [drm] No driver support for vblank timestamp query.
[ 222.397236] [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:05:00.0 on minor 0
[ 222.406533] ————[ cut here ]————
[ 222.406534] refcount_t: underflow; use-after-free.
[ 222.406550] WARNING: CPU: 1 PID: 513 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0
[ 222.406551] Modules linked in: nvidia_drm(POE) nvidia_modeset(POE) nvidia_uvm(OE) snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel nvidia(POE) snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep joydev snd_seq snd_seq_device edac_mce_amd drm_kms_helper snd_pcm kvm_amd snd_timer drm snd kvm ipmi_devintf sp5100_tco irqbypass wmi_bmof ipmi_msghandler k10temp i2c_piix4 soundcore pcspkr gpio_amdpt gpio_generic acpi_cpufreq nfsd binfmt_misc auth_rpcgss nfs_acl lockd grace sunrpc ip_tables dm_crypt hid_logitech_hidpp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ccp r8169 aacraid hid_logitech_dj wmi pinctrl_amd fuse
[ 222.406576] CPU: 1 PID: 513 Comm: plymouthd Tainted: P OE 5.5.10-200.fc31.x86_64 #1
[ 222.406577] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450M Pro4, BIOS P3.90 12/09/2019
[ 222.406579] RIP: 0010:refcount_warn_saturate+0xa6/0xf0
[ 222.406581] Code: 05 2e 03 2e 01 01 e8 7b 8e bc ff 0f 0b c3 80 3d 1c 03 2e 01 00 75 95 48 c7 c7 18 99 3c 9d c6 05 0c 03 2e 01 01 e8 5c 8e bc ff <0f> 0b c3 80 3d fb 02 2e 01 00 0f 85 72 ff ff ff 48 c7 c7 70 99 3c
[ 222.406582] RSP: 0018:ffffb573c103fcb8 EFLAGS: 00010286
[ 222.406583] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000007
[ 222.406584] RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff9416ce859cc0
[ 222.406585] RBP: ffff9416bacbfce8 R08: 0000000000000413 R09: 0000000000000003
[ 222.406585] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9416c70502e8
[ 222.406586] R13: ffff9416c7050000 R14: 0000000000000008 R15: 0000000000000000
[ 222.406588] FS: 00007f07558f3f00(0000) GS:ffff9416ce840000(0000) knlGS:0000000000000000
[ 222.406588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 222.406589] CR2: 00007f0755072052 CR3: 00000004035c6000 CR4: 0000000000340ee0
[ 222.406590] Call Trace:
[ 222.406597] nv_drm_atomic_helper_disable_all+0xec/0x290 [nvidia_drm]
[ 222.406603] nv_drm_master_drop+0x22/0x60 [nvidia_drm]
[ 222.406616] drm_drop_master+0x1e/0x30 [drm]
[ 222.406628] drm_dropmaster_ioctl+0x4c/0x90 [drm]
[ 222.406639] ? drm_setmaster_ioctl+0xb0/0xb0 [drm]
[ 222.406651] drm_ioctl_kernel+0xaa/0xf0 [drm]
[ 222.406663] drm_ioctl+0x208/0x390 [drm]
[ 222.406675] ? drm_setmaster_ioctl+0xb0/0xb0 [drm]
[ 222.406678] ? do_filp_open+0xa5/0x100
[ 222.406681] ? selinux_file_ioctl+0x174/0x220
[ 222.406683] do_vfs_ioctl+0x461/0x6d0
[ 222.406685] ksys_ioctl+0x5e/0x90
[ 222.406686] __x64_sys_ioctl+0x16/0x20
[ 222.406690] do_syscall_64+0x5b/0x1c0
[ 222.406693] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 222.406695] RIP: 0033:0x7f0755bb138b
[ 222.406697] Code: 0f 1e fa 48 8b 05 fd 9a 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d cd 9a 0c 00 f7 d8 64 89 01 48
[ 222.406697] RSP: 002b:00007ffced5fe798 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 222.406699] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0755bb138b
[ 222.406699] RDX: 0000000000000000 RSI: 000000000000641f RDI: 0000000000000009
[ 222.406700] RBP: 000000000000641f R08: 000055b6a6ff1df0 R09: 000055b6a6fa5010
[ 222.406701] R10: 0000000000000000 R11: 0000000000000246 R12: 000055b6a6ff2970
[ 222.406701] R13: 0000000000000009 R14: 0000000000000000 R15: 0000000000000000
[ 222.406703] —[ end trace fa45bb73ed0780f4 ]—
[ 222.411358] kauditd_printk_skb: 45 callbacks suppressed

Von Euch sieht natürlich jeder sofort, daß hier NVIDIA und PLYMOUTH im Spiel sind und das der Nvidiatreiber einen Fehler bei der DRM Initialisierung verursacht. Der Server bootet danach weiter, also erstmal nicht so wichtig. Es folgen die üblichen Dinge: Bugreport bei Fedora ( wegen Plymouth ) und bei RPMFusion ( wegen Nvidia ) erstellen, und komplett entäuscht werden… !

„Da ist kein Bug, gehen Sie weiter!“

Nun kann Fedora da nicht viel machen, wenn der Nvidiatreiber da Mist baut, außer natürlich, es übergibt dem Treiber schon was falsches, da könnte der Treiber dann nicht mehr soviel für den Bug. Das werden wir aber nie erfahren, denn der Bug wurde sofort beerdigt. Nagut, wir haben ja noch den RPMFusionreport.

Sagte ich, wir haben noch einen anderen offenen Bugreport? So kann man sich irren: „Your Bugreport has been closed with „WONT FIX“.Und dann stehen wir mit einem Fehler da, von dem alle Parteien sagen „Nicht mein Problem“. Doch, Eurer Problem! Wessen denn sonst?

Der Bug wurde in der Devliste von Nvidia zwar besprochen, aber es gibt leider keinen finalen Fix dafür:

Devliste: https://forums.developer.nvidia.com/t/bug-nvidia-440-64-kernel-5-5-6-stable-boot-trace-was-nvidia-440-59-kernel-5-5-1-stable-boot-trace/111643

Der derzeitige Stand ist: Geht halt nicht; und DRM geht dann halt auch nicht. Wobei letzteres sollte man eh abschaffen, falls damit das DigitalRightsManagement gemeint ist.

Was mich aber am meisten stört: „ist nicht unser Problem“. Von RPMFusion hätte ich erwartet, daß das offen bleibt, bis das von den Nvidiadevs gefixt wurde, schon um das Problem zu tracken, aber von Scott kann man halt oft nichts anderes erwarten.

Neue Platte automatisch entschlüsseln lassen

Ich hab eine neue Platte im PC und die soll sich natürlich beim Hochfahren automatisch ins System integrieren, wenn ich das Passwort kenne. Leider klappt das mit den Automatiken nicht so ganz, daher müssen wir da kurz Hand anlegen.

Automatisch LUKS-Platten beim Boot einbinden

Zunächst brauchen wir mal eine mit LUKS verschlüsselte Platte. Um eine Platte mit LUKS zu verschlüsseln eignet sich das Laufwerketool. Die zu formatierende Partition auswählen und auf „Partition formatieren“ klicken:

man sieht die erste Formatierungsseite im LaufwerketoolIhr geht den neuen Namen für die Platte an, damit meldet die sich dann später im System, und wählt „Passwortgeschützter Datenträger (LUKS)“  aus. Ggf. habt Ihr die Wahl zwischen LUKS und LUKS2, aber F30 hat die noch nicht. Wenn ja, nehmt ruhig LUKS2.

Man sieht, wie das Passwort eingegeben wird.Ein ordentlich langes Passwort ist Pflicht. Danach dürft Ihr das noch einmal bestätigen und ein paar Sekunden später die Platte mit Hilfe des Lazy-Inits bereits bereit. „Lazy-Init“ meint, daß die Platte dort formatiert wird, wo Daten geschrieben werden sollen und nicht jetzt gleich die ganze Platte von Vorn bis Hinten formatiert wird. Das hätte nämlich bei 8TB 23 Stunden gedauert, da hatte ich wirklich keine Lust zu 😉

Die UUID ermitteln

Zwei Möglichkeiten eröffnen sich Euch: Ihr fragt das Laufwerkstool nach der UUID der neuen Platte ( Luks-Teil ) oder Ihr bemüht „blkid“ in der Konsole. Da wir diese eh gleich brauchen, bietet sich das an:

Erstmal ROOT werden:

$ su

dann suchen wir uns die UUID raus:

# blkid|grep sdd
/dev/sdd: UUID=“c16596bf-b40d-4c57-a46d-93b98d4bac47“ TYPE=“crypto_LUKS“

„sdd“ ist hier meine Platte. Eine UUID ist eine einmalige ID ( daher das zweite U ) die aufgrund eines einheitlichen Verfahrens ( das erste U ) erzeugt wird. Mehr müßt ihr darüber eigentlich nicht wissen.

Nun nehmen wir die UUID und tragen das passend in /etc/crypttab und /etc/fstab ein:

$ echo „/dev/mapper/luks-c16596bf-b40d-4c57-a46d-93b98d4bac47 /media/Huge ext4 defaults,x-systemd.device-timeout=0 1 2″ >>/etc/fstab

Da es sich um ein LUKS Laufwerk handelt und Devmapper das für uns managen wird, tragen wir den Devmapperpräfix und die UUID als Laufwerkspfad ein. „/media/Huge“ ist der Mountpoint, den Ihr bei Euch ggf. vorher noch anlegen müßt. Natürlich könnt Ihr auch einen anderen Pfad dafür nehmen, müßt Ihr wissen. Für alle Einsteiger: Der Mountpoint ist nichts weiter als ein leeres Verzeichnis. Das kann liegen wo Ihr wollt, aber /mnt/directory oder /media/directory  bieten sich an. Wichtig ist, daß da nichts anderes gemountet ist und der Pfad nicht in einem anderen Mountpoint ist.

Beispiel:

/media/Small
/media/Bigger
/media/Huge

ext4“ ist das Filesystem. Ihr werdet gemerkt haben, daß nach dem Formatieren der LUKS Partition ein weitere Partition unter der LUKS-Partition aufgetaucht ist. Da liegen Eure Daten dann wirklich drin. Das sieht so aus:

am sieht die Anzeige einer Luks-Partition gefolgt von der dadrin befindlichen normalen PartitionDiese Partition muß von Euch jetzt auch erst noch formatiert werden, dann natürlich passend zu dem Eintrag in der /etc/fstab, den wir gerade besprochen haben. Nehmt einfach Ext4, könnt Ihr praktisch nichts falsch machen. Wie Ihr sehen könnt, bekommt diese Partition eine eigene neue UUID. Aber das muß Euch jetzt nicht weiter belasten.

Damit die Platte jetzt auch beim Booten entschlüsselt wird und damit das Mounten/Einhängen des Laufwerks überhaupt erst möglich wird, tragt Ihr die UUID noch in die /etc/crypttab ein:

echo „luks-c16596bf-b40d-4c57-a46d-93b98d4bac47 UUID=c16596bf-b40d-4c57-a46d-93b98d4bac47 none“ >> /etc/crypttab

Das wars schon. Beim nächsten Booten ist die Platte dann sofort verfügbar.

„Keine Panik!“

Ok, eine freundliche Schriftart habe ich jetzt auf die Schnelle nicht zur Hand und großer geht es auch nicht, aber falls Ihr mal etwas vergessen oder Euch vertippt habt und Euer System nicht bootet.. KEINE PANIK!

Das löst sich ganz einfach:

1. den PC von einer USB-LIVE Disk booten.
2. Das Laufwerketool starten.
3. Eure Systempartition ggf. erst entschlüsseln und dann direkt im Tool mounten/einhängen.
4. TERMINAL öffnen
5. „su“ eingeben

6. „blkid“ eingeben
7. UUID in /etc/fstab und /etc/crypttab  vergleichen
8. Tippfehler beheben und Rechner neu booten.

99% aller Fehler in dem Bereich sind Vertipper oder man hat es schlicht und ergreifend nicht abgespeichert 🙂