☰

Wie entschlüsselt man ein LUKS-verschlüsseltes Gerät beim Anmelden für jeden Benutzer einzeln?

tag-icon • tag-icon systemd login luks d-bus cryptsetup
Wie entschlüsselt man ein LUKS-verschlüsseltes Gerät beim Anmelden für jeden Benutzer einzeln?

Ich habe den folgenden [email protected]Dienst für erstellt systemd:

[Unit]
Description=Cryptography Setup for '%I'
After=cryptsetup-pre.target
After=dev-mapper-%i.device
Before=cryptsetup.target
Before=umount.target
BindsTo=dev-mapper-%i.device
BindsTo=dev-mapper-%i.luks.device
Conflicts=umount.target
DefaultDependencies=no
IgnoreOnIsolate=true
RequiresMountsFor=/home

[Service]
ExecStart=/usr/lib/systemd/systemd-cryptsetup attach '%I.luks' '/dev/mapper/%I' '%h/%I/secret.key' 'luks,header=%h/%I/header'
ExecStop=/usr/lib/systemd/systemd-cryptsetup detach '%I.luks'
KillMode=none
RemainAfterExit=yes
TimeoutSec=0
Type=oneshot

[Install]
WantedBy=default.target

xxxDie Idee besteht darin, bestimmte LUKS-verschlüsselte Geräte nur für einen bestimmten Benutzer zu entschlüsseln xxx.luks, der den Dienst beispielsweise mit folgendem aktiviert:

systemctl --user enable luks@xxx

Leider sogar testen mit

systemctl --user start luks@xxx

schlägt fehl, da es immer mit einem Exit-Code zurückkehrt, 1ohne den eigentlichen Grund anzugeben. Für mich war klar, dass das Problem wahrscheinlich bei den Berechtigungen liegt. Das heißt, ich weiß mit Sicherheit, dass man, um manuell auszulösen cryptsetup luksOpen ..., die Shell erhöhen muss, z. B. mit sudo. Wenn ich tatsächlich ausführe,

sudo systemctl start luks@xxx

es funktioniert wie ein Zauber und ebenso

sudo systemctl enable luks@xxx

würde für die Bootphase funktionieren.

NOTIZ:
Für eine solche systemweite Installation ist es natürlich erforderlich, den Dienst zu ändern und ihn durch %hdas tatsächliche Home-Verzeichnis des Geberbenutzers zu ersetzen. Das ist unschön und erfüllt ohnehin nicht den eigentlichen Zweck.

Jetzt ist mir bekannt, dass pam_mountes in der Lage ist, ähnliche Einbindungen (die ich nicht verwenden kann, weil es keine getrennten LUKS-Header unterstützt und weil es tatsächlich Geräte einbindet, was ich nicht will) auf Benutzerbasis durchzuführen und tatsächlich pam_systemdzu starten systemctl --user, also sollte es definitiv eine Möglichkeit geben, während des Bootens auf Benutzerbasis Berechtigungen zu erhalten, um die Geräteentschlüsselung durchzuführen.

Übrigens, Ausfallsymptome von

systemctl --user enable luks@xxx

sind noch schlimmer als die Ergebnisse eines Tests mit

systemctl --user start luks@xxx

(das nur den Exitcode zurückgibt 1). Das heißt, ich kann mich nicht einmal mit dem angegebenen Benutzer anmelden, da es sich beschwert über

Failed to create bus connection: No such file or directory

weil XDG_RUNTIME_DIRund DBUS_SESSION_BUS_ADDRESSnicht mehr festgelegt sind, obwohl sie vom systemd-logind.serviceDienst festgelegt sein sollten. Offensichtlich luks@xxxunterbricht dies irgendwie den gesamten Initialisierungsprozess, aber aufgrund unzureichender Informationen im Journal kann ich nicht genau feststellen, warum. Daher bleibt mein aktueller Verdacht bezüglich fehlender Berechtigungen bestehen.

Ich freue mich auf fundierte Vorschläge. Vielen Dank.

Antwort1

Eine alternative Lösung besteht darin, die sudoersDatei zu bearbeiten und dem betreffenden Benutzer die Berechtigung zu erteilen, /usr/lib/systemd/systemd-cryptsetupmit Root-Berechtigungen und aktivierter Option NOPASSWD zu arbeiten.

Anschließend bearbeiten Sie Ihre (benutzerspezifische) Servicedatei oben wie folgt:

ExecStart=/usr/bin/sudo /usr/lib/systemd/systemd-cryptsetup attach '%I.luks' '/dev/mapper/%I' '%h/%I/secret.key' 'luks,header=%h/%I/header'
ExecStop=/usr/bin/sudo /usr/lib/systemd/systemd-cryptsetup detach '%I.luks'

Ich bin nicht sicher, ob Sie auch aktivieren müssten!Anforderungdamit das funktioniert

Aktualisieren:

Um die Sicherheit in diesem Zusammenhang zu erhöhen, insbesondere bei einem Mehrbenutzersystem, empfehle ich dringend, einige Skripte zu erstellen, um die Schritte „Anhängen“ und „Trennen“ im Namen des Benutzers auszuführen, anstatt /usr/lib/systemd/systemd-cryptsetupdirekt Sudo-Zugriff zu erteilen, da sonst jeder Benutzer, dem die Berechtigung zum Ausführen dieses Befehls erteilt wird, möglicherweise andere verschlüsselte Volumes stören kann.

Antwort2

Ich würde vorschlagen, einen Type=oneshot RemainAfterExit=yesDienst für den Benutzer zu erstellen und zu aktivieren, der eine Datei mit seiner ExecStartDirektive erstellt und sie mit seiner ExecStopDirektive entfernt, z. B.

ExecStart="/usr/bin/touch %h/.decrypt"
ExecStop="/usr/bin/rm %h/.decrypt"

[email protected]Anschließend können Sie eine Unit-Datei mit absolutem Pfad für den Systembenutzer erstellen und aktivieren :

PathExists="/home/user/.decrypt"

Dadurch wird der vom obigen Benutzerdienst erstellte Pfad überprüft, die [email protected]Einheit wird beim Erstellen aktiviert und beim Entfernen deaktiviert, wodurch eine indirekte Abhängigkeit des Systemdienstes vom Benutzerdienst hergestellt wird.

Beachten Sie, dass für einen sicheren Betrieb das Verzeichnis, in dem die Datei erstellt wird, natürlich nur vom Benutzer beschreibbar sein darf.

verwandte Informationen