[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120311182007.GA5601@redhat.com>
Date: Sun, 11 Mar 2012 19:20:07 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Solar Designer <solar@...nwall.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Djalal Harouni <tixxdz@...ndz.org>,
linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com,
Andrew Morton <akpm@...ux-foundation.org>,
Al Viro <viro@...iv.linux.org.uk>,
Alexey Dobriyan <adobriyan@...il.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Vasiliy Kulikov <segoon@...nwall.com>,
Kees Cook <keescook@...omium.org>,
WANG Cong <xiyou.wangcong@...il.com>,
James Morris <james.l.morris@...cle.com>,
linux-security-module@...r.kernel.org,
linux-fsdevel@...r.kernel.org, Alan Cox <alan@...rguk.ukuu.org.uk>,
Greg KH <gregkh@...uxfoundation.org>,
Ingo Molnar <mingo@...e.hu>, Stephen Wilson <wilsons@...rt.ca>,
"Jason A. Donenfeld" <Jason@...c4.com>
Subject: Re: exec_id protection from bad child exit signals (was: Re:
[PATCH 0/9] proc: protect /proc/<pid>/* files across execve)
On 03/11, Solar Designer wrote:
>
> Actually, the original/historical purpose of the exec_id stuff was to
> protect privileged parent processes (those having done a SUID/SGID exec)
> from non-standard child exit signals, which could be set with clone().
> I think we may want to audit the current implementation and see if it
> still fully achieves the goal or maybe not (and fix it if not).
Funny that, I noticed this message only after I sent the question about
the current exec_id stuff.
> I include below pieces of the prototype implementation from
> linux-2.2.12-ow6.tar.gz released in 1999.
Perhaps I missed something, but ignoring the "cap_raised" issues, this
all is very simple. de_thread() should simply do:
current->exit_signal = SIGCHLD;
read_lock(&tasklist_lock);
list_for_each_entry(p, ¤t->children, sibling)
p->exit_signal = SIGCHILD;
read_unlock(&tasklist_lock);
The only problem is CLONE_PARENT.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists