Xref: utzoo comp.unix.wizards:25435 alt.security:2471 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!princeton!njin!uupsi!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: <29117:May621:05:1391@kramden.acf.nyu.edu> Date: 6 May 91 21:05:13 GMT References: <17916:May522:46:2091@kramden.acf.nyu.edu> <19250@rpp386.cactus.org> Organization: IR Lines: 24 In article <19250@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > In article <17916:May522:46:2091@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >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. > Naw, this is still more than you have to do. What happens if I move > u.u_ttyd from the u-page to the process table? Yeah, I think you can make vhangup() chop /dev/tty without races if you change u_ttyd to p_ttyd throughout, fix all your process-status programs so that they don't crash with this change, and add some lines inside the vhangup() syscall. That doesn't do anything about current operations. > How about fixing that problem instead of creating another > hack? ``Creating another hack''? Sheesh. The entire idea of having a separate tty security mechanism is a hack. /dev/tty represents an alternate method of file access, and as such makes security a whole lot more complicated than when there was only open(). That's the problem that /dev/stdtty fixes. ---Dan