linux-kernel - Re: [PATCH] exit: PR_SET_ANCHOR for marking processes as reapers for child processes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 5 Mar 2010 10:55:06 -0800
From:	Kay Sievers <kay.sievers@...y.org>
To:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Cc:	Oleg Nesterov <oleg@...hat.com>,
	Lennart Poettering <lennart@...ttering.net>,
	linux-kernel@...r.kernel.org,
	Americo Wang <xiyou.wangcong@...il.com>,
	James Morris <jmorris@...ei.org>,
	Kyle McMartin <kyle@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Michael Kerrisk <mtk.manpages@...glemail.com>,
	Roland McGrath <roland@...hat.com>
Subject: Re: [PATCH] exit: PR_SET_ANCHOR for marking processes as reapers for 
	child processes

On Thu, Mar 4, 2010 at 20:47, KOSAKI Motohiro
<kosaki.motohiro@...fujitsu.com> wrote:
>> On 02/02, Lennart Poettering wrote:
>> >
>> > This patch adds a simple flag for each process that marks it as an
>> > "anchor" process for all its children and grandchildren. If a child of
>> > such an anchor dies all its children will not be reparented to init, but
>> > instead to this anchor, escaping this anchor process is not possible. A
>> > task with this flag set hence acts is little "sub-init".
>>
>> Lennart, this patch adds a noticeable linux-only feature. I see
>> your point, but imho your idea needs the "strong" acks. I cc'ed
>> some heavyweights, if someone dislikes your idea he can nack it
>> right now.
>>
>>
>> Security. This is beyond my understanding, hopefully the cc'ed
>> experts can help.
>>
>> Should we clear ->child_anchor flags when the "sub-init" execs? Or,
>> at least, when the task changes its credentials? Probably not, but
>> dunno.
>>
>> The more problematic case is when the descendant of the "sub-init"
>> execs the setuid application. Should we allow the reparenting to
>> !/sbin/init task in this case?
>>
>> Should we clear ->pdeath_signal after reparenting to sub-init ?
>>
>> Do we need the new security_operations->task_reparent() method ?
>> Or, perhaps we can reuse ->task_wait() if we add the "parent"
>> argument?
>>
>> Something else we should think about?
>
> I think changing reparent rule is a bit risky. instead, I propse
> that exporting ANCHOR flag via /proc and ps parse it.
>
> What do you think?

No, that does not help anything, as mentioned earlier. It's not about
making 'ps' look nice, we need the signals if processes die, so we
want to be the parent of the process to keep the usual semantics.

Thanks,
Kay
--
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/