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

> Security. This is beyond my understanding, hopefully the cc'ed
> experts can help.

There are a few different aspects of behavior change to think about.

1. Who can get a SIGCHLD and wait result they weren't expecting.
2. Who sees some PID for getppid() when they are expecting 1.
3. What ps shows.

When I start thinking through what might be security issues, they are
almost all #1 questions.  There is a hairy nest of many variations of #1
questions.  The #2 question is pretty simple, but it also could be an issue
for security when setuid is involved (or just correctness for any
application).

My impression is that #3 is the only actual motivation for this feature.
So perhaps we should consider an approach that leaves the rest of the
semantics alone and only affects that.

Lennart, am I right that this is all you are looking for?  Does it even
matter to you that this change the PPID that ps groks today?  How about if
it's just an entirely new kind of assocation that ps et al can learn to
display, and not even the traditional PPID field changes?

> To me, it looks more natural if PR_SET_ANCHOR marks the whole process as
> a local reaper, not only the thread which called PR_SET_ANCHOR.

Agreed.  It could probably be a bit in signal_struct.flags,
which also means no memory cost for adding the feature.


Thanks,
Roland
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