BSD tty security, part 4: What You Can Look Forward To

[Dan Bernstein]

In article <19280 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F Haugh II) writes:
> I suspect that every system with some "revoke" concept doesn't have
> problems with its tty system.

BSD 4.2- and 4.3-derived systems have a ``revoke'' concept (viz.,
vhangup()) and have huge problems with the tty system. So much for that
suspicion.

The very latest version of BSD has a revoke() syscall which works just
like you said. It still lets anyone take over a ``script'' session.

Why do you have this religious fixation on revoke()?

In contrast, the SVR4 tty system allocates ttys dynamically (in the
sense that you get a tty that nobody else is using, not in the sense
that there are arbitrarily many ttys). It doesn't revoke() anything; it
just skips what's being used.

The BSD 4.4 tty system will also have dynamic tty allocation. So will a
future SunOS release.

C'mon, John, why can't you point out the insecurity in SVR4 ttys? If, as
you claim, skipping what's in use is so much less secure than attempting
to revoke what's in use, then where's the attack that Steve Bellovin and
Jonathan Shapiro somehow missed? Where's the danger?

> You scheme, for example, can't insure
> the passwd command that it isn't being run as part of a trojan horse.
> Mine can.

Bullshit. Have you ever heard of network logins? Have you ever heard of
dialout modems? As I said before, unless you restrict use of passwd to
the console, passwd will have absolutely no idea what it's talking to.
Your claim is never true.

Face it, John: revoke() does not solve any problems that avoiding a used
tty entirely doesn't solve. The most revoke() can do is guarantee that
the tty used for login is clean, and that's exactly what my proposals
do. Stop pretending that there's some advantage to revoke().

> This is why
> "Trusted Path" and "SAK" and "access revocation" are so much more
> useful than "don't ever let anyone talk to the hardwire tty."

So how come UNIX processes don't choose their own pids and revoke access
by any other processes with the same pid? How come pid revocation isn't
``so much more useful'' than dynamic process allocation? How about
memory use? How about inodes? How about pipes? How about disk space?

Dynamic allocation appears everywhere in UNIX. It works. Access
revocation is a pointless complexity.

> What
> can you do to prevent the trojan from ever being run, and once it is
> running, how can you get rid of it?

A Trojan Horse is ineffective unless it actually gets a chance to talk
to someone. Under my suggestions, a normal user logging in will always
be talking directly to a system process. No other processes can access
the line. There's no reason to ``get rid of'' what you can just ignore.

---Dan