Stephen Smalley <stephen.smalley.work@xxxxxxxxx> writes: > 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? AFAIK (and from experience) yes, CAP_MAC_ADMIN and root. Theres also setfiles_mac_t for this. > >> 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. > I agree but its not mounted on the host. It just installs a tree on the host, labels that a then uses systemd-repart with --offline [1] option to copy the tree to a disk image (no root needed and no mounting needed) You'd still need to be able to associate an invalid label with the file. [1] "--offline=BOOL Instructs systemd-repart to build the image offline. Takes a boolean or "auto". Defaults to "auto". If enabled, the image is built without using loop devices. This is useful to build images unprivileged or when loop devices are not available. If disabled, the image is always built using loop devices. If "auto", systemd-repart will build the image online if possible and fall back to building the image offline if loop devices are not available or cannot be accessed due to missing permissions. Added in version 254. " https://github.com/systemd/mkosi/blob/main/mkosi/__init__.py#L3210 https://github.com/systemd/mkosi/blob/main/mkosi/__init__.py#L3334 -- gpg --locate-keys dominick.grift@xxxxxxxxxxx (wkd) Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 Dominick Grift Mastodon: @kcinimod@xxxxxxxxxxx
