On Fri, Aug 19, 2022 at 10:45 AM Serge E. Hallyn [off-list ref] wrote:

On Thu, Aug 18, 2022 at 11:11:06AM -0400, Paul Moore wrote:

quoted

On Thu, Aug 18, 2022 at 10:05 AM Serge E. Hallyn [off-list ref] wrote:

...

quoted

quoted

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.

quoted

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.

quoted

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.

quoted

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