Quadlet containers re-label all volumes with a new MCS each restart

[hakong]

Example:
~/.config/containers/systemd/grafana.container:

[Container]
Image=docker.io/grafana/grafana
ContainerName=grafana
PublishPort=3001:3000
Volume=%h/data:/var/lib/grafana:Z

[Service]
Restart=always

[Install]
WantedBy=default.target

[grafana@container-1 ~]$ podman ps
CONTAINER ID  IMAGE                             COMMAND     CREATED       STATUS                 PORTS                   NAMES
2960ef9e7bdc  docker.io/grafana/grafana:latest              15 hours ago  Up 15 hours (healthy)  0.0.0.0:3001->3000/tcp  grafana

[grafana@container-1 ~]$ ls -lZ data/
total 964
drwxr-xr-x. 3 755831 grafana system_u:object_r:container_file_t:s0:c430,c714     15 Jan 20 18:19 alerting
drwx------. 2 755831 grafana system_u:object_r:container_file_t:s0:c430,c714      6 Jan 20 18:19 csv
-rw-r-----. 1 755831 grafana system_u:object_r:container_file_t:s0:c430,c714 987136 Feb  8 14:20 grafana.db
drwxr-xr-x. 2 755831 grafana system_u:object_r:container_file_t:s0:c430,c714      6 Jan 20 18:19 plugins
drwx------. 2 755831 grafana system_u:object_r:container_file_t:s0:c430,c714      6 Jan 20 18:19 png
[grafana@container-1 ~]$

MCS Label: c430,c714

[grafana@container-1 ~]$ systemctl restart grafana

[grafana@container-1 ~]$ ls -lZ data/
total 964
drwxr-xr-x. 3 755831 grafana system_u:object_r:container_file_t:s0:c807,c1019     15 Jan 20 18:19 alerting
drwx------. 2 755831 grafana system_u:object_r:container_file_t:s0:c807,c1019      6 Jan 20 18:19 csv
-rw-r-----. 1 755831 grafana system_u:object_r:container_file_t:s0:c807,c1019 987136 Feb  8 14:24 grafana.db
drwxr-xr-x. 2 755831 grafana system_u:object_r:container_file_t:s0:c807,c1019      6 Jan 20 18:19 plugins
drwx------. 2 755831 grafana system_u:object_r:container_file_t:s0:c807,c1019      6 Jan 20 18:19 png

MCS Label: c807,c1019

Is this intended? This can cause containers with volumes that contain a large amount of files to be very slow to restart.
AFAICS this is because the container is being removed each time and re-created.

[grafana@container-1 data]$ podman ps
CONTAINER ID  IMAGE                             COMMAND     CREATED       STATUS        PORTS                   NAMES
37626003715a  docker.io/grafana/grafana:latest              18 hours ago  Up 2 seconds  0.0.0.0:3001->3000/tcp  grafana
[grafana@container-1 data]$ podman stop grafana
grafana
[grafana@container-1 data]$ time podman start grafana
grafana

real    0m0.139s
user    0m0.058s
sys     0m0.044s
[grafana@container-1 data]$ podman stop grafana
grafana
[grafana@container-1 data]$ time systemctl start grafana

real    0m24.207s
user    0m0.004s
sys     0m0.005s

The reason I start this discussion is because we have a software repository mirror (what type doesn't matter, just many files) and starting/restarting it takes over 5 minutes (it's not pulling the image).

[ygalblum]

I can see that you are setting the relabeling to private (by adding Z). Did you consider setting it to shared (replacing Z with z)?
Please see the Labeling Volume Mounts section in the man page.

[hakong]

That's an option, but from the standpoints of principles of least privilege, I would prefer not to.
Using the features SELinux offers to segregate access to data by different containers on the same user (or even the same host) in case of a container escape (or other issues) will only work with a private MCS label.

This isn't an issue when using podman directly (e.g. podman run, podman stop, podman start) since the container isn't removed (just stopped and started) and nothing is relabeled.

The CI/CD pipeline for the software repository mirror in question takes a long time to run because each time the container is started with systemd it will relabel the entire repository.

Reading https://github.com/containers/quadlet/blob/main/docs/ContainerSetup.md#robust-container-shutdown provides a bit more insight into why containers are removed when using systemd. At a first glance there doesn't seem to be anything to be done about this, but it would be a big improvement if podman was smarter about relabeling when using a Z.

(ps. is there anything that prevents podman from using an MCS label that's already been used on the system, other than just roughy 1/500000 chance? https://opensource.com/article/18/2/selinux-labels-container-runtimes)

[hakong]

It also seems that using SecurityLabelLevel=<random MCS label> with a Z is slightly faster than z:

Z with SecurityLabelLevel=

[grafana@container-1 data]$ time systemctl restart grafana

real    0m3.972s
user    0m0.004s
sys     0m0.008s
[grafana@container-1 data]$ time systemctl restart grafana

real    0m3.935s
user    0m0.005s
sys     0m0.004s
[grafana@container-1 data]$ time systemctl restart grafana

real    0m3.995s
user    0m0.003s
sys     0m0.007s
[grafana@container-1 data]$ time systemctl restart grafana

real    0m3.935s
user    0m0.002s
sys     0m0.008s
[grafana@container-1 data]$ time systemctl restart grafana

real    0m3.963s
user    0m0.005s
sys     0m0.004s
[grafana@container-1 data]$ time systemctl restart grafana

real    0m3.966s
user    0m0.002s
sys     0m0.008s

Only z:

[grafana@container-1 data]$ time systemctl restart grafana

real    0m4.017s
user    0m0.002s
sys     0m0.008s
[grafana@container-1 data]$ time systemctl restart grafana

real    0m4.076s
user    0m0.002s
sys     0m0.008s
[grafana@container-1 data]$ time systemctl restart grafana

real    0m4.256s
user    0m0.005s
sys     0m0.005s
[grafana@container-1 data]$ time systemctl restart grafana

real    0m3.925s
user    0m0.003s
sys     0m0.007s
[grafana@container-1 data]$ time systemctl restart grafana

real    0m3.884s
user    0m0.002s
sys     0m0.008s
[grafana@container-1 data]$ time systemctl restart grafana

real    0m4.001s
user    0m0.002s
sys     0m0.007s

[rhatdan]

Pick a static MCS Label for the containers in the quadlet, and then initialize the volume to match the label, and then do not add :Z
That way you get the protection and the data is never relabeled.