On Wed, Jul 10, 2024 at 1:40 PM Dominick Grift <dominick.grift@xxxxxxxxxxx> wrote: > > 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'm fairly sure that people have been using the unknown label support for livecd creation successfully for quite some time. Have they just been doing it with CAP_MAC_ADMIN enabled or otherwise as root? > 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. Yes, I'm not sure if this is a compelling example. For Android I just built the support for labeling files into the filesystem image generation tools themselves so that it could produce a fully labeled filesystem without ever needing to mount it on the host. I think the Yocto meta-selinux tooling also migrated toward that kind of an approach, although I could be wrong.
