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

The package selinux-utils is depended on by selinux-policy-default, so it will
be dragged in by every functional SE Linux system and shouldn't need anything
else.  When SE Linux is disabled there shouldn't be a case where mcstrans is
looked up.

Thw case of "security=selinux" on the kernel command line with no policy
installed is not suppprted.

I suggest removing that depends.

On https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/14,
Adrian argued that "On an embedded system one does often provision
policy through other means" (presumably meaning that such systems would
not necessarily have selinux-policy-default installed). Is that a
use-case that is supported by the SE Linux team in Debian?

If yes, is there a package that is smaller than selinux-policy-default,
but *does* need to be pulled in by every functional SE Linux system? I'm
hoping that one of selinux-basics, policycoreutils or selinux-utils has
that role.

If all working SE Linux systems will have one of those packages, then
the same reasoning says that the Recommends isn't necessary.

     smcv

That's not something we support in Debian.  For almost everything in Debian
someone could theoretically install their own non-packaged replacement to save
some space and we would give them the freedom to do so on their own without
compromising our work.

I am happy to make things easier for people who want a Frankenstein system,
but not if that means making things worse for people who do things the
recommended way.

The selinux-basics and policycoreutils packages have depended on selinux-utils
for a long time.  The selinux-basics package is a convenience package that
could be skipped if someone wants to keep things small, but policycoreutils is
really needed for any SE Linux system.

Yes.

  > "Using selinux means instealling policy, admin tools, etc."

  "On an embedded system one does often provision policy through other
   means and does not install admin tools."

The problem with abstract broad claims like what Luca did is that they
are not true in all cases, e.g. there might be no need for checkpolicy
on a target.

IMHO the reasoning that what is effectively a mkdir in libselinux1 would
be a problem is not convincing, my argument in #1141909 is that tmpfiles
is functionality that should be (and de facto basically already is) in
the essential set.
Adrian

BTW: I wonder why selinux_compile_fcontexts is in libselinux1 and not in
     selinux-utils, but that's also not something that is a problem.