[Bug 1950787] Re: systemd-sysusers cannot mount /dev in privileged containers (to pass credentials)
Stéphane Graber
1950787 at bugs.launchpad.net
Fri Nov 12 14:33:06 UTC 2021
If this only fails in privileged containers, then I probably wouldn't
worry about it too much, those aren't the default and a LOT of things
break in privileged containers, so I don't think it's worth doing distro
changes to accommodate this, assuming the container otherwise still
boots.
For cases like this one, it's usually been hard to make a solid case for
a change of behavior in upstream systemd. There are a few places like
the devices cgroup where permission errors are considered non-fatal
which then accommodates containers quite well, but the same isn't true
with the isolation security features which this one ties into.
In an ideal world, AppArmor would allow us to craft a policy which:
- Allows for mount namespaces
- Allows for bind-mounts of restricted paths
- Applies the parent's policy onto the bind-mount target
- Properly support mount propagation flags in a way that can't be abuse to allow all mounts
But as it stands, AppArmor is entirely path based, so a policy that
applies to /proc will not apply to /proc bind-mount to /blah/proc (which
is effectively what systemd does) and so causes all confinement to be
bypassable. Additionally, there are (or were in some versions at least)
issues with processing those mount propagation flags you see in your log
(shared/slave/...) and allowing a bind-mount to be marked using one of
those flags would incorrectly cause the parser or the kernel (not quite
sure which) to allow ALL mounts...
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1950787
Title:
systemd-sysusers cannot mount /dev in privileged containers (to pass
credentials)
Status in lxd package in Ubuntu:
Invalid
Status in systemd package in Ubuntu:
New
Bug description:
systemd-sysusers.service/systemd.exec fails to start in privileged containers, due to being unable to properly mount /dev for passing credentials, caused by the following config in the .service unit:
```
# Optionally, pick up a root password and shell for the root user from a
# credential passed to the service manager. This is useful for importing this
# data from nspawn's --set-credential= switch.
LoadCredential=passwd.hashed-password.root
LoadCredential=passwd.plaintext-password.root
LoadCredential=passwd.shell.root
```
Reproducer:
$ lxc profile set default security.privileged "true"
$ lxc launch ubuntu-daily:jammy test
$ lxc exec test bash
# add-apt-repository ppa:ci-train-ppa-service/4704
# apt install systemd # install systemd 249.5-2ubuntu1
# systemctl restart systemd-sysusers
# systemctl status systemd-sysusers
# system --status=failed
$ lxc profile set default security.privileged "false"
A workaround is to disable it via:
$ cat /etc/systemd/system/systemd-sysusers.service.d/override.conf:
[Service]
LoadCredential=
Interesting logs:
Nov 12 12:09:44 test systemd[1]: systemd-journald.service: Added fd 42 (n/a) to fd store.
Nov 12 12:09:44 test systemd[431]: Mounting /dev (MS_REC|MS_SLAVE "")...
Nov 12 12:09:44 test systemd[431]: Failed to mount n/a (type n/a) on /dev (MS_REC|MS_SLAVE ""): Permission denied
Nov 12 12:09:44 test systemd[430]: (sd-mkdcreds) failed with exit status 1.
Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed to set up credentials: Protocol error
Nov 12 12:09:44 test systemd[430]: systemd-sysusers.service: Failed at step CREDENTIALS spawning
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950787/+subscriptions
More information about the foundations-bugs
mailing list