We do RPM things. Some of those RPM things need the /proc file system. Not forever, but for a short while. So we mount /proc, do something, and unmount. Which works fine.
Until we tried to do it in a container.
When we ran our umount code in the container, we got the following error:
umount: /meta/meta-rpm/build/tmp/work/qemux86_64-redhat-linux/rpmbased-minimal-image/1.0-r0/rootfs/.proc: block devices are not permitted on filesystem.
SELinux. Running in permissive mode worked fine. In /var/log/messages We have the following message:
May 5 15:22:41 zygarde setroubleshoot: SELinux is preventing /meta/meta-rpm/build/tmp/work/qemux86_64-redhat-linux/rpmbased-minimal-image/1.0-r0/recipe-sysroot-native/usr/bin/umount from unmount access on the filesystem .#012#012 Plugin catchall (100. confidence) suggests *******#012#012If you believe that umount should be allowed unmount access on the filesystem by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c ‘umount’ –raw | audit2allow -M my-umount#012# semodule -X 300 -i my-umount.pp
It seems somewhat unbalanced that a container can mount a filesystem, but not unmount one.
As the messages said, we can get by it by building and running a custom policy:
ausearch -c 'umount' --raw | audit2allow -M my-umount semodule -X 300 -i my-umount.pp
Its overkill, but you can never have too much overkill.
Actually, yes you can. When your goal is to not violate security constraints, opening up a hole is counterproductive.
When we run a container, by default, it gets the labeled as container_runtime_t:
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ayoung 1736123 1609658 0 18:04 pts/1 00:00:00 grep --color=auto metarpm
To change the label, run with a different security context. For instancing running podman with –security-opt label=type:metarpm.process like this:
podman run -it --security-opt label=type:metarpm.process -v /dev/fuse:/dev/fuse -v metadata:/meta localhost/metarpm /usr/bin/bash
Gives ends up with a process labeled system_u:system_r:metarpm_policy.process like this:
system_u:system_r:metarpm_policy.process:s0:c738,c1010 100999 1736385 1736373 0 18:08 pts/0 00:00:00 /usr/bin/bash
So long as this matches policy, we can do new things. But if we don’t ,we can’t do anything. But writing SELinux policy is a non-trivial amount of learning curve. How can we simplify?
Udica. Pronounced you-DI-tza. Or something like that.
Now…I’m going to cut out some of my trial and error with Udica. Following the instructions alone did not solve my problem, mainly because Udica does not yet understand how to deal with the umount or ioctl erros caused by the container. Here is what worked
- set SELinux in permissive mode, so the operations succeeds, but the errors get caught in the audit log
- as a non-root user,
- start the container and run the bitbake function to generate the errors
- run the podman ps command to get the container id
- redirect the output a file
- stop the container
- as root
- re-enable SELinux
- cat the output of the file generated above into udica, add the flag to read the audit file
- load the generated policy
Here is what that looks like on the terminal. As root
$ podman run -it --security-opt seccomp=unconfined -v /dev/fuse:/dev/fuse -v metadata:/meta localhost/metarpm /usr/bin/bash $ cd /meta/meta-rpm/ $ . ./oe-init-build-env $ bitbake rpmbased-minimal-image
Leave that running, and go to another terminal as ayoung
$ podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES c153bee4a84d localhost/metarpm /usr/bin/bash About a minute ago Up About a minute ago naughty_heyrovsky $ podman inspect c153bee4a84d > container.json <pre> <!-- /wp:html --> <!-- wp:paragraph --> <p>Now as <strong>root</strong></p> <!-- /wp:paragraph --> <!-- wp:html --> <pre lang="bash"> $ cat container.json | udica metarpm --append-rules /var/log/audit/audit.log $ setenforce enforcing $ semodule -i metarpm.cil /usr/share/udica/templates/base_container.cil $ semodule -l | grep meta metarpm
As the ayoung user, rerun the container with the additional flag
$ podman run -it --security-opt label=type:metarpm.process --security-opt seccomp=unconfined -v /dev/fuse:/dev/fuse -v metadata:/meta localhost/metarpm /usr/bin/bash
If you look in the process list, you can see the container running:
$ ps -efZ | grep meta unconfined_u:system_r:container_runtime_t:s0-s0:c0.c1023 ayoung 1977102 1609151 0 13:25 pts/0 00:00:00 podman run -it --security-opt label=type:meth unconfined_u:system_r:container_runtime_t:s0-s0:c0.c1023 ayoung 1977115 1977102 0 13:25 pts/0 00:00:00 podman run -it --security-opt label=type:meth system_u:system_r:metarpm.process:s0:c492,c842 100999 1977157 1977145 0 13:25 pts/0 00:00:00 /usr/bin/bash unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ayoung 1977217 1939598 0 13:26 pts/1 00:00:00 grep --color=auto meta
If I rerun the bitbake command now (after cleaning the output of the successful permissive run) it will succeed.
Here is the difference between the default output of udica and adding in the flag that pulls in the audit file:
# diff metarpm.cil.orig metarpm.cil 11a12,13 > (allow process proc_t ( file ( ioctl ))) > (allow process proc_t ( filesystem ( unmount )))