BSD tty security, part 4: What You Can Look Forward To

[Steven Bellovin]

The bug, or rather, bugs, that Dan is talking about do indeed exist, in
many versions of the UNIX system.  The root problem is that access to
the user's tty is not adequately controlled.  There are a number of
manifestations of this problem; some are entirely innocent but annoying
nevertheless.  For every such manifestation, there has been an
attempted fix over the years, it seems.  Few have been notably
successful; problems (including security problems) still show up.

I won't recite here all of the issues; they're described at some length
in my paper.  (Btw, for those who are interested but haven't been able
to locate a copy of the relevant Usenix proceedings, I've made the
paper available for ftp on research.att.com, in dist/sessext.ps.Z)

This problem has been bothering me for quite a number of years; I
remember investigating it as early as 1979.  I concluded that much of
the problem was due to complexity -- it wasn't possible to revoke
access in any clean, comprehensive fashion because the necessary
information was spread out into too many different places.
Furthermore, even if I did all the work necessary -- chasing down
u.u_ttyp, looking for vagrant file descriptors pointing to a given tty,
blocking race conditions, etc. -- I realized that I'd never feel
confident that I'd found them all.  Witness vhangup() -- for all its
deficiencies, it is capable of doing much of the job, but there have
been several application patches released over the years because there
were unappreciated subtleties to the proper usage of the system call.
What was needed, then, was not just a solution, but one that was
demonstrably correct.  (By ``correct'', btw, I mean that it
accomplished my goals:  that it unconditionally revoked all prior
access to the tty.)

The other focus of my work was the hangup/DTR problem.  Many versions
of the UNIX system could experience race conditions involving hangup.
Perhaps the login shell would hang around waiting for a buggy
application to finish, or some nohup'ed application still had some fd's
open, so the close routine was never called.  Or maybe there was
another scenario -- I suspect that if all variations of the problem
were ever identified, the problem might have been solved.  But it
wasn't.  The manifestations were dead ports -- modems that didn't
answer, or network daemons that tried to talk on wedged ptys.

The two threads are tied together in hangup processing.  Apart from
getting the line properly re-enabled, the receipt of a hangup signal is
when you really have to revoke access to the tty -- that's when the
hardware or the network daemon have concluded that the connection no
longer exists.  But you can't call a close routine then -- HUP signals
occur at interrupt time, and hence without a user context.

The upshot of all that was the session manager.  I implemented it for
System V because streams and multiplexor devices provided a clean
implementation technique.  But I could have done it for 4.2bsd; I had
an implementation sketched out around 1984 or thereabouts.  I'm not
claiming that my idea is the only way to do things, or even necessarily
the best.  But its complexity is all in one place (the user-level
session manager process), and the kernel implementation was such that
it would tend to ``fail secure'', as it were.  I'm somewhat leary of
Dan's solution because I think it's too complex in the wrong spots --
it puts too much of the onus on application programs (which one would
like to have unprivileged, i.e., the script command).  Keith Muller's
generation number idea sounds intriguing, but I haven't analyzed it
fully.  In any event, it wouldn't solve the DTR problem.  John Haugh's
suggestion of a secure attention key tends to beg the point -- one can
specify one, but there's still the problem of how you implement it.
It's still hard to revoke all access to an open tty, especially given
the indirect accesses through /dev/tty.  (Obviously it can be done
without the session manager, since several vendors have done it.  I
haven't examined any of these in detail, so I don't know how reliable
their solutions are.)  I'm *not* prepared to offer my own retrofit
solution at this time.


		--Steve Bellovin