I was thinking about the problem again today, and, having learned a
bit about sessions and controlling ttys and stuff, was able to come up
with a simpler mechanism.
First, observe that the POSIX session mechanism, if properly
implemented, guarantees that only processes from one session at a time
can have any given tty be their controlling tty. What this means is
that if Joe's shell is running on ttyp2, Fred can't run a process that
makes ttyp2 its controlling tty. The only way one of Fred's processes
can have ttyp2 be its controlling tty is if Joe invokes a setuid-Fred
program explicitly from his own session.
What this means is that when you make a tty your controlling tty, that
tty effectively becomes yours until you're done with it.
Why not build chowning into this process? On TIOCSCTTY, the tty would
chown itself to the effective uid of the current process and chmod
itself to 620. Then, on close, the tty would chown itself back to
root and chmod itself to 666.
If the effective uid of the process opening the tty is 0, and the
process is intending to start a non-root session, said process is
presumably capable of doing the chown itself.
The only problem I see with this scheme offhand is that if you run a
malicious setuid-Fred program it might be able to chown your tty away
from you. However... if you run a malicious setuid-Fred program it has
any number of easier ways to make trouble and so I'm not sure this is
a problem.
The advantage of this scheme over the previous ioctl one is that it
doesn't require changing any binaries.
(I'm sending a copy of this to linux-kernel, but since I'm not on it
at the moment I'd appreciate if any discussion there would keep me on
the cc list.)
--
- David A. Holland | VINO project home page:
dholland@eecs.harvard.edu | http://www.eecs.harvard.edu/vino