[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAF2d9jjeRv_=kxsOuntA-R5hNhQ9fR=AK5Jxv+Chzh1vMR4B=Q@mail.gmail.com>
Date: Thu, 8 Mar 2018 21:19:03 -0800
From: Mahesh Bandewar (महेश बंडेवार) <maheshb@...gle.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: James Morris <jmorris@...ei.org>, Eric Dumazet <edumazet@...gle.com>,
"Serge E. Hallyn" <serge@...lyn.com>, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCHv4 0/2] capability controlled user-namespaces
On Thu, Mar 8, 2018 at 3:46 PM, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> "Mahesh Bandewar (महेश बंडेवार)" <maheshb@...gle.com> writes:
>
>> On Thu, Mar 8, 2018 at 2:52 PM, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>>> James Morris <jmorris@...ei.org> writes:
>>>
>>>> Perhaps try a repost upstream for possible merging to 4.16.
>>>
>>> I have a real concern that capability controlled user namespaces
>>> are only good for CAP_NET_RAW and CAP_NET_ADMIN. They don't appear
>>> general.
>>>
>> NET_RAW and NET_ADMIN threats are real and demonstrated and hence it's
>> easy to show this patch-set to handle them well.
>>
>>> I think this should be discussed on the linux hardening mailing list.
>>> As that is what we are really talking about something to reduce the
>>> attack surface of the kernel. Possibly after it has shipped.
>>> In some well defined way.
>>>
>> This patch-set has been posted to linux-hardening mailing list since
>> initial RFC series.
>
> When I looked this thread was not. Hmm. It looks like this thread had
> become completely private. Sigh.
>
>>> That feels to me like a project for profiling tools, and some bpf programs
>>> that attach to functions and call permissions.
>>>
>>> Either that or something like my count of maximum number of namespaces.
>>> Which appears to be just as usable as capability controlled user
>>> namespaces.
>>>
>> maximum number of namespaces is similar to the distros adding a sysctl
>> to disallow creating user-namespace and does not solve the problem nor
>> it's usable if the use case involves creating user-namespaces.
>
> If the namespace you are limiting creating is the network namespace it
> has nearly the same efficacy and we already have that knob in the kernel
> and we need it for several reasons.
>
It may be useful for other use cases and that's fine but doesn't solve
the problem that I'm trying to address. Again in my use case I cannot
restrict creating any namespace. All I can say is, what they cannot
do.
>>> I am very sympathetic but this does not appear to be a general solution
>>> to a general problem. The general problem being how to reduce the
>>> attack surface of the kernel.
>>>
>> Now let's say there is vulnerability discovered in CAP_DAC_OVERRIDE,
>> why do think this patch-set is not general enough to handle that? The
>> point is that at this moment there is no mechanism that allows me to
>> create a sandbox in a true sense. This patch-set allows you to do
>> that.
>
> I don't think the same amount of code is behind the other capablities
> which drastically alters the efficacy of something like this when
> considered in such a context.
>
I don't think what is or how much code behind each capability but it's
the same mechanism that allows or disallows in a sandboxed or
controlled environment.
>>> Especially when the end goal is fixing the relevant kernel code and
>>> removing the restrictions I don't see why a weird kernel patch with
>>> oddball semantics can help.
>>>
>> I'm not fixated on *this only* solution but don't want a solution that
>> restricts creating user-namespaces since my use-cases involve creating
>> user-namespaces with "lesser" privileges. The patch-set has been
>> posted for more than 6 months and problem is known for some time now
>> unfortunately I haven't seen any other solution that does not involve
>> blocking user-namespace creation.
>
> I don't recall poposing a solution that limits creating user-namespaces.
> Certainly I have proposed other kinds of solutions.
>
> I offered sketches for several other solutions. Including the one above
> about using the tracing/debugging framework to inject additional
> permission checks into the code at run-time.
>
> There is a real danger in the direction you are walking. Having a
> mentality that is reactive and adding restrictions after the fact has
> the very real danger of breaking applications when those restrictions
> are imposed.
>
I think you got it wrong. It doesn't have to be reactive! Well, one
could be reactive also, but in my environment I know what are the
dangerous set of actions that I wouldn't allow and would set the
environment preemptively right from day one while keeping the
flexibility of extending if something else is discovered. The default
mask I have proposed is for the backward compatibility so that no
existing system should break. The admin in every deployment is in the
position to decide what is the best default-mask that suits his/her
environment. This is a tool that can be turned on or off based on the
need.
> The only way I know to avoid breaking things is to have preemptive
> sandboxing that tightly limits what applications can do. Perhaps
> something like sandstorm.io. That preemptive sandbox let's you say.
> Wasn't it nice that we don't allow that code path so patching is less of
> a priority.
>
> Past that you have to balance between what you might break and what you
> are what problems you are going to avoid by disallowing things after the
> fact.
>
> I have a little time but I don't think I will have much time for a
> general design discussion until after 4.16 is out.
>
> So far to me, capability controlled user namespaces look like a nasty
> adhoc feature that one person will use, and not much. That however will
> need to be maintained in perpetuity. As such I think it is quite
> reasonable to drag my feet, and ask is there something better and/or
> more general that we can do.
>
sure, but until then we are all exposed and we don't know when the
next obscure vulnerability will be discovered. I just wish that
user-namespaces didn't happen because now we (kernel developers) are
torn between applications trying to use them in interesting ways and
security people trying to stop them from using it and I see this
happening in perpetuity.
> Eric
>
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.
