Lokale Shell-Befehle einbinden

„ls -la“ kennt Ihr vermutlich aus jedem Konsolen-Tutorial für Linux. Aber habt Ihr auch schon mal einen lokalen Befehl nur für Euch gebaut ?

Globale oder Lokale Befehle ?

Globale Befehle kennt vermutlich jeder Linuxuser, denn alles was in /bin/ als Programm abgelegt und für alle Benutzer ausführbar ist, kann aufgerufen werden. Meistens laufen diese Programme im Context des aufrufenden Benutzers. Ausnahmen gibt es nur, wenn das SETUID-Flag gesetzt ist, dann darf jemand einen Befehl als ein bestimmter User ausführen. Üblicherweise ist das Root, aber andere user sind auch denkbar. „ls“, „find“, „uname“ usw. sind solche Befehle. So weit, so normal.

Wer den Videobeitrag Wie starten sich eigentlich Programme? gesehen hat, der ist da jetzt schon weiter, denn dort wird das genau erklärt. Kann ich Euch nur empfehlen, weil damit ist das hier möglich :

[marius@eve ~]$ firefox
Ich bin aber nicht der FireFox!
insgesamt 20
drwxrwxr-x. 2 marius marius 4096 14. Jul 09:45 .
drwxr-xr-x. 5 marius marius 4096 5. Jul 23:48 ..
-rwx——. 1 marius marius 100 14. Jul 09:45 firefox
-rwx——. 1 marius marius 112 5. Jul 23:48 fixrom
#!/bin/bash

echo „Ich bin aber nicht der FireFox!“

ls -la ~/.local/bin/
cat ~/.local/bin/firefox

[marius@eve ~]$

„Nicht die Mama“

Ok, Firefox ist jetzt nicht mehr Firefox .. super.. Browser kaputt gemacht 🙁  Was wäre, wenn im System ein Firefox Quantum installiert ist, der User aber Quantum ******** findet und lieber noch FF 52 ESR nutzen will? Egal welches Programm Firefox für seine Webseitendarstellung aufruft, es wird immer der systemweit installierte Firefox genommen. Der kleine Trick hier könnte das auf dem Firefox ESR umleiten. Das wäre nur lokal für diesen Benutzer der Fall.

Wesentlich praktischer ist das andere kleine Programm in den .local/bin Verzeichnis: fixrom . Wer den Beitrag über das fehlerhafte Fehlerfenster bei Runes of Magic gelesen hat, der weiß was es tut: Es verschiebt ein Fenster, daß nutzlos im Weg ist und dazu noch so defekt, daß man das nicht per Maus machen kann.

Da ich das kleine Script in das Lokale Bin-Verzeichnis verschoben habe, kann ich es von überall aus aufrufenund muß nicht mal den Pfad kennen, wo es wirklich liegt. ALT+F2 und die Eingabe von „fixrom“ startet es genauso, also wenn es in der Konsole eingebe. Ich kann es auch pauschal in die Desktopicons einbauen:

[marius@eve ~]$ cat Schreibtisch/Runes\ of\ Magic.desktop | grep Exec
Exec=env WINEPREFIX=“/home/marius/.wine“ wine C:\\\\windows\\\\command\\\\start.exe /Unix „/home/marius/Programme/GameforgeLive/Games/DEU_deu/Runes Of Magic/Runes of Magic.exe“

Dann würde es direkt nach dem Start von Runes of Magic gestartet werden und mit das Fenster sofort vom Hals halten. Aber, dann würde es auch bei jedem Start laufen und es muß nur eine Instanz davon aktiv sein, daher starte ich das von Hand.Gut, ich könnte das Script auch mit einem PID File versehen und prüfen ob es schon läuft und dann den Start umgehen, zeige ich vielleicht sogar mal 🙂

A Truth about Red Hat

Der vollständigkeithalber muß ich erwähnen, daß das mit dem Firefoxersatz unter Fedora nur klappt, wenn man seinen Pfad korrigiert. Wer nicht weiß was ein Pfad ist, schaut sich bitte das Video an. So sieht der Pfad unter Fedora aus:

