BSD tty security, part 3: How to Fix It

[John F Haugh II]

In article <17790:May522:37:5591 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <19002 at sdcc6.ucsd.edu> muller at sdcc10.ucsd.edu (Keith Muller) writes:
>> Why should hardwire ttys be insecure?
>
>For all the reasons that Bellovin outlines in his session tty paper.

There is absolutely =no= reason to consider hardware tty's to be
insecure simply because they are hardware tty's.  All that is required
to make hardware tty's secure is for some operation to exist which
insures that all current references to the device are legitimate.

This could be implemented as a hardware signal (Secure Attention Key)
which kills all processes on the list of processes having the device
open directly or indirectly but not possessing some privilege or
belonging to some set or processes.

>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''.

It is very possible to have u.u_ttyd and still have secure hardware
tty ports.  The system could very easily maintain a list of every
process which has any reference to that specific device.  A system
call could then traverse that list and kill any process not permitted
to still have a reference to that device, or it could be nice and
merely invalidate the access to that device.

>Don't you understand that this ``termination'' idea is foreign to UNIX?
>Don't you think that you'd better have a whole bunch of people think
>through it and reimplement the kernel around it before deciding that it
>works?

This has already been done several times.  If you can find a way past
the revoke() and frevoke() system calls in AIX v3, send me a note.  I
don't care for how it was implemented (which I consider to be a gross
hack of the first order), but it works very completely.

The complaints you have about "future" termination are really very
easy to address.  There are only so many places a process can sleep
in a device driver.  Go fix them.

>Here, let's review my required kernel changes again:

[ List deleted ]

>Would you like to give a paragraph stating your required changes, at the
>same level of detail?

Provide a mechanism within the kernel for tracking processes with
current access to any inode table entry.  Define a system call or
ioctl command which terminates all processes, except the current
process, which have references to that inode table entry.  Define
it such that operations on character and block devices affect all
inode table entries that refer to the same major and minor device
number pair.  This gives access revocation ability for files and
filesystems, as well as tty's.  It also doesn't require streams
or dynamic pty allocation or copying all manner of data all over
the inside of the kernel.

The first part is time and space consuming, and does more than
what is needed to solve the tty problem.  If you care about all
those things, limit it to tty devices only.  The nature of the
problem is that there is no reverse mapping from inode to process.
Create a reverse map from inode to process, and the problem
goes away.
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) |  Domain: jfh at rpp386.cactus.org
"If liberals interpreted the 2nd Amendment the same way they interpret the
 rest of the Constitution, gun ownership would be mandatory."