Re: [Patch]: shared.cc debug info.
Christopher Faylor wrote: > > On Mon, Oct 06, 2003 at 09:26:12PM -0400, Pierre A. Humblet wrote: > >Here is a pretty simple patch.. > > Ok to include. > > >BTW, are there more questions about "[Patch]: Fixing the PROCESS_DUP_HANDLE > >security hole (part 1)." from last week? > > Yes, actually. I am still puzzling over all of the extra logic that you > pass in cygheap. I don't understand the need for special handling of > children of the process that owns the controlling tty. A typical sequence is as follows (e.g. telnet) 1) inetd runs as SYSTEM, launches in.telnetd 2) in.telnetd creates master pty and forks 3) in.telnetd (child) setsid(), opens slave terminal and execs login.exe 4) login.exe calls setuid and execs bash.exe 5) bash.exe opens /dev/tty Unfortunately this requires duplicating pipes from in.telnetd and thus having PROCESS_DUP_HANDLE access to in.telnetd. As in.telnetd runs as SYSTEM, this is a security risk. What the patch does is that when the slave side is first opened in 3), the pipes are duplicated in the cygheap and passed by inheritance (until the ctty changes). There is no access/security issue because 3) is running as SYSTEM. >From now on, each time the ctty is opened (in particular in 5) the patch first checks if local inherited copies of the pipes are available. If so, they are used as the source of the duplication. This obviates the need for bash to have any access to in.telnetd and thus in.telnetd doesn't need to open itself wide to everybody (in 2). Pierre
Re: [Patch]: shared.cc debug info.
On Mon, Oct 06, 2003 at 09:26:12PM -0400, Pierre A. Humblet wrote: >Here is a pretty simple patch.. Ok to include. >BTW, are there more questions about "[Patch]: Fixing the PROCESS_DUP_HANDLE >security hole (part 1)." from last week? Yes, actually. I am still puzzling over all of the extra logic that you pass in cygheap. I don't understand the need for special handling of children of the process that owns the controlling tty. However, I haven't had time to look at this in any great detail since I'm pursuing my own cygwin interests at the moment, when my real job doesn't interfere. Although in this case, I'm actually doing cygwin work for Red Hat but it's not my real job, but there is still potential revenue associated with it, but... cgf
[Patch]: shared.cc debug info.
Here is a pretty simple patch.. BTW, are there more questions about "[Patch]: Fixing the PROCESS_DUP_HANDLE security hole (part 1)." from last week? Pierre 2003-10-06 Pierre Humblet <[EMAIL PROTECTED]> * shared.cc (open_shared): Report map name in api_fatal. Index: shared.cc === RCS file: /cvs/src/src/winsup/cygwin/shared.cc,v retrieving revision 1.75 diff -u -p -r1.75 shared.cc --- shared.cc 25 Sep 2003 02:29:04 - 1.75 +++ shared.cc 7 Oct 2003 01:02:30 - @@ -99,7 +99,7 @@ open_shared (const char *name, int n, HA if (!shared_h && !(shared_h = CreateFileMapping (INVALID_HANDLE_VALUE, psa, PAGE_READWRITE, 0, size, mapname))) - api_fatal ("CreateFileMapping, %E. Terminating."); + api_fatal ("CreateFileMapping %s, %E. Terminating.", mapname); } shared = (shared_info *)