-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OCI SELinux labeling mismatch when package only ships binary policy - greetd is broken #510
Comments
Yes. This relates to #388 where we want to basically move the labeling to the build time. That said, something I think would also be interesting is to create a dedicated "image transform" container that can accept any arbitrary container as input and produce a "boot-ready" (including proper selinux labeling) container image. This would replace a need for |
To fix this in the current architecture (without changing
Basically SELinux greatly complicates the architecture here because it's a set of files that can affect any other file. So far the "always use the policy from the base" is a compromise. |
I guess the first step towards the "container transformer" is to have a container that is capable of doing the labelling needed. Mm I've been thinking about this and trying to get a container that allows me to properly label these files - even if it's just a PoC I've been using podman and I ran into the issue that podman passes a I'm just leaving this comment here for my own reference but if anyone has any clues that'd be helpful. |
There's a lot of complexity here around xattrs and OCI and podman, see extensive discussion in containers/storage#1608 |
An update here, we were able to troubleshoot around some non-filesystem related SELinux issues by shipping our custom policy and running
This specific policy does not have any changes to the filesystem so I am not sure if it would be affected by this but noting here just for reference. In theory if can just load the policy from within the container this may work? (I didn’t know GitHub let you do that until today) (sorry for the noise) |
mm it seems that if we use podman
so in theory if we can just grab a container, run it using the |
Not really, ostree wants to own the security contexts, trying to change them behind its back won't really work. The most reliable is going to be #510 (comment) but it's ugly to implement today. |
Yeah, this also breaks layering libvirt and enabling swtpm. Annoying. |
Does OSTREE just need the final /etc/selinux/targeted/context/files directory? Or do the files actually have to be applied as XAttrs within the image? |
For swtpm, what would be the most minimal work around right now? This breaks VMs quite a bit for me. |
For my minimal workaround. I am using a systemd service to copy the swtpm binary to a mutable location. Bind mounting the mutable binary back over /usr/bin/swtpm. Then fix the file contexts and relabel it. What are the downsides for this work around?
|
This also relates to containers/bootc#215 - that's where I'm thinking about going with this. |
Another workaround is basically:
|
Hi OSTree team,
I am trying to debug an issue that surfaced in Ublue (ublue-os/main#223). In Ublue we are making use of the OCI functionality heavily to produce custom downstream images of Fedora Silverblue. Some users have wanted to install
greetd
as their greeter for simplicity but whenever they do the resulting image is slightly broken because of wrong SELinux labeling.I have investigated the package and I see that
/usr/bin/greetd
should be labeled asxdm_exec_t
(see: here) which makes sense for a display manager but in the resulting images we see that/usr/bin/greetd
is labeled asbin_t
and therefore access gets denied by SELinux when the system is booted.This is the output of
ls -lZ
in the images:this is the package source that shows the intended labeling:
I tried to trace down the issue and I found this function:
sepolicy_from_base
:I am not an expert but if I understand correctly this will look for the labels defined in
/usr/etc/selinux
in the resulting image and then it willrestorecon
based on that. In this case the package only ships a binary policy so my theory was that this would not find the rule/usr/bin/greetd -- gen_context(system_u:object_r:xdm_exec_t,s0)
which is defined in a binary policy therefore leading to the wrong labeling we observed.We can use this minimal Containerfile to reproduce reliably:
The text was updated successfully, but these errors were encountered: