Re: Fixing a security hole in pinfo.

[Christopher Faylor <cgf at redhat dot com>]

On Thu, Sep 11, 2003 at 12:27:00AM -0400, Pierre A. Humblet wrote:
>At 12:15 AM 9/11/2003 -0400, you wrote:
>>On Thu, Sep 11, 2003 at 12:05:42AM -0400, Pierre A. Humblet wrote:
>>>The flag PID_MAP_RW is added in the few pinfo constructors
>>>that need to be write into _pinfo if it exists. 
>>>[snip]
>>>diff -u -p -r1.166 exceptions.cc
>>>--- exceptions.cc	10 Sep 2003 17:26:12 -0000	1.166
>>>+++ exceptions.cc	11 Sep 2003 03:40:57 -0000
>>>@@ -610,7 +610,7 @@ sig_handle_tty_stop (int sig)
>>>      its list of subprocesses.  */
>>>   if (my_parent_is_alive ())
>>>     {
>>>-      pinfo parent (myself->ppid);
>>>+      pinfo parent (myself->ppid, PID_MAP_RW);
>>>       if (NOTSTATE (parent, PID_NOCLDSTOP))
>>> 	sig_send (parent, SIGCHLD);
>>>     }
>>
>>The above won't need to be RW when I check in my new signal changes.
>>(Not that there won't be other inheritance type problems)
>
>Yep, I kind of suspected that, but it's still needed now.
>I count on your solution to solve the issue of seteuid'ed children.
>In fact, does your solution ever write to a remote _pinfo? 
>The PID_MAP_RW flag may have a very short life!

The parent still needs to write status flags (as in proc_subproc) in its
children processes doesn't it?  Is that an issue here?  Otherwise,
you're right.  I think that only parent processes will need to open this
read/write.  I suspect there's still a security hole there, somewhere.

cgf