Xref: utzoo comp.unix.wizards:25407 alt.security:2444 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!munnari.oz.au!mundamutti.cs.mu.OZ.AU!kre From: kre@cs.mu.oz.au (Robert Elz) Newsgroups: comp.unix.wizards,alt.security Subject: Re: BSD tty security, part 3: How to Fix It Message-ID: Date: 5 May 91 07:56:40 GMT References: <18924@sdcc6.ucsd.edu> <15369:May219:46:0491@kramden.acf.nyu.edu> <8993:May415:59:4491@kramden.acf.nyu.edu> Sender: news@cs.mu.oz.au Lines: 31 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 - the most common case perhaps being those progs that have a '!' or 'shell' command, to fork/exec an interactive shell, from which anything can be run. This is a much harder problem to fix - essentially it means that all progs that close(3) and allow any other prog to be exec'd need to be fixed. >The research UNIX people considered using 127, then decided >that there wasn't anything so special about stdtty and made it 3. Yes, I know - they have the luxury of fixing their entire environment. Very few others do - vendors don't, they can't fix code supplied by customers, or independant code suppliers. Breaking code that customers have written, or even worse, bought, is not something any vendor is going to want to undertake lightly. On the other hand, using fd -2 (not -1, that will cause stupid progs that attempt to reference fd's after an open error to do weird things) or 65535, or any other "unusual" number would not have these drawbacks. Its much more work for the vendors in their kernels, but at least its work that is mostly compatible with their current offerings. kre Brought to you by Super Global Mega Corp .com