Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!sdd.hp.com!think.com!paperboy!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.wizards
Subject: Re: BSD tty security
Message-ID: <27517:May808:02:2091@kramden.acf.nyu.edu>
Date: 8 May 91 08:02:20 GMT
References: <26758@adm.brl.mil>
Organization: IR
Lines: 57

In article <26758@adm.brl.mil> marco@email.ncsc.navy.mil (Barbarisi) writes:
>      rm /bin/write

Another plausible idea along the same lines is to rm -rf / ...

I just put together a simple backwards-compatible write system
synchronizing through BSD's UNIX-domain sockets rather than through
ttys. There's a privileged server and a privileged client to set up
secure communication, but everything else---how write looks for ttys,
writing itself, the write daemon that produces output---is under user
control. Expert users can freely substitute their own write, ucommwrite,
and ucommwrited front-ends and back-ends, so the Multics hands should be
satisfied.

In the package I have a patch to 4.3 ntalk to send messages through
write rather than the tty; a ``biffmail'' that you can stick in .forward
instead of depending on comsat/biff; simple clones of mesg and write. To
address Jef's disgust for new features, I made sure that you could
retain backwards compatibility by setting a few environment variables.
The new mesg n does not turn off writes in progress, but as any write to
a user involves a process run by that user, appropriate kills will turn
off writes.

I do not know if these changes cover all the cases in which user
applications need ttys to be in the filesystem. If they do, then a
vendor could solve the tty security problems (though not the
denial-of-service attacks) by simply making /dev/tty* exclusive-open
like /dev/pty*. (The denial-of-service problem would be a lot less
important if more applications did random pseudo-tty searching like pty.
It can only really be solved, though, by protecting the files and making
a user pay one process or utmp entry per tty wasted.) This is really
easy to implement---it's almost like a permanent TIOCEXCL, which does
apply to /dev/tty btw---but would require some work in each
tty-allocating program.

Back to write: Any volunteer beta testers? Please don't respond just
because you're trying to find a better mousetrap or tighten up security.
The package will be available soon enough. What I'm looking for are
people who have some experience with various message systems, may want
to contribute extra front ends or back ends, know exactly what
compatibility users depend on, and can test the code on different BSD
machines. I'm also looking for a brave soul to do a System V port, but
this isn't immediately necessary (I do have some fifo-based
client-server stuff lying around somewhere).

> There is also an alternative to "write" called "talk", which appears to
> be far less susceptable to abuse.  I believe it comes with modern
> flavors of BSD.  

talk is, in fact, completely insecure. (Doesn't ``hunt'' forge talk
messages to everyone on a mailing list?) You can make BSD 4.3 ntalk
support RFC 931 with the patches in pub/hier/inet/rfc931/talk* on
stealth.acf.nyu.edu, but that only gives you authenticated usernames if
the other side of the connection has an RFC 931 server. This has very
little to do with tty security in any case.

---Dan