Xref: utzoo comp.unix.wizards:25630 alt.security:2541
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!rutgers!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 4: What You Can Look Forward To
Message-ID: <11900:May1518:21:5491@kramden.acf.nyu.edu>
Date: 15 May 91 18:21:54 GMT
References: <721@seqp4.UUCP> <729@seqp4.UUCP> <14768@ulysses.att.com>
Organization: IR
Lines: 39

In article <14768@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes:
  [ about his session manager ]
> 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).

I have to agree with this. I find it absolutely ridiculous that so many
different programs---telnetd, rlogind, script, emacs, xterm, expect,
screen, mtty, Randal's chat2.pl, atty, etc.---are all responsible for
managing a single resource. If even one of those programs fails, the
whole system will fail. This *is* way too complex in the wrong spots.

My previous solution to this problem was pty, my generic pseudo-tty
session manager. Every single one of those programs can be modified to
use pty---script, for example, becomes a tiny (unprivileged) shell
script as included in the pty package. You can change the entire
pseudo-tty interface by just changing that one program. In this respect
pty is a lot like Bellovin's session manager (which it was partially
modelled after).

The problem is that it's hard to convince people to stop copying the
pseudo-tty allocation code from one application to the next, and to use
pty instead. If I thought people would accept this solution, then I'd
gladly reorganize my tty fixes around pty, and Bellovin's objection
would disappear. But people don't seem to understand why session
managers---either Bellovin's or mine---are so useful. So I have no
choice but to work within the existing complexity of the tty subsystem.

(Side note: Remember that telnetd/rlogind patch announced by CERT? Well,
at least under SunOS 4.0.3 and later as well as some other systems, pty
will skip a tty with ``/dev/ttyp7 unopenable: I/O error'' in the same
situations where Sun's new telnetd/rlogind will skip it. So anyone who's
been using pty since last year is already safe against ``cover''. Is
that any incentive to start using it?)

---Dan