How to decrypt LUKS-encrypted device on per user basis upon login?

Question

I've created the following luks@.service service for 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

The idea is to decrypt certain LUKS-encrypted xxx device as xxx.luks only for a given user, who enables the service with, for example:

systemctl --user enable luks@xxx

Unfortunately, even testing it with

systemctl --user start luks@xxx

fails as it always returns with exit code 1 without stating the actual reason. To me it was clear that the problem is likely in permissions. That is I know for sure that in order to manually trigger cryptsetup luksOpen ..., one has to elevate the shell, e.g. with sudo. Indeed, if I issue

sudo systemctl start luks@xxx

it works like a charm and similarly

sudo systemctl enable luks@xxx

would work for boot phase.

NOTE:
For such system-wide installation, it is of course needed to modify the service by replacing %h with the actual home directory of a giver user, which is ugly and does not serve the final purpose anyway.

Now, I'm aware of pam_mount which is capable of doing similar mounting (which I cannot use because it does not support detached LUKS headers and because it actually mounts devices, something what I don't want) on per user basis and, in fact, pam_systemd launches systemctl --user, so there definitely should be a way to obtain privileges during boot on per user basis to perform the device decryption.

By the way, failure symptoms of

systemctl --user enable luks@xxx

are even worse than those of testing it with

systemctl --user start luks@xxx

(which only returns exit code 1). That is I cannot even log in with the given user as it complains about

Failed to create bus connection: No such file or directory

because XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS are not set anymore, while they should have been by the systemd-logind.service service. Clearly, luks@xxx somehow breaks the whole initialization process but due to insufficient information in journal, I cannot identify exactly why. Thus, my current suspicion about lack of permissions still remains.

Looking forward to educated proposals. Thank you.

Answer 1

An alternative solution would be to edit the sudoers file to add permissions for the user in question to run /usr/lib/systemd/systemd-cryptsetup with root permissions with NOPASSWD option enabled.

You would then edit your (user-specific) service file above to read:

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'

I'm not sure whether you would also have to enable !requiretty for this to work

Update:

To increase security around this, especially for a multiple-user system, I'd highly recommend creating a couple of scripts to perform the 'attach' and 'detach' steps on behalf of the user rather than giving sudo access to /usr/lib/systemd/systemd-cryptsetup directly, as otherwise any user that is given access to run this command can potentially interfere with other encrypted volumes.

Answer 2

I would suggest creating and enabling a Type=oneshot RemainAfterExit=yes service for the user that creates a file with it's ExecStart directive, and removes it with it's ExecStop directive e.g.

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

You can then create and enable a luks@xxx.path unit file for the system user with an absolute path:

PathExists="/home/user/.decrypt"

This would check for the path created by the user service above, activating the luks@xxx.service unit when it is created, and deactivating it when it is removed, thus establishing an indirect dependency of the system service on the user service.

Note that for this to operate securely, the directory in which the file is created should be writable by the user only, of course.