BSD tty security, part 3: How to Fix It

[Dan Bernstein]

In article <19262 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F Haugh II) writes:
> 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?

I don't understand this. Why should the application need such assurance?
It's just an unprivileged program. Are you saying that whenever someone
forks ls, it's ls's job to make sure that it's talking to the ``right
thing'' (whatever that is) before it runs? How is it supposed to behave
differently if it's not talking to the ``right thing''?

If the system supports normal UNIX security, my changes guarantee that
when a user starts a program through telnet or rlogin or script or
whatever, no other program initially has access to the same tty. It's
not the program's job to make such checks, just as it's not the job of
each new process to check at user level that it has a unique pid.

> 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.

Every new telnet or rlogin or script will skip that pty, so who cares?
In the meantime the session will be accounted to you.

> 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.

So use a different secure attention key. The point is that if getty is
the only program with a hardwired tty open, then there's no way for user
programs to mangle that tty except as getty allows.

---Dan