Xref: utzoo comp.unix.wizards:25678 alt.security:2576
Path: utzoo!utgpu!cs.utexas.edu!execu!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.wizards,alt.security
Subject: Re: BSD tty security, part 3: How to Fix It
Message-ID: <19313@rpp386.cactus.org>
Date: 19 May 91 17:36:00 GMT
References: <19306@rpp386.cactus.org> <3140@cirrusl.UUCP> <19309@rpp386.cactus.org> <23893:May1901:19:2191@kramden.acf.nyu.edu>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Lone Star Cat Emporium and BBQ Grill
Lines: 35
X-Clever-Slogan: Help Prevent Robbery.  Tax the IRS.

In article <23893:May1901:19:2191@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>(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.)

[ I was going to respond to the other article from Dan.  I'm on a
  "responding to Dan" diet ...  This last paragraph was too juicy to
  pass up. ]

Which means that your SAK scheme is actually less secure than I had
originally thought.  What are you going to do to revoke TTY access to
a process that =somehow= has illicitly gained access to the TTY?  Multics
and AIX v3 (and others ...) have a SAK key that gets it right - if you
don't have any authorization to attach to the port, you die when the
user presses SAK.  Your scam lets the trojan or whatever lurk about in
the background, and never kills it because you've been too kind hearted
and let it live.

Now I realize that SAK and trusted path really come into the NCSC
criteria somewheres up around B2 and B3, but really, either implement
it so that SAK does what it should (revoke unauthorized access to the
TTY) or don't bother at all.  Your suggestion is akin to the apparent
AT&T implementation of SAK for SV/MLS - /etc/getty interprets the DTR
falling, and goes and kills the jobs that have the port open.  But
what if /etc/getty isn't running?  [ This is a real question ... ]

All I want to know is what do you do to get rid of trojan horses after
they have gained access to your tty line.  Could you please answer
that one simple little question?
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) |  Domain: jfh@rpp386.cactus.org
"If liberals interpreted the 2nd Amendment the same way they interpret the
 rest of the Constitution, gun ownership would be mandatory."