On Fri, Aug 19, 2022 at 10:45 AM Serge E. Hallyn <serge@xxxxxxxxxx> 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@xxxxxxxxxx> 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. -- paul-moore.com
