BSD tty security, part 3: How to Fix It

[John F Haugh II]

In article <21553:May1020:06:0791 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>Since John expressed some doubts, enclosed here is an informal but
>reasonably detailed proof of the security of my proposed solution. Also
>here is a justification of each of the required steps in my solution.
>Someone who reads through this should understand why each step is
>necessary and why in combination they are sufficient; if there's any
>misunderstanding, send me e-mail, and I'll post a clarification.

None of that is "an assurance" that I have a clean port.  What does
the system do to "assure" the application that the pty port is clean?
What can the application do to gain some assurance that the pty port
server it is talking to is really the right thing to be talking to?

There are only two things needed to guarantee you have the only
open file descriptor - TIOCOCNT (or whatever) and fchmod().  If you
want to bump everyone off, add a "revoke()"-like system call.  All
this tty copying nonsense defers the problem to the administration,
which had better never let the permissions get messed up, or a new
device node created.  Yes, kernel changes are needed as well.

The ability to "clean" a hard or soft tty with a "revoke()" system
call guarantees that the tty port you are talking to is yours and
yours alone, file permissions or no.  What you do is to defer the
issue for another level - nothing has prevented me from setting up
my trojan horse on the pty side and walking away.  You'll also
find the business with the <BREAK> key is pretty costly when you
start getting framing errors on your modem ports and your users
get logged out.
-- 
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."