Paul Moore <paul@xxxxxxxxxxxxxx> writes: > On Wed, Jul 10, 2024 at 9:50 AM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> wrote: >> 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. > > FWIW, we would also need to see a very compelling reason with broad > reach that doesn't have a good workaround before we consider changing > the current behavior. The scenario described in the original GH issue > is interesting, but my suspicion is that it is fairly limited. > thanks!
