On Thu, Aug 25, 2022 at 01:15:46PM -0500, Eric W. Biederman wrote:

Paul Moore [off-list ref] writes:

quoted

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

quoted

 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.

I would love to actually hear the problems people are trying to solve so
that we can have a sensible conversation about the trade offs.

As best I can tell without more information people want to use
the creation of a user namespace as a signal that the code is
attempting an exploit.

I don't think that's it at all.  I think the problem is that it seems
you can pretty reliably get a root shell at some point in the future
by creating a user namespace, leaving it open for a bit, and waiting
for a new announcement of the latest netfilter or whatever exploit
that requires root in a user namespace.  Then go back to your userns
shell and run the exploit.

So i was hoping we could do something more targeted.  Be it splitting
off the ability to run code under capable_ns code from uid mapping (to
an extent), or maybe some limited-livepatch type of thing where
certain parts of code become inaccessible to code in a non-init userns
after some sysctl has been toggled, or something cooloer that I've
failed to think of.

-serge