How to use the systemd directive "RestrictAddressFamilies" with "podman run"?

[eriksjolund]

Could the systemd directive RestrictAddressFamilies be used to lock down podman run in a systemd user service?
The idea would be to get some extra protections against vulnerabilities in podman.

When I try RestrictAddressFamilies=AF_UNIX, podman run fails with Error: OCI runtime error: crun: socket: Address family not supported by protocol. (See below for the details)

Socket-activated sockets are excluded from the restrictions:

Quote from the systemd.exec man page
Sockets passed into the process by other means (for example, by using socket activation with socket units, see systemd.socket(5)) are unaffected.

I did an experiment

mkdir -p  ~/.config/systemd/user
cd ~/.config/systemd/user
podman run --rm -d --name test docker.io/library/alpine sleep inf
podman generate systemd --name --new test | sed 's/\t/    /g' > test.service.orig

Test 1: RestrictAddressFamilies=none

The file patch1 contains

--- test.service.orig	2022-05-21 14:24:48.355738661 +0200
+++ test.service	2022-05-21 14:27:26.112727012 +0200
@@ -13,10 +13,15 @@
 Environment=PODMAN_SYSTEMD_UNIT=%n
 Restart=on-failure
 TimeoutStopSec=70
+RestrictAddressFamilies=none
 ExecStartPre=/bin/rm -f %t/%n.ctr-id
 ExecStart=/usr/bin/podman run \
     --cidfile=%t/%n.ctr-id \
     --cgroups=no-conmon \
+    --pull=never \
+    --log-driver=k8s-file \
+    --log-opt path=/tmp/test \
+    --network none \
     --rm \
     --sdnotify=conmon \
     --replace \

$ cp test.service.orig test.service
$ patch -p0 < patch1
patching file test.service
$ systemctl --user daemon-reload
$ 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.
$ journalctl --user -xeu test.service | grep error| tail -1
May 21 14:45:53 asus podman[23080]: time="2022-05-21T14:45:53+02:00" level=error msg="Unable to write pod event: \"could not initialize socket to journald\""
$ 

Result: level=error msg="Unable to write pod event: \"could not initialize socket to journald\""

Test 2: RestrictAddressFamilies=AF_UNIX

Edit the file test.service and replace

RestrictAddressFamilies=none

with

RestrictAddressFamilies=AF_UNIX

$ systemctl --user daemon-reload
$ systemctl --user reset-failed test.service
$ 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.
$ journalctl --user -xeu test.service | grep Error | tail -1
May 21 14:52:09 asus podman[23374]: Error: OCI runtime error: crun: socket: Address family not supported by protocol
$ 

Result: Error: OCI runtime error: crun: socket: Address family not supported by protocol

Test 3: RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6

After also adding AF_INET AF_INET6 the service test.service started successfully.

I'm not quite sure why the log says image pull docker.io/library/alpine because --pull=never has been set.

$ journalctl --user -xeu test.service | tail -1
May 21 15:51:56 asus podman[23538]: 2022-05-21 15:51:55.973284311 +0200 CEST m=+0.025711802 image pull  docker.io/library/alpine
$ 

Is it possible to get it working with fewer privileges than:

RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6

?

[mheon]

I can definitely say that RestrictAddressFamilies=none will not work - we use Unix sockets internally to handle container attach.

I am somewhat surprised that restricting to AF_UNIX only does not work - @giuseppe The error seems to be coming out of crun - thoughts?

@eriksjolund Does it work if you use runc instead?

[giuseppe]

interested to open a PR? :-)

[eriksjolund]

Not at the moment. (Currently I'm not familiar with AF_NETLINK)

[eriksjolund]

I created a feature request

• Add support for "RestrictAddressFamilies=AF_UNIX AF_NETLINK" crun#929

A sidenote: I did a successful test with runc and the echo server
ghcr.io/eriksjolund/socket-activate-echo with one socket-activated TCP socket
and RestrictAddressFamilies=AF_UNIX AF_NETLINK.

I noticed there is problem when using 3 socket-activated sockets with runc

• Socket activation with 3 sockets fails opencontainers/runc#3488

[eriksjolund]

I verified that the systemd restriction works. As expected, the combination

• runc
• RestrictAddressFamilies=AF_UNIX AF_NETLINK
• --pull=always
• --network=none
• --log-driver=k8s-file
• --log-opt path=/tmp/test.log
• one socket-activated TCP socket

  ● test.socket - test
       Loaded: loaded (/home/test138/.config/systemd/user/test.socket; disabled; vendor preset: disabled)
       Active: active (listening) since Thu 2022-05-26 10:13:00 CEST; 3s ago
        Until: Thu 2022-05-26 10:13:00 CEST; 3s ago
     Triggers: ● test.service
       Listen: 127.0.0.1:9000 (Stream)
       CGroup: /user.slice/user-1047.slice/[email protected]/app.slice/test.socket
  
  May 26 10:13:00 asus systemd[10686]: Listening on test.socket - test.
  

fails as it should because Podman is not able to pull the container image.
journalctl shows

$ journalctl --user -xe -u test.service | grep -i error | tail -2
May 26 10:09:54 asus podman[28272]: Error: initializing source docker://ghcr.io/eriksjolund/socket-activate-echo:latest: pinging container registry ghcr.io: Get "https://ghcr.io/v2/": dial tcp 140.82.121.34:443: socket: address family not supported by protocol
May 26 10:09:54 asus podman[28291]: Error: error reading CIDFile: open /run/user/1047/test.service.ctr-id: no such file or directory
$ 

[eriksjolund]

If running in user mode, or in system mode, but without the CAP_SYS_ADMIN capability (e.g. setting User=), NoNewPrivileges=yes is implied.
quote from the systemd documentation RestrictAddressFamilies

I noticed that the Podman user namespace needs to be created explicitly in another user service because NoNewPrivileges=yes has the effect that newuidmap runs without its extra capabilities and thus fails. See the discussion in

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

[vrothberg]

For completeness, I want to add that customizing the generated units files is not supported. While we will do our best to resolve issues as they come in, we can only support that Podman generates.