Package: libselinux1
Version: 3.11-2
Severity: wishlist
X-Debbugs-Cc: Luca Boccassi <[email protected]>, Adrian Bunk <[email protected]>
The transitively-Essential libselinux1 package now Recommends
selinux-utils, as part of the change !14 [1] that moved a tmpfiles.d(5)
snippet from libselinux1 into selinux-utils to resolve #1141854 /
#1140305. This will not affect the contents of a deboostrap'd /
mmdebstrap'd system, because debootstrap intentionally doesn't follow
non-mandatory dependencies, but it's likely to result in selinux-utils
being pulled in by apt on non-minimal systems, even if they use a
different LSM (most commonly AppArmor) or no "big" LSM at all. I'd like
to query whether this is really necessary?
As well as pulling in what is probably an unnecessary package on
non-SELinux systems, this Recommends is circular:
/ -Recommends-> \
libselinux1 selinux-utils
\ <-Depends---- /
which I believe we generally try to avoid as a design principle, because
it inhibits autoremoval (garbage-collection of unused packages),
although the fact that libselinux is transitively Essential means that
in reality it isn't going to get removed anyway.
For reference, the purpose of the tmpfiles.d snippet is to create
/run/setrans, owned by root:root with 0755 permissions. Christian
explained on !14 that: "That directory is used by mcstransd(8) to offer
a socket for context translation, which is completely optional. The
reason why libselinux creates the directory is to avoid a [rogue] daemon
offering a broken translation service. (With SELinux enabled even root
daemons might not be able to write into a correctly labeled /run/setrans
thus the pre-creation helps.)"
Without detailed knowledge of SELinux, I'd be inclined to agree with
Luca's assertion that creating this directory isn't/shouldn't be the
shared library's job: the shared library gets installed on every Debian
system and into every Debian container (it's transitively Essential),
but most Debian systems don't actively use SELinux. As a result, I think
moving the tmpfiles.d snippet from libselinux1 to selinux-utils was a
good thing to do.
However, I'm not so sure that adding the Recommends as part of that
change is desirable. Luca's reasoning for why it was OK to move the
creation of /run/setrans from libselinux1 to selinux-utils, because
practical systems with SELinux will have these utilities anyway, seems
like it would be equally valid even without that Recommends?
If the system is not using the SELinux LSM (like the majority of Debian
systems) and just has libselinux pulled in as a dependency of coreutils
etc., I would tend to assume that it also doesn't benefit from
/run/setrans, and therefore doesn't need the tmpfiles.d snippet that
creates /run/setrans. Is this true?
Meanwhile, if the system *is* using a SELinux LSM, policycoreutils
already Depends on selinux-utils, and it seems like it would be
difficult to have a working SELinux system without policycoreutils,
which contains the load_policy executable, which I assume is a necessary
part of loading SELinux policies (analogous to apparmor_parser in the
AppArmor world). Is this the case, or am I misunderstanding something?
(I think the AppArmor equivalent of what I'm saying is that if AppArmor
needed a tmpfiles.d snippet, I'd expect it to be in the apparmor
package, not the libapparmor1 package; and I wouldn't expect
libapparmor1 to have a Depends, Recommends or even Suggests on
apparmor, because we expect systems that actively use AppArmor to
install the apparmor package.)
It also seems reasonable to say that if sysadmins are going to enable a
non-default OS feature instead of the one that Debian provides by
default, then those sysadmins need to install the relevant packages,
which in the case of SELinux would seem to mean at least selinux-utils,
and most likely policycoreutils and selinux-basics as well.
Thanks,
smcv
[1] https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/14
