Paul Moore [off-list ref] writes:

On Wed, Aug 17, 2022 at 4:56 PM Eric W. Biederman [off-list ref] wrote:

quoted

Paul Moore [off-list ref] writes:

quoted

On Wed, Aug 17, 2022 at 3:58 PM Eric W. Biederman [off-list ref] wrote:

quoted

Paul Moore [off-list ref] writes:

quoted

At the end of the v4 patchset I suggested merging this into lsm/next
so it could get a full -rc cycle in linux-next, assuming no issues
were uncovered during testing

What in the world can be uncovered in linux-next for code that has no in
tree users.

The patchset provides both BPF LSM and SELinux implementations of the
hooks along with a BPF LSM test under tools/testing/selftests/bpf/.
If no one beats me to it, I plan to work on adding a test to the
selinux-testsuite as soon as I'm done dealing with other urgent
LSM/SELinux issues (io_uring CMD passthrough, SCTP problems, etc.); I
run these tests multiple times a week (multiple times a day sometimes)
against the -rcX kernels with the lsm/next, selinux/next, and
audit/next branches applied on top.  I know others do similar things.

A layer of hooks that leaves all of the logic to userspace is not an
in-tree user for purposes of understanding the logic of the code.

The BPF LSM selftests which are part of this patchset live in-tree.
The SELinux hook implementation is completely in-tree with the
subject/verb/object relationship clearly described by the code itself.
After all, the selinux_userns_create() function consists of only two
lines, one of which is an assignment.  Yes, it is true that the
SELinux policy lives outside the kernel, but that is because there is
no singular SELinux policy for everyone.  From a practical
perspective, the SELinux policy is really just a configuration file
used to setup the kernel at runtime; it is not significantly different
than an iptables script, /etc/sysctl.conf, or any of the other myriad
of configuration files used to configure the kernel during boot.

I object to adding the new system configuration knob.

Especially when I don't see people explaining why such a knob is a good
idea.  What is userspace going to do with this new feature that makes it
worth maintaining in the kernel?

That is always the conversation we have when adding new features, and
that is exactly the conversation that has not happened here.

Adding a layer of indirection should not exempt a new feature from
needing to justify itself.

Eric