setfiles: Could not set context on SELinux-enforcing systems
#6
Comments
|
Yep, we accidentally tested this tool only on selinux-disabled systems. :( Looking into this is my highest priority. |
|
Thanks for checking, @ondrejbudai ! |
|
@rhatdan may be able to help :) |
|
Any AVC's? |
|
It would be nice if the context below was actually displayed. Most likely the context does not exist on the host system. |
|
From the AVC's I see that the script is attempting to set time->Tue Nov 21 07:24:17 2023 The issue here is this a process label not a file label, so the script is rightfully blocked. I think there is a bug in osbuild when attempting to set this label. |
ondrejbudai
changed the title
setfiles: Could not set context on SELinux-enforcing systems
|
These are the messages from This issue is not new to The root cause lies in the fact that osbuild needs to apply SELinux labels on the filesystem being built. This wouldn't be a big issue if it builds the same distribution as it runs on. However, when osbuild deals with cross-distribution building, it can happen that it needs to apply a label that the host doesn't know. In this particular case, we build Fedora ELN on Fedora 38/39. Fedora ELN uses
Let's take a look at how
To sum it up, even though Now lt's look at our options inside a If the host has Without I was thinking that a simple fix would be to run Another option for labeling the filesystem without our custom selinux policy is to move the labeling process out of The last-resort option is AFAIK to run certain stages without I must admit though, that I might be missing something obvious and that I might have completely misunderstood the relationship between SELinux domain transitions and |
The hyperlink seems wrong?
Please, no. I've spent sooooo much time ensuring SELinux labeling in ostree works well, having something else try to override/recompute all the labels is really unappealing. It's also really important to note that the use case here is deploying a pre-labeled (ostree) container image; we don't want to go in and potentially change those labels. (Also with composefs enabled, one can't) That said...even today we have a "bootstrap" problem for the labels on the files/directories necessary for all the files/directories leading up to the ostree root. In coreos-assembler's create_disk.sh we basically cheat because the labels come from the policy of the build container. In the way bootc works, we have the target OS image running as a container and so it's more natural to use that for labeling. But...doing this here does require fetching and unpacking the container (or at least
Well, yes. Ultimately because there's no namespacing for SELinux, anything writing arbitrary labels needs full privileges. That said, what bootc tries today is to ensure the entire process runs as So we could try that here too. Note that doing this I think requires today doing |
Also with Anaconda today it's similar; these labels use the policy embedded in the Anaconda ISO. In general this doesn't really matter because the labels for the "bootstrap state" haven't changed in forever. Looks like |
|
The process does not need MAC_ADMIN, this is happening because it is trying to pull a processes label (current label) on to the file system. SELinux does not allow process labels to be applied to file system, because they make no sense. I ran the centos-bootc image and searched for spc_t in the /etc/selinux/targeted/context/files/* directory and there is nothing there, so I have no idea what is going on here. |
|
We could try running
|
The is coming from https://github.com/osbuild/osbuild/blob/f982b1f61af012dfdf7addf78c363f8d293638de/stages/org.osbuild.selinux#L62
|
But we do want to ensure that the labels are retained and so our tools inside the build root need to be correctly labelled and have the appropriate policy to write those labels (see previous comment about |
|
I am looking for where that main is exec'd Somewhere tree is set and file_contexts is being set, the content of the file_context looks wrong, at least pulling in the spc_t label. ["setfiles", "-F", "-r", f"{tree}", f"{file_contexts}", f"{tree}"], check=True) |
|
|
|
What exactly is osbuild doing with the skopeo command? Does it just assemble a rootfs? If so, then we might be able to speed this up buy pulling the image and then using it from local containers/storage. Rather then pulling it everytime. |
|
It uses |
When building an image, we need to make sure that the target system is correctly labeled. This becomes challenging if the target system contains labels that are unknown to the host because the process setting the label needs to have CAP_MAC_ADMIN if the host is SELinux-enforcing. CAP_MAC_ADMIN isn't a common capability on a SELinux-enforcing system. Even unconfined_t doesn't have it (same for spc_t - label used by --privileged containers). Thus, we need to ensure that we transition to a domain that actually has it. This commit relabels osbuild as install_t, a domain that has CAP_MAP_ADMIN. A bit of mount-dancing is needed in order to achieve that, see prepare.sh. I decided to make prepare.sh a separate script. This is useful for debugging: host # podman run -it \ --privileged \ --security-opt label=type:unconfined_t \ --entrypoint bash \ localhost/osbuild-deploy-container container # ./prepare.sh This way, you get the same environment as if you run the container the default way. See #6 (comment) and links in this comment for further information.
When building an image, we need to make sure that the target system is correctly labeled. This becomes challenging if the target system contains labels that are unknown to the host because the process setting the label needs to have CAP_MAC_ADMIN if the host is SELinux-enforcing. CAP_MAC_ADMIN isn't a common capability on a SELinux-enforcing system. Even unconfined_t doesn't have it (same for spc_t - label used by --privileged containers). Thus, we need to ensure that we transition to a domain that actually has it. This commit relabels osbuild as install_t, a domain that has CAP_MAP_ADMIN. A bit of mount-dancing is needed in order to achieve that, see prepare.sh. I decided to make prepare.sh a separate script. This is useful for debugging: host # podman run -it \ --privileged \ --security-opt label=type:unconfined_t \ --entrypoint bash \ localhost/osbuild-deploy-container container # ./prepare.sh This way, you get the same environment as if you run the container the default way. See #6 (comment) and links in this comment for further information.
Tried with
quay.io/centos-boot/fedora-tier-1:elnandquay.io/centos-boot/centos-tier-1:stream9.The text was updated successfully, but these errors were encountered: