BSD tty security, part 3: How to Fix It

[Dan Bernstein]

In article <19002 at sdcc6.ucsd.edu> muller at sdcc10.ucsd.edu (Keith Muller) writes:
> In article <1237:May321:05:0191 at kramden.acf.nyu.edu>, brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
> > (It will work for hardwired ttys if you make the outlined changes to
> > getty's initialization routine. But without a secure break key [as you
> > can implement with my suggestion #24], hardwired ttys are completely
> > insecure anyway.)
> Why should hardwire ttys be insecure?

For all the reasons that Bellovin outlines in his session tty paper.

> Preventing login just because a background job is referencing a
> tty is not acceptable.

But leaving the tty insecure isn't acceptable either. That's why the
logical compromise is to allow login on a dynamically allocated tty, or
to simulate dynamic allocation the way that I've been recommending. I
notice that you deleted my explanation of the analogy between ttys and
pipes/pids/etc.; I'd appreciate it if you responded to that analogy
before continuing to talk about ``acceptable'' ways to handle tty
security.

> If I read #24 correctly you want to force ttys through ptys?

Yes, though this is not a required step. It just makes sense, and gives
you features like a secure break key. I'd say that severing the link
between modem connections and tty handling is the heart of Bellovin's
session tty idea.

> Sure is a lot
> of overhead (in and out of user mode multiple times to move data). 

There's a lot of conceptual overhead too---all the tty processing,
forwarding the data to a physical device like a modem, etc. With streams
(or, I assume, bstreams), there's no user-mode switch anyway, and going
through both a /dev/modem and /dev/ptyxx would be almost as fast as the
current hardwired ttys.

> > And once you have included special treatment of that flag in every
> > single tty operation. This is a lot of kernel work. Why do you refuse to
> > write out these changes at a sufficiently low level of detail that
> > people can implement them? If it's so few lines of code, why don't you
> > write out the code?
> I am not trying to promote a fix, but promote a discussion on how to 
> address tty semantics. The only reason I even answer your postings is to
> point out that other METHODS exsist.

Okay, I'm sorry for flaming. I just don't want to see people proposing
non-solutions as solutions, because that's exactly what's caused all the
previous screwups.

In particular, your ``fixes'' do not work on any system that has
p_ttyd/u_ttyd instead of u_ttyvp. This includes most BSD releases,
Ultrix through at least 4.1, Convex UNIX through at least 9.0, and many
other systems. So if you're going to continue talking about your
``solution'', please try to be accurate: ``solution for BSD 4.3-Reno''.

> 	if (((unsigned)uap->fdes) >= NOFILE ||
> 		    (fp = u.u_ofile[uap->fdes]) == NULL ||
> 			(fp->f_flag & FREAD) == 0)
> 			return (EBADF);
> Now tell me the open file table access rights for the read isn't being
> done here....

It isn't. Again, what makes UNIX security so simple is that there's the
file protection firewall, and once you're past that wall there's nothing
to check. One of vhangup()'s problems, as you noted, is that a process
blocking on I/O won't check for access rights again.

Doesn't it strike you as odd that you have to introduce access checks at
so many extra spots to make your revoke() work even marginally better
than vhangup()? Don't you realize that you're proposing a fundamental
change to the security mechanism? There's no precedent in UNIX for
revoking file access!

> Deallocation
> of ttys is not a very highly called occurance to consider the above loop
> "intensive".

I care very little about the efficiency of tty allocation, though
scanning the file table on allocation increases turnaround time, while
actions on deallocation don't. I care much more about the amount of code
that has to be changed.

> Actually in both this and
> your method the case where multiple (v)(i)nodes reference the same device
> probably should be addressed (even if it is a questionable thing to do)..

Again, please stop criticizing my proposal before you've read it. My
method handles this case correctly---it's not even a special case,
because unlike you I'm not mucking around with vnodes and the file
table. I agree that you have to address such issues.

> All tty
> references use the open file table. Access removed there terminates access
> to the tty.

No. That's a common blunder. In a multitasking system there are several
operations going on at once. You have terminated FUTURE access to the
tty ONLY IF there are no current operations.

Don't you understand that this ``termination'' idea is foreign to UNIX?
Don't you think that you'd better have a whole bunch of people think
through it and reimplement the kernel around it before deciding that it
works?

> In the 4.3 reno you get from CSRG, ttyvp does exsist (see kern/tty_tty.c).

Yes. That's what I said.

> > But you want people to add an extra check, plus have it handled for
> > blocking processes. I repeat my claim.
> This is the only check added. Not a significant consumption of time.

When did you suddenly become so fixated on time? What I care about is
simplicity. People (and vendors) should have to make as few changes as
possible to the system, with as little of it as possible in the kernel.

Here, let's review my required kernel changes again:

: Quick summary of kernel changes required: Make /dev/tty ioctls work on
: /dev/tty??, make a /dev/stdtty driver which simply dup()s fd 3, and add
: an ioctl, TIOCOPENCT, which returns the number of active references to a
: given inode. That's it.

Would you like to give a paragraph stating your required changes, at the
same level of detail?

  [ ... ]
> And thats what I desribed, a technique for the BSD 4.[234] tty system.

But, once again, your technique does not work on most BSD 4.3-based
systems and will work on absolutely no BSD 4.2 systems. Rather than
arguing with me, why don't you ask Marc Teitelbaum at Berkeley whether
there exist standard systems supporting u_ttyd. You apparently don't
believe they do.

---Dan