This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: problem with readonly pinfo?


Christopher Faylor wrote:

> >> Yes, I know.  That would involve a new thread or removing one potential
> >> process from the list of processes that are currently waited for in the
> >> process thread.
> >
> >I was thinking about one event in catchem (sigproc) and the same kind of
> >processing as what is done today. Don't know how compatible that is with
> >your new implementation.
> 
> That would be perfect for the old method.  I'm just blocking on a pipe now.
> If MSFT actually implemented overlapped reads for pipes this wouldn't be
> an issue.  I don't know why they limited things in this fashion.
> 
> >>>Also I wrote That doesn't solve the case of the group leader who isn't
> >>>an ancestor.
> >
> >Actually it does.  The group leader could set the same event (or
> >another event) as a child would, and set some kind of flag in its own
> >pinfo.  The process seeing the event knows who its group leader is and
> >can look up the flag in the leader pinfo.
> 
> The one things I've been trying to avoid (now that you've got me thinking
> about security) is the potential for a DOS.  The existence of an event means
> that there's the possibility for a DOS.  It's probably inavoidable though.

Agreed, I don't see any way to avoid it. However DOS attacks are near
the bottom of my worries. 
Here is another one: increase sys_mount_table_counter in the cygwin shared
by 2,000,000,000 and watch all cygwin processes go read the registry 
2000000000 times. However the attacker gets nothing.
 
> >One way or another we won't escape having something world writable and
> >having the reader/recipient decide if the message is legitimate.
> >With a pipe, is there a way for the reader to get the process id of the
> >writer, or some such?
> 
> I wish.  I was proposing that we could use a protocol where the sender
> sends process info to the reader but that opens up the possibility of
> a miscreant just sending random garbage to the pipe, leaving the reader
> to have to somehow synchronize.  Of course, that is an issue with the
> current implementation, too.  Sigh.

Except, in the current SIGCHLD implementation the parent does not have 
to believe any information received from anybody (besides that there is an
event), it goes checking for itself in the children pinfo's (which
unfortunately involves scanning).
 
> >> >I am looking at your changes in fhandler_process::fill_filebuf.
> >> >By insisting on PID_MAP_RW we will be depriving ourselves (in the future)
> >> >of the possibility of getting information that doesn't require writing.
> >>
> >> The command line passing mechanism involves sending pseudo signals.  You
> >> can't send a signal unless you've opened the pinfo region with
> >> read/write.  The winpids code first tries to open the shared region with
> >> RW and then drops back to read-only if it fails.
> >
> >Agreed. So you won't be able to get the command line if you don't have write
> >access to the pinfo, which seems sensible from a security point of view.
> >But the way the code is now (I think), fhandler_process::fill_filebuf () will
> >(eventually) fail to return things such as the UID if the pinfo isn't writable.
> >Actually I take back my suggestion. It's simpler to ask for PID_MAP_RW only when
> >fileid == PROCESS_CMDLINE
> 
> "The winpids code first tries to open the shared region with RW and then
> drops back to read-only if it fails."

I know you wrote that and I wondered why. I may be really confused but I don't
see how handler_process::fill_filebuf () uses winpids. It deals with pinfo's
directly. kill_pgrp uses winpids. You fixed both the same night (late)...

> Thanks.  This is interesting stuff, isn't it?

Much more interesting than watching TV!

Pierre


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]