Stephen Smalley <stephen.smalley.work@xxxxxxxxx> writes: > 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. > The use-case for this is livecd/usb creation. For example creating an MLS livecd/usb on a non-MLS host. I also hit this issue on policy-developement as I am also a user of the mkosi tool that is referenced in the issue. mkosi is a tool that can build a source and boot an image using that source. If I add some module to my policy source tree and I want to test that in a virtual machine then I would run mkosi on the source. mkosi is not allowed to use the label that is unknown on the host on the filesystem. So the file ends up unlabeled in the virtual machine. So using mkosi for testing policy is not useful unless you run mkosi as root. Which is fair to be honest. There is quite a bit of functionality in mkosi that only works if you run it as root. -- gpg --locate-keys dominick.grift@xxxxxxxxxxx (wkd) Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 Dominick Grift Mastodon: @kcinimod@xxxxxxxxxxx