$ echo $PATH
/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/usr/sbin:/usr/sbin:/home/marius/.local/bin:/home/marius/bin:/usr/sbin/:/usr/sbin

So müßte er aussehen:

[marius@eve ~]$ echo $PATH
/home/marius/.local/bin:/home/marius/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/usr/sbin:/usr/sbin:/usr/sbin/:/usr/sbin

macht man übrigens so :

[marius@eve ~]$ export PATH=/home/marius/.local/bin:/home/marius/bin:$PATH

Natürlich müßt Ihr meinen Usernamen in Euren Änderungen durch Euren Namen ersetzen 😉

Wieso Fedora/Red Hat den Pfad so unbrauchbar gemacht haben, ist mir ein Rätsel, denn genau für solche Spielereien sind die lokalen Bin-Verzeichnisse da. Jetzt könnte man argumentieren, daß ein Angreifer damit den (im Beispiel) Firefox lokal ersetzen könnte und so ggf. noch mehr Schaden beim User durch Spionage anrichten kann. Das wäre zwar richtig, aber jeder, der von Remote da was hinlegen kann, kann noch ganz andere Dinge und hätte das Angriffsszenario nicht nötig 😉

Solange man aber nicht vorhat ein Systemprogramm zu ersetzen, ist der Pfad eigentlich egal, nur .local/bin/ müßte halt drin vorkommen.

selinux-policies auf den letzten funktionierenden Stand bringen

Wie Ihr ( und .tux. )  im letzten Bericht zu selinux-policy lesen konntet, wurde das SEL Problem mit einem generellen Downgrade erstmal behoben. Heute schauen wir uns an, wie man das trotz aller Gegenwehr von Red Hat wieder auf den letzten aktuellen Stand geupdated bekommt 😉

Fedora und die Repostrukturen

Wenn man dnf downgrade benutzt, bekommt man nicht automatisch die letzte Version von einem Paket installiert, sondern nur die nächst kleinste im Repository (Repo) und genau da happerts meiner Meinung nach bei Fedora und Red Hat. Man sollte ja annehmen, daß die aktuelle Version und die vorherige Version eines Paketes zur Verfügung stehen, tun Sie aber nicht. Fedora betreibt ein Basis Repo und ein Updates Repo. Eine funktionierende alte Fassung liegt im Basis Repo, die aktuellste im Updates Repo. Zwischenversionen gibt es leider keine und das ist, denke ich, ein Fehler von Seiten der Distribution.

Immer wieder Koji

Und wieder ist es Koji, die Buildverwaltung für Fedora, die uns bei der Sache als nützliche Datenquelle dient:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1076199

Dort holen wir uns die nötigen RPMs für die lokale Installation:

https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-targeted-3.13.1-283.34.fc27.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-devel-3.13.1-283.34.fc27.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-doc-3.13.1-283.34.fc27.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-3.13.1-283.34.fc27.noarch.rpm

Wer meiner Anweisung gefolgt ist, und in die dnf.conf eine Sperre für das Paket eingetragen hat, muß diese Sperre jetzt natürlich wieder entfernen, bevor er das Update durchführen kann.

Manuelles DNF Update

Der Befehl „dnf update ./selinux-policy-*“ ist unser Freund:

[root]# dnf update ./selinux-policy-*
Letzte Prüfung auf abgelaufene Metadaten: vor 0:24:25 am Di 10 Jul 2018 09:59:33 CEST.
Abhängigkeiten sind aufgelöst.
================================================================================================================================================================================================================================================================================
Paket Arch Version Paketquelle Größe
================================================================================================================================================================================================================================================================================
Aktualisieren:
selinux-policy noarch 3.13.1-283.34.fc27 @commandline 541 k
selinux-policy-devel noarch 3.13.1-283.34.fc27 @commandline 1.4 M
selinux-policy-doc noarch 3.13.1-283.34.fc27 @commandline 2.7 M
selinux-policy-targeted noarch 3.13.1-283.34.fc27 @commandline 10 M

