BSD tty security, part 3: How to Fix It

[John F Haugh II]

In article <3140 at cirrusl.UUCP> Rahul Dhesi <dhesi at cirrus.COM> writes:
>Dan will, of course, have his own response to this (as he always
>does :-).

Yes, I have read the specification for the Dan Bernstein Window
Manager.  It argues with your for 15 minutes and still doesn't
resize the window ...

>          Although it's true that not all hardware guarantees an
>out-of-band channel to support a secure attention key, it turns out
>that there is a simple method of using in-band signalling that is
>*virtually* foolproof.

The problem is that it must be =absolutely= foolproof.  If I can
come up with even one way to circumvent it, it isn't usable as a
SAK sequence.  AT&T with the SV/MLS product uses DTR as the
out-of-band signal.  What about three-wire terminals?  [ The answer
there is that if you don't use exactly the set up the NCSC evaluated,
your milage may vary ;-) ]

>     (1 second pause) +++ (1 second pause)
>
>When the above happens on the data line, a modem that understands it
>goes into command mode.

Every second I send an answer-back request to your terminal.  Once a
second I receive the answer-back, strip it out from whatever you type,
and pass that along unchanged to the rest of the system.  You never
notice anything funny because you aren't talking to the hardware
anyhow, but rather my little trojan horse that is pretending to be
the login program.

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).  I don't think it is possible for a single SAK sequence to
apply to all possible login session types for more than the smallest
collection of hardware.  I think it takes a multiple choice approach.

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.  If
the user can't SAK at any time, they will never SAK.  And that means
any need for the SAK key during crucial operations (like changing
your password) will not be met - what, press SAK and kill my XBIFF?
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) |  Domain: jfh at rpp386.cactus.org
"If liberals interpreted the 2nd Amendment the same way they interpret the
 rest of the Constitution, gun ownership would be mandatory."