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