On Wed, Jul 10, 2024 at 9:32 AM Petr Lautrbach <lautrbach@xxxxxxxxxx> wrote: > > Hello, > > this is originally reported at > https://github.com/SELinuxProject/selinux/issues/437 > > There a question why kernel blocks changing SELinux label to some > unknown label and requires CAP_MAC_ADMIN even in permissive mode? > > Reproducer: > > $ id -u > 1000 > > $ getenforce > Permissive > > $ chcon -t bin_t /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator > > $ chcon -t selinux_unknown_type_t /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator > chcon: failed to change context of '/var/lib/mock/fedora-rawhide-x86_64/root/usr/lib/systemd/system-generators/systemd-ssh-generator' to ‘system_u:object_r:selinux_unknown_type_t:s0’: Invalid argument > > > Quotes from the issue: > > This is happening on a system with SELinux in permissive mode. Applying > your suggestion does not change the result. I assume this is gated > behind CAP_MAC_ADMIN for unprivileged users. Is there any way to make > this work without needing root privileges? > > Hmm so the kernel blocks unknown labels unless the user has > CAP_MAC_ADMIN in the initial user namespace. I'm assuming this is for a > good reason and it would be unsafe to allow any user to do this so I > don't think there's anything that can be done here > > One thing that's not clear to me, why is an unprivileged user allowed to > write labels known by the host but not labels that are not known to the > host? What specifically is unsafe about unknown labels that's not an > issue with known labels? With SELinux disabled, setting of security.* xattrs at all is gated by CAP_SYS_ADMIN. With SELinux enabled, the security.selinux xattrs can be set to valid security contexts without any capability if allowed by policy. Support for setting unknown security contexts was a later addition to SELinux for a specific use case (original motivation provided by Red Hat was to permit rpm to set contexts on files unpacked from a package before it inserted the corresponding policy module from %post), and was not expected to be used by unprivileged users. Smack had already introduced CAP_MAC_ADMIN at that point, and it seemed reasonable to use it for this purpose, since setting labels unknown to the policy is effectively like being the admin of the MAC policy. The policy can't make useful determinations about what to do with unknown labels so it can't provide any information flow guarantees. There may also have been a concern about the facility being abused to push arbitrary data into a security.selinux xattr to be fetched by some other privileged process later in a manner that would ultimately lead to a vulnerability. Not saying that we can't change things here, but would require a graceful and compatible transition path.
