BSD tty security, part 3: How to Fix It

[Dan Bernstein]

In article <kre.673345687 at mundamutti.cs.mu.OZ.AU> kre at cs.mu.oz.au (Robert Elz) writes:
> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
> >--far more than required to implement
> >/dev/fd/3 (to replace /dev/tty) or TIOCOPENCT.
> The problem with using /dev/fd/3 and using that instead of /dev/tty

Let me note that I addressed these issues fully in the original
proposal. I would love to hear from someone who can come up with (and
write out) a simpler solution to the /dev/tty problem.

> is that you lose the ability to guarantee to be able to open the
> terminal where your user is sitting, assuming that there is one.

But that guarantee was never there. If you set TIOCEXCL on your tty
under most BSD-derived systems, you won't be able to open /dev/tty
either.

In fact, that's a good way to see how many programs depend on /dev/tty.
Try it. You'll be surprised at the results.

> But worse, there are zillions of progs currently that do, more or
> less
> 	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 (or
really old programs that assume the first open() will return 3). Most of
the programs that close all descriptors also want to stay in the
background, or are already dissociated from the ctty, or simply don't
care about the tty.

As I also pointed out in the proposal, the most important example of
such a program is ksh, which isn't installed on most BSD machines and is
also easily fixed. The other big class is scripts which might redirect
fd 3 somewhere and then want to use /dev/tty; as I also pointed out in
the proposal, you can solve this by using fd 11 instead of fd 3.

If anyone has actual examples of programs that redirect fd 3 and then
use /dev/tty, I expect that he'll do the sensible thing and post the
necessary fixes to the net, so as to save work on everyone else's part.

> The one big advantage of /dev/ttyd (u.u_ttyd) is that its very difficult
> to accidentally give it away, you really have to try very very hard
> to do it.

(One might ask whether this is the ``right'' situation---should it be
``very very hard'' to redirect stdin or stdout or stderr? Do you think
that the file descriptor model somehow isn't adequate for cttys?)

I addressed this in the proposal, notably with the fd 11 suggestion.
Steve Bellovin says that file descriptor -1 would preserve backwards
compatibility. Unfortunately, it would also require changes throughout
the kernel. The research UNIX people considered using 127, then decided
that there wasn't anything so special about stdtty and made it 3.

---Dan