Transaktionsübersicht
================================================================================================================================================================================================================================================================================
Aktualisieren 4 Pakete

Gesamtgröße: 15 M
Ist dies in Ordnung? [j/N]:j
Pakete werden heruntergeladen:
Transaktionsüberprüfung wird ausgeführt
Transaktionsprüfung war erfolgreich.
Transaktion wird getestet
Transaktionstest war erfolgreich.
Transaktion wird ausgeführt
Vorbereitung läuft : 1/1 
Aktualisieren : selinux-policy-3.13.1-283.34.fc27.noarch 1/8 
Ausgeführtes Scriptlet: selinux-policy-3.13.1-283.34.fc27.noarch 1/8 
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Aktualisieren : selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Aktualisieren : selinux-policy-doc-3.13.1-283.34.fc27.noarch 3/8 
Aktualisieren : selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8 
Ausgeführtes Scriptlet: selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8 
Aufräumen : selinux-policy-devel-3.13.1-283.14.fc27.noarch 5/8 
Aufräumen : selinux-policy-doc-3.13.1-283.14.fc27.noarch 6/8 
Aufräumen : selinux-policy-targeted-3.13.1-283.14.fc27.noarch 7/8 
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.14.fc27.noarch 7/8 
Aufräumen : selinux-policy-3.13.1-283.14.fc27.noarch 8/8 
Ausgeführtes Scriptlet: selinux-policy-3.13.1-283.14.fc27.noarch 8/8 
Running as unit: run-ra699effd01cd4ceba2ad927e7889ce3b.service
Running as unit: run-r27b6453c4a5e4d2ab971a1766a434a30.service
Überprüfung läuft : selinux-policy-3.13.1-283.34.fc27.noarch 1/8 
Überprüfung läuft : selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Überprüfung läuft : selinux-policy-doc-3.13.1-283.34.fc27.noarch 3/8 
Überprüfung läuft : selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8 
Überprüfung läuft : selinux-policy-targeted-3.13.1-283.14.fc27.noarch 5/8 
Überprüfung läuft : selinux-policy-3.13.1-283.14.fc27.noarch 6/8 
Überprüfung läuft : selinux-policy-devel-3.13.1-283.14.fc27.noarch 7/8 
Überprüfung läuft : selinux-policy-doc-3.13.1-283.14.fc27.noarch 8/8

Aktualisiert:
selinux-policy.noarch 3.13.1-283.34.fc27 selinux-policy-devel.noarch 3.13.1-283.34.fc27 selinux-policy-doc.noarch 3.13.1-283.34.fc27 selinux-policy-targeted.noarch 3.13.1-283.34.fc27

Fertig.

Nicht vergessen die dnf.conf wieder mit einer Sperre zu versehen :

# cat /etc/dnf/dnf.conf
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
exclude=selinux-pol*

Damit wären wir jetzt auf dem Stand, vor dem defekten Paket und bekommen erstmal keine Updates mehr für die selinux-policies.

Ob das so clever war, die automatischen Tests zu umgehen?

Wenn ich der Darstellung im Buildsystem glauben darf, dann wurde für den Push Tests umgangen. Da es nachweislich in die Hose gegangen ist, ist das wohl keine gute Idee.

Wissen eigentlich alle was diese Policies so machen ?

mit dem Befehl „rpm -qi selinux-policy“ bekommen wir eine Beschreibung des Pakets. Leider ist die in diesem Fall äußerst schmal geraten:

„SELinux Base package for SELinux Reference Policy – modular.
Based off of reference policy: Checked out revision 2.20091117“

Daher schauen wir doch mal in ein solches Paket rein. Jetzt ist selinux-policy kein sehr nützliches Beispiel, es setzt nämlich lediglich die System-Konfiguration und andere Metainfos. Viel spannender ist das selinux-policy-targeted Paket, daß die eigentlichen Regeln enthält. U.a. finden wir dies File darin:

/usr/share/selinux/targeted/default/active/modules/100/gnome/cil

Wenn man sich das jetzt mit less ansieht, sieht man nichts, da es bzip2 komprimiert ist. Daher brauchen wir jetzt das hier:

