BSD tty security, part 3: How to Fix It

[Dan Bernstein]

In article <19045 at sdcc6.ucsd.edu> muller at sdcc10.ucsd.edu (Keith Muller) writes:
> In article <17790:May522:37:5591 at kramden.acf.nyu.edu>, brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
> >> Why should hard-wire ttys be insecure?
> >For all the reasons that Bellovin outlines in his session tty paper.
> I was making an "open question". A design that leaves a device as hopelessly
> insecure really need to be reevaluated. If the technique used for
> security on ptys cannot be extended to hard-wired ttys,

Are you referring to mine? As I pointed out, you can perfectly well use
TIOCOPENCT at the beginning of a hardwired tty session (i.e., in getty).
If someone is still using the tty, getty will (I presume) give a message
to the user and sleep.

> I have no special interest in any specific
> technique for solving tty security on BSD for the LONG TERM.

Right. It's interesting to discuss long-term solutions, but the current
topic is a minimal correct fix for BSD 4.[234] as well as all systems
derived from them. Let's make sure to keep these topics separate.

> No one ever objected to dynamic allocation, but you do not
> have dynamic allocation in your solution,

This can be argued---would you say that files are not dynamically
allocated because there's only a finite pool of possible inodes on each
disk? Would you say that processes are not dynamically allocated because
the process table is finite?

> This might be a fine quick fix, but ignoring alternative
> solutions is short-sighted.

All I want people to ignore is non-solutions. What you've proposed is
not a short-term solution for most systems.

Here's what I said at the beginning of this thread:

: Here's one way to fix the BSD 4.[234] tty system, i.e., to provide some
: strong guarantees that pty and tty sessions are safe and not subject to
: corruption or denial of service, with minimal changes to the kernel and
: to application programs. This is also meant to apply to systems derived
: from BSD, such as SunOS, Ultrix, etc.

If you want to talk about changes that don't make those guarantees, or
if you want to talk about changes that only apply to BSD 4.3-Reno, or if
you want to talk about extensive, long-term changes, feel free. Just
don't do it in this thread.

> Creation of completely dynamic ttys (probably more than just
> cloning ptys) for both hardware tty ports and network based ports would
> require a long term project to be done on a pure BSD system.

Well, BSD 4.4 is going to implement ptys with bstreams, and your
concerns about the speed of data flow are answered by any proper streams
system. (Putting I/O through a stream doesn't involve a context switch.)

> Your analogy to pipes/pids is basic operating system concepts, nothing is
> there to comment on....

But you keep saying that revoking access is somehow simpler or better
than dynamic allocation. If you believe that, why don't you extend the
analogy to pids and pipes and inodes?

> >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''.
> To quote (loosely) Chris Torek "... they are not BSD...".

Fine. In case you didn't notice, I'm talking about solutions that the
rest of the world can use. This was part of the very first paragraph in
this thread, and I don't like the way that you neither take the steps to
make your solution portable, nor admit in public that it's not portable,
given that the thread started on a portable note.

And as for BSD, the official BSD 4.2 had u_ttyp. Official BSD 4.3 had
u_ttyp. Official BSD 4.3-Tahoe had u_ttyp. It is only in BSD 4.3-Reno,
which is only a beta of 4.4 and is not a production system, that
Berkeley picked up u_ttyvp.

> I keep saying
> this is discussion of BSD UNIX as from UCB

But you don't even take 4.2, 4.3, or 4.3-Tahoe into account.

> I have been accurate in my statements, you just keep ignoring the text... 

No, I've been taking your statements as you say them. For example:

> Both p_ttyd/u_ttyd have never existed in a UCB release).

This is incorrect. I'm sorry, but I can no longer take seriously what
you say about standard BSD code, and it's obvious that you don't care
about any of the BSD variants.

  [ read() example ]
> So at entry point access rights are
> checked.

Sure, but that's not sufficient to check access rights at all times once
you allow those flags to be turned off.

> >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!
> Sure looks like vhangup() (which has been around for years) revokes
> access.

No, it does not. As a syscall it is useless; as an experiment it failed
miserably.

> access protection by rights is part of unix and
> is not a fundamental change.

Terminating access rights is a fundamental change. How about we drop
this issue until one of the original UNIX developers has given his
opinion.

> The special case (though it is not a bright thing for a admin to do) is
> have two ttys with different names but the same major/minor number.

I can't stop someone from giving all usernames the same userid either.

> >> 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.
> You had better sit down with 4.3 tahoe source for example (and again
> I am talking about pure UCB BSD again). And look. If the code is too complex
> use McKusicks et al Operating System book, a very good reference.
> There are no way a file descriptor can do i/o if its open file table
> reference is invalidated (where invalidation means FREAD etc flags are
> removed).

Obviously you don't understand what an I/O operation is. If someone is
performing a read operation or write operation on a tty, he has already
gotten past the access checks in the open file table, and terminating
permission there doesn't stop the operations in progress.

> In a multitaking system on a single cpu, there really only one section of
> code (either kernel or user, ignoring dma and i/o bus stuff) executing
> at a given instance.

And this is the most useless way to look at an operating system. Unless
every atomic user operation completes instantly, the OS will have to
handle several operations in progress at once.

> A very good basic text is Silberschatz et al
> Operating System Concepts for a description of these fundamental techniques.

Why don't you read it?

> Second guessing what changes a vendor made to the basic BSD system
> is not being discussed.

Who are you to dictate what's being discussed? I'm worrying about
security on all the BSD-derived systems out there, and only a small
percentage of them are straight from Berkeley. I *have* to know what
vendors are doing. You don't, but your fixes also don't work on most
machines.

> > > 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.
> A fix that slows a kernel down because it is easy is probably a poor
> design.

Perhaps.

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

I didn't forget anything. See the word ``kernel.'' I again request that
you outline the kernel changes you require, in at least sufficient
detail that someone familiar with what each kernel routine does can
implement the changes. ``fix the wakeup cases'' has no detail at all.
Then try to claim that changing code throughout the kernel is more
robust than adding a couple of syscalls.

> But in all
> fairness, I would not be concerned about the size, but the performance
> (read this as execution speed) of the solution.

Fine. My solution involves absolutely zero change in user turnaround
time for pty allocation, and nearly zero time total. Yours?

> >> And thats what I described, 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.
  [ accuses me of misreading something ... ]
> Please stop trying to expand this to non BSD systems (Sunos
> is NOT BSD....).

You're the one who tried to take the phrase ``BSD 4.[234] tty system''
out of context. The complete paragraph is quoted above; as anyone can
see, I have from the beginning been referring to *all* BSD-derived
systems.

  [ after once again claiming that BSD releases have never included u_ttyd ]
> Please go and study operating systems in more detail. If you comment on
> 4.3 Tahoe or reno look at the code, (dropping names does not make a
> statement correct) and say nothing about the code until you understand it.
> You may want to consider taking a few graduate level courses in
> operating systems...

I think this is a classic case of someone making an absolutely false
statement, then giving several pieces of advice that obviously would be
better applied to himself.

---Dan