On Fri, Aug 19, 2022 at 10:45 AM Serge E. Hallyn serge@hallyn.com wrote:
On Thu, Aug 18, 2022 at 11:11:06AM -0400, Paul Moore wrote:
On Thu, Aug 18, 2022 at 10:05 AM Serge E. Hallyn serge@hallyn.com wrote:
...
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.
Maybe. But I do get a bit worried based on some of what I've been reading in mailing lists lately. Kernel dev definitely moves like fashion - remember when every api should have its own filesystem? That was not a different group of people.
I'm not going to argue against the idea that kernel development is subject to fads, I just don't agree that adding a LSM control point for user namespace creation is going to be the end of user namespaces.
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
Oh, you misunderstand. Whereas I do feel there are important concerns in Eric's objections, and whereas I don't feel this set sufficiently addresses the problems that I see and outlined above, I do see value in this set, and was not aiming to deter it. We need better ways to mitigate a certain clas sof 0-days without completely disallowing use of user namespaces, and this may help.
Ah, thanks for the explanation, I missed that (obviously) in your previous email. If I'm perfectly honest, I suppose the protracted debate with Eric has also left me a little overly sensitive to any perceived arguments against this patchset.
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
No I wasn't thinking we would use LPC to decide on this patchset. As far as I can see, the patchset is merged.
While I maintain that Frederick's patches are a good thing, I'm not going to consider them "merged" until I see them in Linus' tree or Linus decided to voice his support on the lists. These patches do have Eric's NACK, and a maintainer's NACK isn't something to take lightly. I certainly don't.
I am hoping we can come up with "something better" to address people's needs, make everyone happy, and bring forth world peace. Which would stack just fine with what's here for defense in depth.
You may well not be interested in further work, and that's fine. I need to set aside a few days to think on this.
I'm happy to continue the discussion as long as it's constructive; I think we all are. My gut feeling is that Frederick's approach falls closest to the sweet spot of "workable without being overly offensive" (*cough*), but if you've got an additional approach in mind, or an alternative approach that solves the same use case problems, I think we'd all love to hear about it.