All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
Cc: Linux Containers
	<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH review 1/3] pidns: Outlaw thread creation after unshare(CLONE_NEWPID)
Date: Sat, 22 Dec 2012 12:16:22 -0800	[thread overview]
Message-ID: <874njddeqx.fsf@xmission.com> (raw)
In-Reply-To: <1356205160.5255.0@driftwood> (Rob Landley's message of "Sat, 22 Dec 2012 13:39:20 -0600")

Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> writes:

> On 12/21/2012 10:57:34 PM, Eric W. Biederman wrote:
>> 
>> The sequence:
>> unshare(CLONE_NEWPID)
>> clone(CLONE_THREAD|CLONE_SIGHAND|CLONE_VM)
>> 
>> Creates a new process in the new pid namespace without setting
>> pid_ns->child_reaper.  After forking this results in a NULL
>> pointer dereference.
>> 
>> Avoid this and other nonsense scenarios that can show up after
>> creating a new pid namespace with unshare by adding a new
>> check in copy_prodcess.
>> 
>> Pointed-out-by:  Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> Signed-off-by: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
>> ---
>>  kernel/fork.c |    8 ++++++++
>>  1 files changed, 8 insertions(+), 0 deletions(-)
>> 
>> diff --git a/kernel/fork.c b/kernel/fork.c
>> index a31b823..65ca6d2 100644
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> @@ -1166,6 +1166,14 @@ static struct task_struct  
>> *copy_process(unsigned long clone_flags,
>>  				current->signal->flags &  
>> SIGNAL_UNKILLABLE)
>>  		return ERR_PTR(-EINVAL);
>> 
>> +	/*
>> +	 * If the new process will be in a different pid namespace
>> +	 * don't allow the creation of threads.
>> +	 */
>> +	if ((clone_flags & (CLONE_VM|CLONE_NEWPID)) &&
>> +	    (task_active_pid_ns(current) != current->nsproxy->pid_ns))
>> +		return ERR_PTR(-EINVAL);
>> +
>
> Since the first bit will trigger if clone_flags has just CLONE_VM  
> without CLONE_NEWPID, or vice versa, I'm guessing this is a fast path  
> optimization? (Otherwise you meant (clone_flags &  
> (CLONE_VM|CLONE_NEWPID)) == CLONE_VM|CLONE_NEWPID ?)
>
> (Just trying to wrap my head around it...)

Actually I mean (clone_flags & (CLONE_THREAD | CLONE_SIGHAND | CLONE_VM | CLONE_NEWPID))
CLONE_THREAD and CLONE_SIGHAND imply CLONE_VM... and that is enfored above.

I don't mean all of those flags must be in place.

CLONE_NEWPID is an optimization in that the test is also in copy_pid_ns
but there is no point in going to all of the work to get there if we are
going to be testing for this scenario anyway.

I definitely don't mean (clone_flags & (CLONE_VM|CLONE_NEWPID)) ==
(CLONE_VM|CLONE_NEWPID)).  The task_active_pid_ns(current) !=
current->nsproxy->pid_ns case is what tests to see if the pid namespace
has already been unshared.

The sequence "unshare(CLONE_NEWPID); unshare(CLONE_NEWPID);" is nonsense
and that is what CLONE_NEWPID is about in that test.

Similary the sequence "unshare(CLONE_NEWPID); clone(CLONE_THREAD);" is
nonsense and what the CLONE_VM is the test is for.  There are also a
number of other nonsense thread like states that CLONE_VM also catches
and prevents.

Eric

WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Rob Landley <rob@landley.net>
Cc: Oleg Nesterov <oleg@redhat.com>,
	Linux Containers <containers@lists.linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH review 1/3] pidns: Outlaw thread creation after unshare(CLONE_NEWPID)
