archive mirror
 help / color / mirror / Atom feed
From: (Eric W. Biederman)
To: Andy Lutomirski <>
Cc: Josh Boyer <>,
	"Serge E. Hallyn" <>,
	Jann Horn <>, Roland McGrath <>,
	Oleg Nesterov <>,
	"linux-kernel\" <>,
	"security\" <>,
	Serge Hallyn <>,
	Linus Torvalds <>
Subject: Re: [PATCH] ptrace: being capable wrt a process requires mapped uids/gids
Date: Tue, 05 Jan 2016 20:04:29 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Andy Lutomirski's message of "Tue, 5 Jan 2016 17:36:33 -0800")

Andy Lutomirski <> writes:

> On Tue, Jan 5, 2016 at 5:17 PM, Eric W. Biederman <> wrote:
>> Josh Boyer <> writes:
>>> On Sat, Dec 26, 2015 at 9:03 PM, Andy Lutomirski <> wrote:
>>>> On Sat, Dec 26, 2015 at 1:51 PM, Serge E. Hallyn
>>>> <> 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 <>
>>>>> Acked-by: Serge Hallyn <>
>>>> Acked-by: Andy Lutomirski <>
>>>> 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.


  reply	other threads:[~2016-01-06  2:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-12 20:12 [PATCH] ptrace: being capable wrt a process requires mapped uids/gids Jann Horn
2015-12-15  0:26 ` Andy Lutomirski
2015-12-17 18:59 ` Serge E. Hallyn
2015-12-26  1:10 ` Jann Horn
2015-12-26  2:52   ` Jann Horn
2015-12-26 21:17     ` Serge E. Hallyn
2015-12-26 21:27       ` Jann Horn
2015-12-26 21:49         ` Serge E. Hallyn
2015-12-26 21:51     ` Serge E. Hallyn
2015-12-27  2:03       ` Andy Lutomirski
2016-01-04 15:03         ` Josh Boyer
2016-01-06  1:17           ` Eric W. Biederman
2016-01-06  1:36             ` Andy Lutomirski
2016-01-06  2:04               ` Eric W. Biederman [this message]
2015-12-26 20:23   ` Serge E. Hallyn
2015-12-26 20:55     ` Jann Horn
2015-12-26 21:08       ` Serge E. Hallyn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).