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

[Dan Bernstein]

In article <19315 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F Haugh II) writes:
> >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().
> Sure there are.  "Denial of service".  If I manage to take up all
> the pty's, how are you ever going to get me off the port?

If a user opens all the ptys (which he can't under my proposal since
they're protected), nobody will be able to open any of them again, and
revoke() doesn't do diddly about that. If a user has access to all the
ttys, then under my proposal not only will all those ttys will be
accounted to him, but he'll have to be running under a telnetd or
rlogind or whatever on each port, so all the ptys will be open anyway.
Once again revoke() does absolutely nothing.

> I don't care what happens when you login.  I want to know what happens
> =after= you login.  Get it through you think skull.  I don't care about
> login time.  F*ck login time.

It's too bad you feel that way. Right now I'm focusing on tty security,
and each login process runs under a tty. (This isn't how it should be:
you should allocate as few resources as possible to someone who hasn't
idenitifed himself. Wasting an entire tty is silly.) If the line is
clean before login runs, it will remain clean unless the user does
something stupid, like find / -user `whoami` -exec chmod {} 666 \;.

> How does the Dan Bernstein Trusted Path Manager get that process off
> the line, other than arguing with it for 2 weeks before doing nothing?

It ignores it---and enforces security---by using another line. Which is
what Dan Bernstein should probably be doing to you.

---Dan