greetd + SELinux issues

[gerblesh]

this issue is detailing the repeated problems we had with greetd and SELinux in the discord, don't know if this will ever be solved or if it can be solved but it's good to have it as an issue.
the issue:
greetd spits out this error when trying to setup it up with agreety

cp: cannot create regular file '/var/lib/greetd.justfile': Permission denied

greetd has the wrong SELinux context rules, and there's currently no way to change it
here is what the context rules are:
running: ls -lZ /usr/bin/greetd

-rwxr-xr-x. 3 root root system_u:object_r:bin_t:s0 839488 Jan  1  1970 /usr/bin/greetd

here's what they should be:

system_u:object_r:xdm_exec_t,s0

The build errors when trying to change the context while building the image:

chcon: can't apply partial context to unlabeled file '/usr/bin/greetd'

again, don't know if this can or ever be fixed, but it's good to have an issue on github nonetheless

[jpeeler]

Some additional information on bugzilla I filed here: https://bugzilla.redhat.com/show_bug.cgi?id=2224162.

I think this is worth looking into further as surely this is not a greetd specific issue?

[akdev1l]

it looks like the issue can be reproduced in a regular fedora container with GDM:

I tried doing: -v /sys/fs/selinux:/sys/fs/selinux -v /etc/selinux/config:/etc/selinux/config and the resulting container reports SELinux as enabled in enforcing mode correctly (in case the packages are detecting this at install time)

still the resulting binary is not correct

[root@c8a1df5a7145 selinux]# ls -lZ /usr/sbin/gdm
-rwxr-xr-x. 1 root root system_u:object_r:container_file_t:s0:c1022,c1023 400912 Mar  2 14:37 /usr/sbin/gdm

it is worth noting that I am not even sure why container_file_t was set because my container was also running with --security-opt label=disable so the files created should have unlabeled_t

[akdev1l]

trying to manually set the context via restorecon complains about missing file contexts, once I pass through the file context configuration then restorecon complains further:

/usr/sbin/gdm not reset as customized by admin to system_u:object_r:container_file_t:s0:c1022,c1023

the package container-selinux is not installed inside the container and forcing restorecon -F results in an error:

restorecon: Could not set context for /usr/sbin/gdm:  Operation not supported

[akdev1l]

turns out the labeling happens at deployment time inside ostree-rs-ext. Filed an issue to ask if this is a bug due to the package only shipping a binary policy and no file_contexts configuration

[akdev1l]

We got confirmation from upstream that this is behavior is actually not intended but part of a long standing issue.

It is not easy to resolve. As a workaround we can probably ship out the configuration in /etc/selinux/targeted/file_contexts - this will allow the booted system to read what the contexts should actually be.

Currently working on a prototype to see if I can get selinux rebaling working inside podman.

[akdev1l]

Turns out this is complex because SELinux is not namespaced so selinux in podman actually requires an out-of-band method of storing the correct labels. This is not implemented as of now.

I have been thinking of a method in which we can perhaps pull a container, spin up a small VM to load the correct SELinux policy in the image and then trigger a relabel.

It sounds possible. If so we could add this as a step post-build to fix the labeling issues. This idea was originally pointed to me by cgwalters - it may work

[plata]

I ran into the same problem with Waydroid: waydroid/waydroid#1032