Xref: utzoo comp.unix.wizards:25416 alt.security:2453 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.unix.wizards,alt.security Subject: Re: BSD tty security, part 3: How to Fix It Message-ID: <17916:May522:46:2091@kramden.acf.nyu.edu> Date: 5 May 91 22:46:20 GMT References: <8993:May415:59:4491@kramden.acf.nyu.edu> Organization: IR Lines: 23 In article kre@cs.mu.oz.au (Robert Elz) writes: > brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >> for (fd = 3; fd < ENOUGH; fd++) > >> close(fd); > >I pointed this out in the proposal. I also pointed out that it only > >affects programs which change fd 3 and then want to open /dev/tty > No, this is not true - it affects programs that close fd 3, then > exec any program that wants to open /dev/tty (That's the same thing; program != process.) Right, which is why Marc pointed out ksh. If you find other examples of such programs, please say so here. If you can post patches too, great! [ using descriptors other than 3 ] > Its much more work for the vendors in their kernels, but at least its > work that is mostly compatible with their current offerings. It won't be any extra work if they pick the current maximum fd and kludge getdtablesize() to subtract 1 from its answer. In any case, all that's important for security is that *some* file descriptor be used rather than the old /dev/tty driver. ---Dan