For bootable containers, currently chunkah doesn't even try to persist security.selinux xattrs because it can't rely on the labels it sees from the target rootfs image mount.
But this means we lose out on server-side labeling, which has various benefits: (1) you get authoritative labels that you can test with in CI and know it matches the client-side (see e.g. coreos/fedora-coreos-tracker#2030), (2) bootc doesn't need to do a two-pass import for relabeling, which itself can cause issues (see e.g. bootc-dev/bootc#1637 and coreos/fedora-coreos-config#4265).
But I also would prefer chunkah to stay out of the business of SELinux labeling itself. That code already exists in lots of places in the bootc stack so ideally we reuse that. What we could do is support an xattr mapping scheme from the user to security namespace. E.g. before calling chunkah, $tools like bootc (e.g. via a bootc container relabel command) could add user.selinux xattrs, and then chunkah knows to translate this to security.selinux. Or make it even more generic? E.g. user.chunkah-security-$key=$val where chunkah knows to map that to security.$key=$val... Probably not worth the UX hit.
Ancillary to this: we need to make sure that in-stream SELinux labels work as expected in bootc (no longer requires two passes), and even with container runtimes themselves (so that podman run ... still works as expected).
For bootable containers, currently chunkah doesn't even try to persist
security.selinuxxattrs because it can't rely on the labels it sees from the target rootfs image mount.But this means we lose out on server-side labeling, which has various benefits: (1) you get authoritative labels that you can test with in CI and know it matches the client-side (see e.g. coreos/fedora-coreos-tracker#2030), (2) bootc doesn't need to do a two-pass import for relabeling, which itself can cause issues (see e.g. bootc-dev/bootc#1637 and coreos/fedora-coreos-config#4265).
But I also would prefer chunkah to stay out of the business of SELinux labeling itself. That code already exists in lots of places in the bootc stack so ideally we reuse that. What we could do is support an xattr mapping scheme from the user to security namespace. E.g. before calling chunkah, $tools like bootc (e.g. via a
bootc container relabelcommand) could adduser.selinuxxattrs, and then chunkah knows to translate this tosecurity.selinux. Or make it even more generic? E.g.user.chunkah-security-$key=$valwhere chunkah knows to map that tosecurity.$key=$val... Probably not worth the UX hit.Ancillary to this: we need to make sure that in-stream SELinux labels work as expected in bootc (no longer requires two passes), and even with container runtimes themselves (so that
podman run ...still works as expected).