Xref: utzoo comp.unix.wizards:25388 alt.security:2431
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!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: <kre.673345687@mundamutti.cs.mu.OZ.AU>
Date: 4 May 91 08:28:07 GMT
References: <7299:Apr2510:22:2091@kramden.acf.nyu.edu> <18924@sdcc6.ucsd.edu> <15369:May219:46:0491@kramden.acf.nyu.edu>
Sender: news@cs.mu.oz.au
Lines: 36

brnstnd@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
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.

First, there's the obvious "prog 3</dev/null" which probably isn't
worth worrying about too much (if users explicitly want to have
the prog not be able to use the controlling tty that's OK, and
possible with /dev/tty anyway).

But worse, there are zillions of progs currently that do, more or
less

	for (fd = 3; fd < ENOUGH; fd++)
		close(fd);

(where ENOUGH is calculated different ways in different progs).

All of those are going to need to be fixed to start at 4 instead
of 3, or they're all going to lose their tty access, not just
for themselves, which often won't matter much, but for all of their
decendant processes as well.

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.

kre

ps: you may just as well post the code to exploit the bugs now, if
there's anyone around who can't figure out how to do it now, they're
not likely to be able to figure out how to compile your code either...