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. -- paul-moore.com
