On Thu, Aug 18, 2022 at 10:05 AM Serge E. Hallyn <serge@xxxxxxxxxx> wrote: > On Wed, Aug 17, 2022 at 04:24:28PM -0500, Eric W. Biederman wrote: > > 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. > > I do strongly sympathize with Eric's points. It will be very easy, once > user namespace creation has been further restricted in some distros, to > say "well see this stuff is silly" and go back to simply requiring root > to create all containers and namespaces, which is generally quite a bit > easier anywway. And then, of course, give everyone root so they can > start containers. That's assuming a lot. Many years have passed since namespaces were first introduced, and awareness of good security practices has improved, perhaps not as much as any of us would like, but to say that distros, system builders, and even users are the same as they were so many years ago is a bit of a stretch in my opinion. However, even ignoring that for a moment, do we really want to go to a place where we dictate how users compose and secure their systems? Linux "took over the world" because it offered a level of flexibility that wasn't really possible before, and it has flourished because it has kept that mentality. The Linux Kernel can be shoehorned onto most hardware that you can get your hands on these days, with driver support for most anything you can think to plug into the system. Do you want a single-user environment with no per-user separation? We can do that. Do you want a traditional DAC based system that leans heavy on ACLs and capabilities? We can do that. Do you want a container host that allows you to carve up the system with a high degree of granularity thanks to the different namespaces? We can do that. How about a system that leverages the LSM to enforce a least privilege ideal, even on the most privileged root user? We can do that too. This patchset is about giving distro, system builders, and users another choice in how they build their system. We've seen both in this patchset and in previously failed attempts that there is a definite want from a user perspective for functionality such as this, and I think it's time we deliver it in the upstream kernel so they don't have to keep patching their own systems with out-of-tree patches. > Eric and Paul, I wonder, will you - or some people you'd like to represent > you - be at plumbers in September? Should there be a BOF session there? (I > won't be there, but could join over video) I think a brainstorming session > for solutions to the above problems would be good. Regardless of if Eric or I will be at LPC, it is doubtful that all of the people who have participated in this discussion will be able to attend, and I think it's important that the users who are asking for this patchset have a chance to be heard in each forum where this is discussed. While conferences are definitely nice - I definitely missed them over the past couple of years - we can't use them as a crutch to help us reach a conclusion on this issue; we've debated much more difficult things over the mailing lists, I see no reason why this would be any different. -- paul-moore.com
