install_t is the gift that keeps on giving. Previously e.g. https://bugzilla.redhat.com/show_bug.cgi?id=2110012 (rpm-)ostree needs to be able to write SELinux labels for the *new* OS update, so we run as install_t. But for bootstrapping in OpenShift we now want to run rpm-ostree *in a container*, and policy is denying this (when doing a major update of course, minor updates that don't change policies don't hit this, which is why I didn't notice until now) https://issues.redhat.com/browse/MCO-396 Things work for me with just this: ``` $ cat spc_install.te module spc_install 1.0; require { type container_file_t; type spc_t; type install_t; class process transition; class file entrypoint; } #============= install_t ============== allow install_t container_file_t:file entrypoint; #============= spc_t ============== allow spc_t install_t:process transition; $ ``` Basically we're now doing: podman run --privileged runcon -t install_t ...
(Previously, when we did things like this we had a huge workaround where the code run in the container actually just passed data over to the host process, but that'd be much harder for what we want here) Short term I may look at just shipping the above in FCOS derivatives and down to RHCOS but it'd be good to just support this out of the box in policy - a privileged container can already do whatever it wants, supporting `runcon -t install_t` just avoids the need to `setenforce 0` etc.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.