Xref: utzoo comp.unix.internals:2844 comp.unix.wizards:25675 alt.security:2572
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!rutgers!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: <23893:May1901:19:2191@kramden.acf.nyu.edu>
Date: 19 May 91 01:19:21 GMT
References: <19306@rpp386.cactus.org> <3140@cirrusl.UUCP> <19309@rpp386.cactus.org>
Followup-To: comp.unix.wizards,alt.security
Organization: IR
Lines: 26

In article <19309@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes:
> It's obvious that you are thinking a lot harder than Dan, but it
> isn't clear that you understand the nature of the problem.  A SAK
> squence must be absolutely uninteruptable (for lack of a better
> word).

John, I am assuming the existence of a well-known SAK for a given line,
and pointing out how it can be used to increase security. You're
attacking the mere concept of an SAK. As Multics and several other
operating systems showed quite clearly, SAKs do exist, so any arguments
to the contrary are wrong.

> But SAK alone is not the end-all to security.  You also need an
> application that can do useful things with SAK, and Dan's suggestion
> that every SAK kills everything on the line is just too gross.

I have never made any such suggestion, and I despise the way that you
have misrepresented my proposals. I advise readers to check my postings
rather than believing John's statements about them.

(What I actually suggested is that SAK disconnect the current session.
This means that the user can later log in again and reconnect, resuming
work where he left off. For further details on session management, see
my pty paper, Bellovin's session manager paper, or VMS documentation.)

---Dan