Re: [PATCH] exec: Only allow a threaded init to exec from the thread_group_leader

[ebiederm@xmission.com (Eric W. Biederman)]

Andrew Morton <akpm@osdl.org> writes:

>> 408dad0f2b7067b23929866150e73b2b2f12d662
>> diff --git a/fs/exec.c b/fs/exec.c
>> index 055378d..c9d8e31 100644
>> --- a/fs/exec.c
>> +++ b/fs/exec.c
>> @@ -600,6 +600,12 @@ static int de_thread(struct task_struct 
>>  	if (thread_group_empty(current))
>>  		goto no_thread_group;
>>  
>> +	/* A threaded init must exec from it's primary thread.
>> +	 * As the init task (i.e. child_reaper) may not exit.
>> +	 */
>> +	if (!thread_group_leader(current) && (current->tgid == 1))
>> +		return -EINVAL;
>> +	
>>  	/*
>>  	 * Kill all other threads in the thread group.
>>  	 * We must hold tasklist_lock to call zap_other_threads.
>
> hmm, this just looks like overhead.  If sometime someone _does_ try to
> thread init, what will happen to them?  If it's something nice and nasty,
> they'll just whine at us and stop doing that.  Same net effect, no runtime
> cost.

So threading init will work just fine.  The only case that will blow up
is calling exec from something that is not the thread group leader.
i.e.  If tgid == 1 but pid != 1 the kernel will cause pid == 1 to exit.

I think that will trigger a kernel panic.  It might just ensure that
no more processes are re-parented to init.  And we dereference a
bad pointer we look at child_reaper.  I haven't been brave enough
to try it.

The cost is only paid if you are a threaded task and you call exec.
Normal process never take that path, so we are already off of the
fast path.

The test when all expanded out is only:

if ((current->tgid == current->pid) && (current->tgid == 1))
	return -EINVAL

So it should be relatively cheap.


If process id namespaces become a reality init stops being
terribly special, and becomes something you may have several
of running at any one time.  If one of those inits is compromised
by a hostile user I having the whole system go down so we can
avoid executing a cheap test sounds terribly wrong.  That is
why I really care.

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