Re: [PATCH] ptrace: being capable wrt a process requires mapped uids/gids

[Eric W. Biederman]

Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes:

> On Tue, Jan 5, 2016 at 5:17 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:
>> Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> writes:
>>
>>> On Sat, Dec 26, 2015 at 9:03 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>>>> On Sat, Dec 26, 2015 at 1:51 PM, Serge E. Hallyn
>>>> <serge.hallyn@xxxxxxxxxx> wrote:
>>>>> On Sat, Dec 26, 2015 at 03:52:31AM +0100, Jann Horn wrote:
>>>>>> ptrace_has_cap() checks whether the current process should be
>>>>>> treated as having a certain capability for ptrace checks
>>>>>> against another process. Until now, this was equivalent to
>>>>>> has_ns_capability(current, target_ns, CAP_SYS_PTRACE).
>>>>>>
>>>>>> However, if a root-owned process wants to enter a user
>>>>>> namespace for some reason without knowing who owns it and
>>>>>> therefore can't change to the namespace owner's uid and gid
>>>>>> before entering, as soon as it has entered the namespace,
>>>>>> the namespace owner can attach to it via ptrace and thereby
>>>>>> gain access to its uid and gid.
>>>>>>
>>>>>> While it is possible for the entering process to switch to
>>>>>> the uid of a claimed namespace owner before entering,
>>>>>> causing the attempt to enter to fail if the claimed uid is
>>>>>> wrong, this doesn't solve the problem of determining an
>>>>>> appropriate gid.
>>>>>>
>>>>>> With this change, the entering process can first enter the
>>>>>> namespace and then safely inspect the namespace's
>>>>>> properties, e.g. through /proc/self/{uid_map,gid_map},
>>>>>> assuming that the namespace owner doesn't have access to
>>>>>> uid 0.
>>>>>>
>>>>>> Changed in v2: The caller needs to be capable in the
>>>>>> namespace into which tcred's uids/gids can be mapped.
>>>>>>
>>>>>> Signed-off-by: Jann Horn <jann@xxxxxxxxx>
>>>>>
>>>>> Acked-by: Serge Hallyn <serge.hallyn@xxxxxxxxxx>
>>>>
>>>> Acked-by: Andy Lutomirski <luto@xxxxxxxxxx>
>>>>
>>>> Who's going to apply this?  Linus?  Eric?
>>>
>>> An Ack from Oleg would be nice too.  I'm guessing this got lost in the
>>> holidays but it has an assigned CVE now.  Would be good to get it in
>>> 4.4 final.
>>
>> If people are going to go around and refuse to understand the problem
>> and assign CVEs to the kernel when they can't understand what is
>> necessary to safely write code I am inclined to nack the entire mess.
>>
>> Whatever (if anything) that is calling setns in this problematic way is
>> the problem today.
>>
>
> Even if we were to grant that the setns caller is buggy, this patch
> seems like a good hardening measure.  Is there any case where ptrace
> access *should* be granted but would not be granted with this patch
> applied?

Honestly I rather like the direction of this patch.

This patch seems to be upholding the old princimple that you are not
allowed to trace a process that has security relevant resources you
could not access any other way.  In this case uids.


As for the question of does this break userspace.  The only preexisting
case that this even comes close to is ptracing user mode helpers.  All
of the existing ptrace hardening in yama actually blocks this case
because the of the disjoint process tree.  So I don't think we are going
to break userspace by changing behavior here.

I can see a strong argument for wanting ptrace to work from this process
to other processes in the user namespace.  Because setns/nsenter is what
you use when you want to debug what is wrong in a container.


That said I don't think it will ever be easy, to write safe code, that
places a process into a user namespace with a hostile user namespace
root.  We can certainly help by tweaking a few things but it won't be
easy.  In writing a process that cass setns and enters a potentially
hostile user namespace you have to be aware of what resource your
process is holding onto and have to carefully drop them.

In this case I am wondering if it might be smart to also consider
setting dumpable (or some version of dumpable) when we call setns and
enter a user namespace.

>> This thread is about a feature request to make it easier to write secure
>> code not about a vulnerability in user namespaces.
>
> So what?

Viewing this as a vulnerability in user namespaces is problematic
because it encourages people to write buggy code.  Plus I get people
asking me what is going on with CVExyz.  So I am answering them there is
no kernel bug here.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/