Terminals are ridiculously insecure

[Doug Gwyn]

In article <5228 at phoenix.Princeton.EDU> bernsten at phoenix.Princeton.EDU (Dan Bernstein) writes:
>There is no rational reason that a process should be able to keep
>access to a tty once its owner is no longer the owner of the tty.

You can argue this for interactive login ports, but it's definitely
false for other tty ports.  If there is a serial printer on /dev/ttyP,
there is no reason in the world anyone with proper permissions should
not be able to "cat file >/dev/ttyP".  (This is the simplest example;
don't divert this into a discussion of use of spoolers.)

>I should think that a terminal with nobody logged on should be readable
>and writable by nobody, i.e., mode 000. It doesn't make sense otherwise.

That's certainly one approach that addresses the REAL security hole.

Some time ago, we had a discussion about use of "public filesystem
resource (including device) allocators", the idea being that free
resources could belong to the allocator daemon, which of course
would be the sole UID with access permission.  There was also some
discussion about allocation of ptys and corresponding utmp maintenance.
If somebody wants to work on this "problem" and really solve the
tty administration RIGHT, it would be wise to factor in those notions.

>3. This discussion brings up another point about UNIX. There are very
>few ways to re-check all the open descriptors referencing a file for
>permission on that file. vhangup() is about the closest things come.

There really are applications that rely on the ability to continue
access to an open descriptor after the inode permission have been
changed.  That in itself is not a security problem.  Let's fix the
real holes and not try to remove useful abilities from UNIX simply
out of paranoia.