Date:   Fri, 19 Aug 2022 17:10:29 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     "Serge E. Hallyn" <serge@...lyn.com>
Cc:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Frederick Lawler <fred@...udflare.com>, kpsingh@...nel.org,
        revest@...omium.org, jackmanb@...omium.org, ast@...nel.org,
        daniel@...earbox.net, andrii@...nel.org, kafai@...com,
        songliubraving@...com, yhs@...com, john.fastabend@...il.com,
        jmorris@...ei.org, stephen.smalley.work@...il.com,
        eparis@...isplace.org, shuah@...nel.org, brauner@...nel.org,
        casey@...aufler-ca.com, bpf@...r.kernel.org,
        linux-security-module@...r.kernel.org, selinux@...r.kernel.org,
        linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, kernel-team@...udflare.com,
        cgzones@...glemail.com, karl@...badwolfsecurity.com,
        tixxdz@...il.com
Subject: Re: [PATCH v5 0/4] Introduce security_create_user_ns()

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

-- 
paul-moore.com

Powered by blists - more mailing lists