Xref: utzoo comp.unix.internals:2843 comp.unix.wizards:25674 alt.security:2571
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.internals,comp.unix.wizards,alt.security
Subject: Re: BSD tty security, part 3: How to Fix It
Message-ID: <23781:May1901:08:3591@kramden.acf.nyu.edu>
Date: 19 May 91 01:08:35 GMT
References: <25833:May1416:43:4291@kramden.acf.nyu.edu> <3136@cirrusl.UUCP> <19306@rpp386.cactus.org>
Followup-To: comp.unix.wizards,alt.security
Organization: IR
Lines: 40

In article <19306@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes:
> Yes.  Not everything has an out of band channel to send a SAK sequence
> along on.

Then the sequence must be in-band. For the sake of argument, let's say
that getty (or whatever process does the I/O on a hardwired line) checks
for ^K everywhere in the input stream. ^K<space> is translated into a ^K
for the underlying session, and ^K<anything else> disconnects the
session for later reconnection and provides a login prompt. That's a
secure attention key, and one which cannot be defeated on most
terminals. (The exceptions are those terminals which can somehow be
forced to silently transmit a space right after the user types ^K, and
those in which the ^K key itself can be reprogrammed.)

> Dan assures us that
> for a properly started login process (which he can't guarantee the
> user is going to press SAK to start) we get a clean line.

What's the point of your parenthetical comment? The system documentation
will tell users that they should press ^K a few times to get a login
prompt. Otherwise, sayeth the docs, some other user might be faking the
login prompt, and that's a Bad Thing. In any case, yes, I assert that my
solution provides a secure tty, and I've explained in another article
exactly why this is true.

> I say,
> remove the dependency on the user pressing SAK to start with - let
> the system clean the line off itself.  If the user wants to clean the
> line, let her nail the SAK key and kill any trojans lurking in the
> wings.

Frankly, John, that is one of the most idiotic statements I've ever
heard from you. You complain about my solution because it can't stop
stupid users from telling other users their passwords, but you want to
trust the user to press SAK after he's given away the password? Wake up.
Revoking tty access does not solve any more problems than my solution
does, and your ridiculous ideas about how a SAK can be implemented have
nothing to do with tty security.

---Dan