systemd user service with NoNewPrivileges=true fails without an existing user namespace

[eriksjolund]

I made an experiment on a Fedora 36 system

1. Create the file /root/prepare.sh with this file contents

podman pull -q docker.io/library/alpine
podman run -q --rm --name test docker.io/library/alpine /bin/sleep inf &
sleep 2
mkdir -p ~/.config/systemd/user
podman generate systemd --new --name test > ~/.config/systemd/user/test.service
sed -i '/\[Service\]/a NoNewPrivileges=true' ~/.config/systemd/user/test.service
systemctl --user daemon-reload
pkill -9 -u $USER

2. Run commands in the terminal

[root@asus ~]# useradd testuser
[root@asus ~]# cat prepare.sh | systemd-run --machine=testuser@ --quiet --user --collect --pipe --wait bash -
e66264b98777e12192600bf9b4d663655c98a090072e1bab49e233d7531d1294
[root@asus ~]# pgrep -u testuser
[root@asus ~]# machinectl shell testuser@
Connected to the local host. Press ^] three times within 1s to exit session.
[testuser@asus ~]$ systemctl --user start test.service
Job for test.service failed because the control process exited with error code.
See "systemctl --user status test.service" and "journalctl --user -xeu test.service" for details.
[test@asus ~]$ journalctl --user --no-pager -xeu test.service | grep -A1 "newuidmap: write to uid_map failed" | tail -2
May 28 09:17:22 asus podman[9562]: time="2022-05-28T09:17:22+02:00" level=error msg="running `/usr/bin/newuidmap 9583 0 1056 1 1 3593760 65536`: newuidmap: write to uid_map failed: Operation not permitted\n"
May 28 09:17:22 asus podman[9562]: time="2022-05-28T09:17:22+02:00" level=error msg="invalid internal status, try resetting the pause process with \"/usr/bin/podman system migrate\": cannot setup namespace using \"/usr/bin/newuidmap\": exit status 1"
[testuser@asus ~]$ podman unshare /bin/true
[testuser@asus ~]$ systemctl --user start test.service
[testuser@asus ~]$ systemctl --user is-active test.service
active
[testuser@asus ~]$

newuidmap is run without its extra capabilities due to NoNewPrivileges=true and thus fails.

test.service first failed to start, but after running podman unshare /bin/true, starting test.service succeeded.

Conclusion: When the systemd directive

NoNewPrivileges=true

is used in a systemd user service, the podman pause process (catatonit) must already be running because newuidmap and newgidmap can't be used.

It seems test.service should be modified to depend on another systemd service that runs the pause process.

What do you think?

[eriksjolund]

The restricted service test.service (with NoNewPrivileges=true) worked when I added a dependency on
on a new service podman-usernamespace.service (with Type=oneshot and ExecStart=/usr/bin/podman unshare /bin/true)

1. Create the file /root/prepare.sh with this file contents:

podman pull -q docker.io/library/alpine
podman create  -q --rm --name test docker.io/library/alpine /bin/sleep inf
mkdir -p ~/.config/systemd/user
podman generate systemd --new --name test > ~/.config/systemd/user/test.service
sed -i '/\[Service\]/a NoNewPrivileges=true' ~/.config/systemd/user/test.service
sed -i '/\[Unit\]/a BindsTo=podman-usernamespace.service' ~/.config/systemd/user/test.service
sed -i '/\[Unit\]/a After=podman-usernamespace.service' ~/.config/systemd/user/test.service

cat << EOF > ~/.config/systemd/user/podman-usernamespace.service
[Unit]
Description=podman-usernamespace.service

[Service]

Type=oneshot
Restart=on-failure
TimeoutStopSec=70
ExecStart=/usr/bin/podman unshare /bin/true
RemainAfterExit=yes

[Install]
WantedBy=default.target
EOF


systemctl --user daemon-reload
pkill -9 -u $USER

2. Run commands in the terminal

[root@asus ~]# useradd testuser 
[root@asus ~]# cat prepare.sh | systemd-run --machine=testuser@ --quiet --user --collect --pipe --wait bash -
e66264b98777e12192600bf9b4d663655c98a090072e1bab49e233d7531d1294
289760e50aeb2650e09d252fa83ffa28d91859d7b097ed8319797a539d80578f
[root@asus ~]# pgrep -u testuser
[root@asus ~]# machinectl shell testuser@
Connected to the local host. Press ^] three times within 1s to exit session.
[testuser@asus ~]$ systemctl --user start test.service
[testuser@asus ~]$ systemctl --user is-active test.service
active
[testuser@asus ~]$ systemctl --user is-active podman-usernamespace.service
active
[testuser@asus ~]$ 

[vrothberg]

Did you consider using podman run --security-opt no-new-privileges instead?

[rhatdan]

This might work if you launched a rootful podman.

[ciandonovan]

Does Podman itself have a way to restrict the address families? That would be a nice option and avoid the issue with newsuid

[ciandonovan]

OK, I see. It's leaving the supported territory.

My idea was to run Podman with as few privileges as possible. From a security point of view I think it would be better to remove privileges as early as possible (i.e. letting systemd remove the privileges instead of Podman)

For instance could podman run --pull=never ... be used for an internet-restricted Podman. In another systemd service an unrestricted Podman could pull the container image.

I find it fascinating that it is possible to run a socket-activated web server with Podman, but at the same time restrict Podman (by using RestrictAddressFamilies=AF_UNIX AF_NETLINK) so that Podman is not able to pull any container image from the internet.

The reason I investigated NoNewPrivileges=true is that it is implied by RestrictAddressFamilies=AF_UNIX AF_NETLINK according to this quote from the RestrictAddressFamilies documentation: If running in user mode, or in system mode, but without the CAP_SYS_ADMIN capability (e.g. setting User=), NoNewPrivileges=yes is implied.

Of note, this is no longer the case as of systemd version 255, NoNewPrivileges not implied and can be set on or off at will

[eriksjolund]

I wrote a blog post about the topic (from August 2022)

https://www.redhat.com/sysadmin/podman-systemd-limit-access

This discussion thread (from July 2023)

• Is there a need for an official systemd unit podman-usernamespace.service? #19370

is also related.

[eriksjolund]

Of note, this is no longer the case as of systemd version 255, NoNewPrivileges not implied and can be set on or off at will

Thanks, good to know!