BSD tty security, part 3: How to Fix It

[Dan Bernstein]

In article <19250 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F Haugh II) writes:
> In article <17916:May522:46:2091 at kramden.acf.nyu.edu> brnstnd at 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