The --chroot option doesn't work well with SELinux off in-chroot

[praiskup]

Consider installing a separate minimal chroot, and then running useradd --root (other shadow-utils utility):

$ sudo dnf5 -y --use-host-config --installroot /tmp/newroot install /bin/sh
$ sudo useradd jdoe --root /tmp/newroot
useradd: failure while writing changes to /etc/passwd

I used GDB to detect what was going on. It is the call to set_selinux_file_context () at file-descriptor-closing-time.

The thing is that set_selinux_file_context() is called non-conditionally every time, and it asks for is_selinux_enabled() - which provides the info about SELinux on-host, not in-chroot:

shadow/lib/selinux.c

Lines 47 to 52 in 3e59e96

	int set_selinux_file_context (const char *dst_name, mode_t mode)
	{
	if (!selinux_checked) {
	selinux_enabled = is_selinux_enabled () > 0;
	selinux_checked = true;
	}

A further assumption that the selabel_open(), selabel_lookup_raw(), etc. in-chroot will work, is wrong.

There are further checks for permissive mode that make shadow utils not fail (in theory):

shadow/lib/selinux.c

Lines 66 to 68 in e367d11

	if (security_getenforce () != 0) {
	return 1;
	}

But one would have to make sure that the /tmp/newroot/sys/fs/selinux/enforce file exists first, and contains 0.

This problem is causing problems to Mock (RPM chrooted builds). We could fake the /sys/fs/selinux/enforce file for sure in Mock (we do other hacks to make things work), though this isn't the ideal solution; the mode in-chroot isn't really "permissive", it is supposed to be "disabled". So we should ideally not even attempt to call selabel_open(), etc.

While I see this probably isn't a mistake of shadow-utils (but rather chroot-unfriendly linbselinux API), I'm curious what is the best way out of this. Could we have a new --no-selinux option?

Also, note that the manual pages are a bit misleading:

       -P, --prefix PREFIX_DIR
           Apply changes to configuration files under the root filesystem
           found under the directory PREFIX_DIR. This option does not chroot
           and is intended for preparing a cross-compilation target. Some
           limitations: NIS and LDAP users/groups are not verified. PAM
           authentication is using the host files. No SELINUX support.

Note the note No SELinux support. This seems wrong. The set_selinux_file_context() is called with --prefix exactly the same way as with --root. It makes people think that --root works better with SELinux, but that's not truth either.

[pmatilai]

We (== rpm upstream) ran into this too: we'd like to use useradd/groupadd to create users into an otherwise practically empty chroot during the initial system install, but this selinux related logic prevents it. As @praiskup notes, just creating a fake enforcing file is enough to work around it:

[root@localhost]# rm -rf /srv/test/*
[root@localhost]# mkdir -p /srv/test/etc
[root@localhost]# groupadd -r -R /srv/test mumble
groupadd: failure while writing changes to /etc/group

[root@localhost]# mkdir -p /srv/test/sys/fs/selinux
[root@localhost]# echo 0 > /srv/test/sys/fs/selinux/enforce
[root@localhost]# groupadd -r -R /srv/test mumble
[root@localhost]#

This seems kinda counterproductive. Been there enough to know that SELinux and chroot aren't the best of friends, but few very few things are designed with a totally empty chroot in mind. In that case there are exactly two options: either use the info from the host, or disable. Disable is non-ambiguous, but obviously has other downsides.

I wouldn't mind working on a patch if we can agree on the desireable way to handle it. FWIW the rpm sysusers issue would be sufficiently handled with an explicit flag of some sort (cli switch, env variable).

[ikerexxe]

I'm not a SELinux expert, am I to assume that sys/fs/selinux/enforce is the file that indicates whether a system (or chroot) has SELinux activated?

[ffesti]

Yes.

[ikerexxe]

In that case, my preferred option would be for SELinux to take this into account and provide an interface that we can use to see if SELinux is enabled in the chroot environment. This would also allow other projects to use the same interface to do the same thing.

In case this is not possible shadow should check the sys/fs/selinux/enforce file manually in the chroot environment and act accordingly.

[praiskup]

Adding a new SELinux API (I assume you mean within the /sys/fs/selinux path) would be a long-shot 🤷 Then, before we invent a new interface there, IMO we should answer a basic question: Does it ever make sense to operate with SELinux if shadow utils are used with --root? It probably makes sense with --prefix.

@pmatilai I observe that dnf --installroot / rpm --root correctly sets SELinux labels on installed files. Is this done by implicit SELinux support of underlying utilities (like shadow-utils), or does RPM handle this post install via restorecon?

I also missed the comment in SELinuxProject/selinux#419 before, where @cgzones suggests calling fini_selinuxmnt. Could we call it when we detect that the --root option is used?

[pmatilai]

@pmatilai I observe that dnf --installroot / rpm --root correctly sets SELinux labels on installed files. Is this done by implicit SELinux support of underlying utilities (like shadow-utils), or does RPM handle this post install via restorecon?

rpm uses the SELinux API by itself - or rather, the plugin does. Unless I totally misremember something, it gets the labels from the host, so it's not really correct. Then again, there simply isn't anything else it could use when installing to an empty chroot.

(sorry for the late reply, I completely missed the question initially and only stumbled here now by accident)

[keszybz]

I'm not a SELinux expert, am I to assume that sys/fs/selinux/enforce is the file that indicates whether a system (or chroot) has SELinux activated?

No. That file indicates whether selinux is in enforcing mode, i.e. whether security denials are hard errors and not just warnings. This is not something that we care about here.

libselinux has is_selinux_enabled(3), which checks whether /sys/fs/selinux is mounted and whether selinux config was found (https://github.com/SELinuxProject/selinux/blob/d13d13eaee668812b15bc4a638d7b3437da75f78/libselinux/src/enabled.c#L11).

Does it ever make sense to operate with SELinux if shadow utils are used with --root? It probably makes sense with --prefix.

The man page explicitly says --prefix does not support selinux. So I think it makes less sense for --prefix to support it than it does for --root.

I don't think it makes sense to use the selinux state or config from the host system in a chroot. The whole point of a chroot is to have a different system, and even if the systems are broadly similar, creating labels that are 90% correct is not useful. It's worse than having no labels at all.

If we're installing into an empty (or partially populated) chroot, then the only thing that makes sense is to ignore selinux. Once everything is in place, and we know that full config is available, we can run a relabel to set labels, if appropriate and desired.

I think the useradd code should simply disable selinux support if --root or --prefix are specified.

[praiskup]

@keszybz +1, just a comment to this:

The man page explicitly says --prefix does not support selinux. So I think it makes less sense for --prefix to support it than it does for --root.

Could anyone want the --prefix option to apply host labeling rules without removing the prefix path? This is likely what I meant earlier. For example, if weird_label_t is recursively applied to /foo on the host and we use --prefix /foo, then the weird_label_t label would be applied to the /foo/etc/passwd file (instead of passwd_file_t, which is intended for /etc/passwd)?