Re: [PATCH] ptrace: being capable wrt a process requires mapped uids/gids
From: Josh Boyer
Date: Mon Jan 04 2016 - 10:04:08 EST
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.
josh
--
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/