bzless /usr/share/selinux/targeted/default/active/modules/100/gnome/cil

u.A. findet man dann dort die Beschreibungen welche Dateien welche SEL-Contexte haben sollen:

(Die Liste ist nicht vollständig und nur für die eine Gnome Klasse)

(filecon „/var/run/user/[^/]*/\.orc(/.*)?“ any (system_u object_r gstreamer_home_t ((s0) (s0))))
(filecon „/var/run/user/[^/]*/dconf(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/var/run/user/[^/]*/keyring.*“ any (system_u object_r gkeyringd_tmp_t ((s0) (s0))))
(filecon „/root/\.cache(/.*)?“ any (system_u object_r cache_home_t ((s0) (s0))))
(filecon „/root/\.color/icc(/.*)?“ any (system_u object_r icc_data_home_t ((s0) (s0))))
(filecon „/root/\.config(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/root/\.kde(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/root/\.gconf(d)?(/.*)?“ any (system_u object_r gconf_home_t ((s0) (s0))))
(filecon „/root/\.dbus(/.*)?“ any (system_u object_r dbus_home_t ((s0) (s0))))
(filecon „/root/\.gnome2(/.*)?“ any (system_u object_r gnome_home_t ((s0) (s0))))
(filecon „/root/\.gnome2/keyrings(/.*)?“ any (system_u object_r gkeyringd_gnome_home_t ((s0) (s0))))
(filecon „/root/\.gstreamer-.*“ any (system_u object_r gstreamer_home_t ((s0) (s0))))
(filecon „/root/\.cache/gstreamer-.*“ any (system_u object_r gstreamer_home_t ((s0) (s0))))
(filecon „/root/\.local.*“ any (system_u object_r gconf_home_t ((s0) (s0))))
(filecon „/root/\.local/share(/.*)?“ any (system_u object_r data_home_t ((s0) (s0))))
(filecon „/root/\.local/share/icc(/.*)?“ any (system_u object_r icc_data_home_t ((s0) (s0))))
(filecon „/root/\.Xdefaults“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/root/\.xine(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/etc/gconf(/.*)?“ any (system_u object_r gconf_etc_t ((s0) (s0))))
(filecon „/tmp/gconfd-USER/.*“ file (system_u object_r gconf_tmp_t ((s0) (s0))))
(filecon „/usr/share/config(/.*)?“ any (system_u object_r config_usr_t ((s0) (s0))))
(filecon „/usr/bin/gnome-keyring-daemon“ file (system_u object_r gkeyringd_exec_t ((s0) (s0))))
(filecon „/usr/bin/mate-keyring-daemon“ file (system_u object_r gkeyringd_exec_t ((s0) (s0))))
(filecon „/usr/libexec/gconf-defaults-mechanism“ file (system_u object_r gconfdefaultsm_exec_t ((s0) (s0))))
(filecon „/usr/libexec/gnome-system-monitor-mechanism“ file (system_u object_r gnomesystemmm_exec_t ((s0) (s0))))
(filecon „/usr/libexec/kde(3|4)/ksysguardprocesslist_helper“ file (system_u object_r gnomesystemmm_exec_t ((s0) (s0))))

und in der findet sich dann kein Hinweis auf den gdm-greeter oder die gnome-session .. Womit es undefiniert ist.

Ich hab versucht da  durchzusteigen, aber das ist echt komplex das Zeugs 😉 Vielleicht will ja mal einer ein Diagnosetool dafür bauen, da berichte ich dann gerne drüber.

Fedora – GDM stürzt wegen SELinux ab

Ein schlecht ausgerolltes Update der SELinux Policies unter Fedora 27 führt dazu, daß der Loginbildschirm, im Fachjargon „Greeter“ genannt, mit einer unschönen Meldung absemmelt.

Fehleranalyse

Betroffene Version:  sellinux-policy 3.13.1-283.35

Wenn Eurer GDM Greeter also mit dem „blah blah ‚Benutzer abmelden'“ Fehler stehen bleibt, dann prüft folgendes:

1. „STRG+F2“ damit Ihr eine Root Konsole bekommt

2. „grep gdm /var/log/messages oderjournalctl -xe | grep gdm

kommt dabei das hier raus:

Jul 8 01:40:51 eve systemd[1627]: selinux: avc: denied { status } for auid=n/a uid=42 gid=42 cmdline=“/usr/libexec/gdm-x-session gnome-session –autostart /usr/share/gdm/greeter/autostart“ scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=system permissive=0

dann hilft Euch das hier weiter, falls keine neuere Version im Repository verfügbar ist (also vorher mit dnf -y update checken) :

dnf -y downgrade selinux-policy*
systemctl restart gdm

und anschließend das erneute Update mit dem Eintrag „exclude=selinux-p*“ in die /etc/dnf/dnf.conf verhindern.

Fazit

So eine Scheiße will einem um 1.10 Uhr nachts wirklich nicht passieren!

Runes of Magic – Der schwarze Fix

So ein diabolisches Programm wie Runes of Magic hat man selten. Da möchte ich Euch einen Bug zeigen, für den ich endlich einen Fix gefunden habe, da zeigt sich der Bug nicht mehr 😀

Der Bug

Zum Glück braucht man es nur ein paar mal starten und der Bug manifestiert sich, als ob er Uhrzeitabhängig wäre 😀 Wem das hier bekannt vorkommt:

Dem kann ich jetzt helfen 🙂 Ein Fenster mit Fehlermeldungen, die nicht angezeigt werden, weil das Fehlerfenster einen Programmierfehler hat :D, ist vor dem Spielfenster zu sehen. Es läßt sich nicht wegbewegen und ist auch ansonsten einfach defekt.

Natürlich gibt es dazu dutzende Bugreports an Wine und Runes of Magic, aber die schieben sich gegenseitig den Fehlerteufel zu und machen nix.

Um das zu lösen, braucht Ihr wmctrl,  das Window-Manager-ControlProgramm, also quasi WMCP 😉 Der Befehl:

wmctrl -l

listet alle offenen Fenster Eures Desktops auf, was so aussehen könnte:

0x03800003 -1 MeinRechner Schreibtisch
0x0380000b -1 MeinRechner nemo-desktop
0x08400006 0 MeinRechner marius@MeinRechner:~
0x09800001 0 MeinRechner Runes of Magic
0x09800003 0 MeinRechner Error List
0x0a400019 0 N/A ROM-Fix1.png (2.6M) — Krita

Ihr seht den Titel des Fensters und die WindowID. Spontan wollte ich mit der WindowID und der -c Option von wmctrl das Fenster einfach schliessen, aber da spielt Runes of Magic nicht mit aka. das ignoriert das kaputte Windowsfenster einfach. Es müssen andere Mittel her 😀

Die Lösung

Die Lösung sieht dann so aus:

wmctrl -r „Error List“ -e 0,0,0,1,1

Damit wird das Fenster mit dem Titel „Error List“ auf dem derzeitigen Desktop, Links oben auf die Koordinate 0/0 geschoben ( da wars vorher schon ) und dann auf 1×1 Pixel reduziert. Es ist jetzt also nur noch genau ein Pixel links oben in der Ecke, wo man sowieso den Fensterrahmen hat. Damit ist es aus der Störgleichung entfernt und das Spiel kann losgehen.

Wer früher mühselig zig Restarts von Rom hingelegt hatte, bis das Fenster mal nicht zu sehen war, der kann jetzt aufatmen … endlich weg 😀

Ein kleines Manko gibts dann doch, wenn man die Arbeitsfläche wechselt, ist der Bug wieder da.

Also Terminal aufmachen  und eingeben : watch -n 5 „wmctrl -r \“Error List\“ -e 0,0,0,1,1″

Alle 5 Sekunden wird es damit automatisch wieder verkleinert.

Wie man besser USB Sticks verschlüsselt mit Linux

Im c’t Uplink vom 22.9 vom 30.6.2018 diskutieren die Heise Redakteure das Thema „USB Sticks praktikabel verschlüsseln“ und kommen dabei zu völlig falschen Einschätzungen 🙂

Bevor Ihr weiter lest, schau Euch bitte die ersten 13 Minuten von dem c’t Uplink an. Ansonsten sieht das hier gleich nach Heise-Bashing aus, was es auf keinen Fall ist.

Die „Windows kanns besser“ These

Vorgestellt werden Bitlocker von Microsoft und VeraCrypt. Veracrypt wird dabei gleich als zu kompliziert aus dem Rennen ausgeschieden, was den Teilnehmern die ernsthaft gemeinte These „Bitlocker von Microsoft wäre die bessere Wahl weil… praktikabel“ entlockt:

– „Du steckst den Stick rein, und die Passwortabfrage kommt.“
– „Das geht mit jedem Windows ab Version 7“

Nur um kurze Zeit später sich selbst widersprechend grade die Bitlocker-Lösung als „properitär“ einzustufen (Stimmt) und mit (sinngemäß)  „Um Festplatteverschlüsselung zu machen, brauchst Du eh die PRO Version, die Home kann das nicht“ gleich wieder aus dem Verkehr zu ziehen. So ganz auf einer Linie ist die Argumentation in sich nicht 🙂

Zusammenfassung

Sie disqualifizieren VeraCrypt mit, daß es zu unpraktisch für den täglichen Einsatz ist.
Sie loben VeraCrypt (indirekt), weil es OpenSource ist und genau das wolle man ja für seine Krypto.
Sie disqualifizieren Bitlocker damit, daß es das sowieso nur in der Pro kann und auch nur für Windows geht und ClosedSource ist.
Sie lassen außen vor, daß es LUKS gibt und wie das mit Linux läuft.

Das lassen wir mal so im Raum stehen ohne es zu bewerten und nehmen wir es einfach mal als Anlass, uns die Sache mit Linux anzusehen und die gleichen Kriterien anzulegen.

Meine „Linux kanns besser“ These

Was haben wir unter Linux für sowas: LUKS.

Es ist Open-Source und auf jeder Major Distribution enthalten, aber es ist  Linux Only … ODER ?? Nein, geht auch mit Windows 😀 Bei Sourceforge.net gab/gibt es ein Projekt, daß Luks Medien unter Windows mountet. Das es vermutlich ähnlich gefährlich ist, wie der Einsatz des Bitlockerhacks unter Linux, ist anzunehmen 🙂

Kriterium „Open-Source“ erfüllt 🙂

Kriterium „Nicht properitär“ … ääähhhm… fairerweise… nicht erfüllt, aber da Open-Source erfüllbar 🙂

Wenn wir einen USB Stick mit Luks einrichten, können wir den einstecken, es kommt eine Passworteingabe und das Laufwerk wird gemountet:

Ich habe mal wieder eine 4. Partition auf meinen aktuellen Livestick gepackt, weswegen das Icon der Fedora-Live-Disk vom USB Stick zusehen ist, denn die Partition war natürlich unverschlüsselt 😉

Kriterium „Praktikabel“ erfüllt 🙂

LUKS ist schon einige Zeit auf dem Markt und daher in allen gängigen Distros auch enthalten. Einschränkungen wie „PRO“ gibt es natürlich nicht.

Kriterium „Geht auf jeder Edition aka allen Linuxen“ erfüllt 🙂

Damit sind wir ein Kriterium besser als Bitlocker und weil M$ den Bitlocker Key erstmal in die eigene Cloud kopiert, damit man „dem Kunden bei Verlust ein Recovery möglich machen kann“ ( wers glaubt ), ist Bitlocker ein NOGO das man nicht ernsthaft in Betracht ziehen kann.

Fazit: Wechselt endlich auf Linux, da geht der Kram einfach 😀

Wie man das einrichtet, gibt es in einem anderen Blog Beitrag.

P.S.: Was die Heise Redakteure nicht wußten war, daß man mit LUKS TrueCryptContainer mounten kann, was bedeutet: „Reinstecken und Passwortabfrage kommt“ geht auch für TrueCrypt/VerCrypt Medien, wenn man das will 😀