[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171106150302.GA26634@mail.hallyn.com>
Date: Mon, 6 Nov 2017 09:03:02 -0600
From: "Serge E. Hallyn" <serge@...lyn.com>
To: Mahesh Bandewar (महेश बंडेवार) <maheshb@...gle.com>
Cc: "Serge E. Hallyn" <serge@...lyn.com>,
Mahesh Bandewar <mahesh@...dewar.net>,
LKML <linux-kernel@...r.kernel.org>,
Netdev <netdev@...r.kernel.org>,
Kernel-hardening <kernel-hardening@...ts.openwall.com>,
Linux API <linux-api@...r.kernel.org>,
Kees Cook <keescook@...omium.org>,
"Eric W . Biederman" <ebiederm@...ssion.com>,
Eric Dumazet <edumazet@...gle.com>,
David Miller <davem@...emloft.net>
Subject: Re: [PATCH resend 2/2] userns: control capabilities of some user
namespaces
Quoting Mahesh Bandewar (महेश बंडेवार) (maheshb@...gle.com):
> On Sat, Nov 4, 2017 at 4:53 PM, Serge E. Hallyn <serge@...lyn.com> wrote:
> >
> > Quoting Mahesh Bandewar (mahesh@...dewar.net):
> > > Init-user-ns is always uncontrolled and a process that has SYS_ADMIN
> > > that belongs to uncontrolled user-ns can create another (child) user-
> > > namespace that is uncontrolled. Any other process (that either does
> > > not have SYS_ADMIN or belongs to a controlled user-ns) can only
> > > create a user-ns that is controlled.
> >
> > That's a huge change though. It means that any system that previously
> > used unprivileged containers will need new privileged code (which always
> > risks more privilege leaks through the new code) to re-enable what was
> > possible without privilege before. That's a regression.
> >
> I wouldn't call it a regression since the existing behavior is
> preserved as it is if the default-mask is not altered. i.e.
> uncontrolled process can create user-ns and have full control inside
> that user-ns. The only difference is - as an example if 'something'
> comes up which makes a specific capability expose ring-0, so admin can
> quickly remove the capability in question from the mask, so that no
> untrusted code can exploit that capability until either the kernel is
Oh, sorry, I misread then, and missed that step. I thought the default
with this patchset was that there were no capabilities exposed to user
namespaces.
> patched or workloads are sanitized keeping in mind what was
> discovered. (I have given some real life example vulnerabilities
> published recently about CAP_NET_RAW in the cover letter)
>
> > I'm very much interested in what you want to do, But it seems like
> > it would be worth starting with some automated code analysis that shows
> > exactly what code becomes accessible to unprivileged users with user
> > namespaces which was accessible to unprivileged users before. Then we
> > can reason about classifying that code and perhaps limiting access to
> > some of it.
> I would like to look at this as 'a tool' that is available to admins
> who can quickly take possible-compromise-situation under-control
> probably at the cost of some functionality-loss until kernel is
> patched and the mask is restored to default value.
The thing that makes me hesitate with this set is that it is a
permanent new feature to address what (I hope) is a temporary
problem. What would you think about doing this as a stackable
(yama-style) LSM?
> I'm not sure if automated tools could discover anything since these
> changes should not alter behavior in any way.
Seems like there are two naive ways to do it, the first being to just
look at all code under ns_capable() plus code called from there. It
seems like looking at the result of that could be fruitful.
-serge
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
