Systemd user service does not work unmodified on Ubuntu 18.04 (5.3 kernel)

[mahiuchun]

Thanks for building this. With the systemd config as given I hit errors like the following

Jul 03 20:34:44 ubuntu systemd[30813]: yubikey-agent.service: Failed to set up user namespacing: Operation not permitted
Jul 03 20:34:44 ubuntu systemd[30813]: yubikey-agent.service: Failed at step USER spawning /usr/local/bin/yubikey-agent: Operation not permitted

and I ended up removing lots of flags in the service section:

[Service]
ExecStart=/usr/local/bin/yubikey-agent -l %t/yubikey-agent/yubikey-agent.sock
ExecReload=/bin/kill -HUP $MAINPID
RuntimeDirectory=yubikey-agent

I know it is a great idea to use as little privilege as possible. OTOH, since kernels shipped by Ubuntu might not work well with such settings yet, it would be nice if we could provide a little more information to the users.

Reference: https://unix.stackexchange.com/questions/303213/how-to-enable-user-namespaces-in-the-kernel-for-unprivileged-unshare

BTW, sysctl settings like

sudo sysctl -w kernel.unprivileged_userns_clone=1
sudo sysctl -w kernel.unprivileged_userns_apparmor_policy=1

does not make it work for me 😞

[LeSuisse]

Hi,

I will take a look. I will admit I only tested the unit on modern distributions 😞 .

BTW, sysctl settings like

sudo sysctl -w kernel.unprivileged_userns_clone=1
sudo sysctl -w kernel.unprivileged_userns_apparmor_policy=1

does not make it work for me 😞

Some systems also limits the maximum number of user namespaces (user.max_user_namespaces) which can also prevent user namespace to work. I know that some RHEL systems set this maximum number to 0.

[LeSuisse]

I did a few tests and there are also a some limitations around capabilities on Ubuntu 18.04.

Would you mind testing with the following unit?

[Unit]
Description=Seamless ssh-agent for YubiKeys
Documentation=https://filippo.io/yubikey-agent

[Service]
ExecStart=/usr/local/bin/yubikey-agent -l %t/yubikey-agent/yubikey-agent.sock
ExecReload=/bin/kill -HUP $MAINPID
ProtectSystem=strict
ProtectKernelLogs=yes
ProtectKernelTunables=yes
ProtectControlGroups=yes
ProtectClock=yes
ProtectHostname=yes
PrivateTmp=yes
PrivateUsers=yes
IPAddressDeny=any
RestrictAddressFamilies=AF_UNIX
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
NoNewPrivileges=yes
KeyringMode=private
SystemCallFilter=~@privileged @resources
SystemCallErrorNumber=EPERM
SystemCallArchitectures=native
UMask=0177
RuntimeDirectory=yubikey-agent

[Install]
WantedBy=default.target

[mahiuchun]

Works for me 😃

[FiloSottile]

Does the workaround drop important protections or should we just change the unit in systemd.md?

[mahiuchun]

Sorry for the confusion. Looks like the unit file LeSuisse gave stopped working for me after some reboots.

[flokli]

Some of the isolations in there require user namespaces. From https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Sandboxing:

Also note that some sandboxing functionality is generally not available in user services (i.e. services run by the per-user service manager). Specifically, the various settings requiring file system namespacing support (such as ProtectSystem=) are not available, as the underlying kernel functionality is only accessible to privileged processes. However, most namespacing settings, that will not work on their own in user services, will work when used in conjunction with PrivateUsers=true.

User namespaces seem to be disabled on most Debian and some Ubuntu systems. I consider these isolations useful enough to keep them enabled by default. According to https://superuser.com/a/1122977), it should be possible to enable user namespace support on these distros too.

It's probably sufficient to add a note to that into the manual installation section - I'd assume Debian & co. will provide their own, less-isolated systemd units in their packages sooner or later anyways.

[LeSuisse]

@mahiuchun Do you have more details? What was the output of systemctl status --user yubikey-agent?

Yep some of the sandboxing instructions are not available when running the service at the user level. I left the instructions anyway if someone wants to run the unit with the global service manager.

Ultimately this is only an issue until packages are published to hide this complexity. Maybe until then, adding a section in the manual with a more universal unit without any sandboxing for people running an Ubuntu 18.04 or older would be enough?

[FiloSottile]

There's now a note in the instructions 👍