Paul Moore <paul@xxxxxxxxxxxxxx> writes: > On Wed, Aug 17, 2022 at 4:56 PM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: >> Paul Moore <paul@xxxxxxxxxxxxxx> writes: >> > On Wed, Aug 17, 2022 at 3:58 PM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: >> >> Paul Moore <paul@xxxxxxxxxxxxxx> writes: >> >> >> >> > 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
