tty access (a general discussion)

[Keith Muller]

To avoid "run-ins" (and chest pounding about security packages that
are available) with people who think that every discussion
is a "cookbook fix", no specific version of unix is being discussed here....
The idea of this posting is to discuss tty deallocation issues in
abstract terms, period.

In very simple term the major differences in security approaches for ttys
can be roughly divided into three flavors. (Assuming STATIC creation of tty
devices only). All of these techniques are based on "well known"
allocation methods that have been around a lot longer than unix...
The point here is to illustrate the need to rethink the semantics of tty
operation in terms of allocation and de-allocation. These three techniques are:

1) You avoid using a tty (even if it is "allocated" to you) until
   all prior references to it are gone. 
2) You revoke all prior references when a tty is allocated to you.
3) At the deallocation of a tty all references to that device are completely
   removed.

Method 2 and 3 are similar, the difference is in the timing of the access
right removal. The technique to revoke access can take many forms, from
flags to generation numbers (if you number is not the current generation
id, no access), to capability lists. The exact technique used is not
important for this discussion.

DYNAMIC allocation avoids these problems as a resource is never reused, it
is destroyed on last reference. In the long term this is probably a good way
to fix all tty security issues.

Lets create a crude analogy called the "tty" car rental agency to illustrate
the tty problems in simplier terms.

When you "sign" up for a rental car you are given the keys to a car parked on
the lot that a previous "customer" has returned. The intent of this rental
agreement is that this car is yours and prior customers have no right to use it.
Now consider the situation where a customer returns a car, returns the keys
and then goes back and sits in the back seat? When you (the new "owner" of that
car) want to use that car you have to deal with the "squatter" in the back
seat. You have no idea if this squatter is a little old grandma or the
mugger from hell. How do you deal with this situation? Method #1 would have you
close your eyes, count to "10" and hope the squatter is gone when you open
your eyes. You keep doing this for some period of time. When this fails, you
go back to the desk to try another car. Method #2 would you take along a large
"bouncer" from the rental agency to "evict" anyone sitting in the car who
locks all doors after the car is empty. Method #3 would require validating
the car is empty when the car and keys are turned in, evicting any remaining
occupants and locking all doors when all is clear. (The rental return agent
is that large bouncer).

For dynamic allocation the "tty" rental agency becomes the "tty" new
car agancy, with "no trade in accepted".

Method 1 and 2 have already be abused so no further discussion is needed.

In this situation method #3 merits consideration. The problem is that there
may be too much vagueness in the current scheme of tty usage to clearly detect
when a tty is "no longer in use". For ptys the close of the master side
is a clear indication. For hardwired ttys the problem is more difficult. 
There are several conditions that can determine deallocation depending
on options set by the user process. 

A dynamic binding of a name to a "one use" tty structure has merit for the
solution in the long term. A similar technique is the way unix domain
sockets are handled. A name in the file system (for those processes that
need it... of course why ttys need to be in the file system is an issue by
itself), and a reference to a one use structure pointed at by the file
descriptors solves the prior access problem. (Note the master side for ptys
would NOT have any name, so it could not be referenced by any other process).
(Of course the master side could be the hook for implementing tty re-attachment)
On last close (on the slave side) all structures are (and the name in the
file system) are destroyed.

Of course with dynamic methods a lot of work is needed to decide the behavior
of a slave tty that is incapable of doing further i/O (the master side pty is
dropped, the hardwire tty connection is dropped etc) when reattachment is
considered.

What do other people think about these problem in general? ......

Keith Muller
University of California