Date: Sat, 22 Dec 2012 12:16:22 -0800	[thread overview]
Message-ID: <874njddeqx.fsf@xmission.com> (raw)
In-Reply-To: <1356205160.5255.0@driftwood> (Rob Landley's message of "Sat, 22 Dec 2012 13:39:20 -0600")

Rob Landley <rob@landley.net> writes:

> On 12/21/2012 10:57:34 PM, Eric W. Biederman wrote:
>> 
>> The sequence:
>> unshare(CLONE_NEWPID)
>> clone(CLONE_THREAD|CLONE_SIGHAND|CLONE_VM)
>> 
>> Creates a new process in the new pid namespace without setting
>> pid_ns->child_reaper.  After forking this results in a NULL
>> pointer dereference.
>> 
>> Avoid this and other nonsense scenarios that can show up after
>> creating a new pid namespace with unshare by adding a new
>> check in copy_prodcess.
>> 
>> Pointed-out-by:  Oleg Nesterov <oleg@redhat.com>
>> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>> ---
>>  kernel/fork.c |    8 ++++++++
>>  1 files changed, 8 insertions(+), 0 deletions(-)
>> 
>> diff --git a/kernel/fork.c b/kernel/fork.c
>> index a31b823..65ca6d2 100644
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> @@ -1166,6 +1166,14 @@ static struct task_struct  
>> *copy_process(unsigned long clone_flags,
>>  				current->signal->flags &  
>> SIGNAL_UNKILLABLE)
>>  		return ERR_PTR(-EINVAL);
>> 
>> +	/*
>> +	 * If the new process will be in a different pid namespace
>> +	 * don't allow the creation of threads.
>> +	 */
>> +	if ((clone_flags & (CLONE_VM|CLONE_NEWPID)) &&
>> +	    (task_active_pid_ns(current) != current->nsproxy->pid_ns))
>> +		return ERR_PTR(-EINVAL);
>> +
>
> Since the first bit will trigger if clone_flags has just CLONE_VM  
> without CLONE_NEWPID, or vice versa, I'm guessing this is a fast path  
> optimization? (Otherwise you meant (clone_flags &  
> (CLONE_VM|CLONE_NEWPID)) == CLONE_VM|CLONE_NEWPID ?)
>
> (Just trying to wrap my head around it...)

Actually I mean (clone_flags & (CLONE_THREAD | CLONE_SIGHAND | CLONE_VM | CLONE_NEWPID))
CLONE_THREAD and CLONE_SIGHAND imply CLONE_VM... and that is enfored above.

I don't mean all of those flags must be in place.

CLONE_NEWPID is an optimization in that the test is also in copy_pid_ns
but there is no point in going to all of the work to get there if we are
going to be testing for this scenario anyway.

I definitely don't mean (clone_flags & (CLONE_VM|CLONE_NEWPID)) ==
(CLONE_VM|CLONE_NEWPID)).  The task_active_pid_ns(current) !=
current->nsproxy->pid_ns case is what tests to see if the pid namespace
has already been unshared.

The sequence "unshare(CLONE_NEWPID); unshare(CLONE_NEWPID);" is nonsense
and that is what CLONE_NEWPID is about in that test.

Similary the sequence "unshare(CLONE_NEWPID); clone(CLONE_THREAD);" is
nonsense and what the CLONE_VM is the test is for.  There are also a
number of other nonsense thread like states that CLONE_VM also catches
and prevents.

Eric


  reply	other threads:[~2012-12-22 20:16 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-22  4:56 [PATCH review 0/3] pid namespaces fixes Eric W. Biederman
2012-12-22  4:56 ` Eric W. Biederman
     [not found] ` <87d2y2elbi.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-22  4:57   ` [PATCH review 1/3] pidns: Outlaw thread creation after unshare(CLONE_NEWPID) Eric W. Biederman
2012-12-22  4:57     ` Eric W. Biederman
     [not found]     ` <877goaela9.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-22 19:39       ` Rob Landley
2012-12-22 19:39         ` Rob Landley
2012-12-22 20:16         ` Eric W. Biederman [this message]
2012-12-22 20:16           ` Eric W. Biederman
2012-12-22  4:58   ` [PATCH review 2/3] pidns: Stop pid allocation when init dies Eric W. Biederman
2012-12-22  4:58     ` Eric W. Biederman
     [not found]     ` <871ueiel9d.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-22 16:54       ` Oleg Nesterov
2012-12-22 16:54         ` Oleg Nesterov
     [not found]         ` <20121222165438.GA19680-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-12-22 20:31           ` Eric W. Biederman
2012-12-22 20:31             ` Eric W. Biederman
2012-12-25  8:24           ` [PATCH review 2/3 take 2] " Eric W. Biederman
2012-12-25  8:24             ` Eric W. Biederman
     [not found]             ` <87licm7d4n.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-25 16:59               ` Oleg Nesterov
2012-12-25 16:59                 ` Oleg Nesterov
2012-12-22  4:58   ` [PATCH review 3/3] proc: Allow proc_free_inum to be called from any context Eric W. Biederman
2012-12-22  4:58     ` Eric W. Biederman

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=874njddeqx.fsf@xmission.com \
    --to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.