On Tue, Jan 5, 2016 at 5:17 PM, Eric W. Biederman <[email protected]> wrote: > Josh Boyer <[email protected]> writes: > >> On Sat, Dec 26, 2015 at 9:03 PM, Andy Lutomirski <[email protected]> wrote: >>> On Sat, Dec 26, 2015 at 1:51 PM, Serge E. Hallyn >>> <[email protected]> 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 <[email protected]> >>>> >>>> Acked-by: Serge Hallyn <[email protected]> >>> >>> Acked-by: Andy Lutomirski <[email protected]> >>> >>> 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? > This thread is about a feature request to make it easier to write secure > code not about a vulnerability in user namespaces. So what? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
