muller@sdcc10.ucsd.edu (Keith Muller) (05/05/91)
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