ioctl-ability, the TIOCCDTR problem - (nf)

[Steven M. Haflich]

The notion of making IOCTL permission on a character or block device
distinct from either read or write has a certain attractiveness.
It could be controlled by the eXecute bits, presumably, but this
screams of special-casedness!  Can anyone think of a reasonable
conflict with the X bits for special files?  I'm not sure, but
perhaps search permissions are needed for the fake files which
appear "underneath" some network servers (e.g. /dev/ether/foo) ???

There are two problems being addressed by the recent discussion.
If all one wants to do is permit/prohibit unauthorized read, writes,
and ioctls on a tty, then present machanisms coupled with some sort of
intelligent checking conventions by a setuid root talk would seem
sufficient -- at least the problem is localized.  However, writing
a multi-user multi-terminal interactive system which remains secure is
far more difficult.  Such things are easy to implement under Unix
if the security requirement is dropped.  (Several historical multi-\
terminal games come to mind.)  As each user begins execution, startup
code makes his tty read/writable by everyone.  However, this allows
anyone *else* to manipulate the device.  Even if original modes are
restored upon exit, someone could have opened the device while it was
lying unprotected...

For most purposes, of course, such concerns are paranoid.  However, if
a real solution were attempted for this problem, probably it would
have the form of "granting" capabilities to process groups (or
whatever).  In fact, an ancient PDP-1 (no typo!) operating system
in the early 70's had many such interesting features for sharing and
acquiring "capabilities," but I disgress.  Alternatively, having the
user code be setuid to a distinct group and perform the appropriate
chmod's at entry and exit would seem to be sufficient.  This does
require support from the system manager to assign a group id and
maintain the /etc/group file, but it is easy to do, requires no
more rediculous warts inside Unix, and is probably fairly secure.

Remember V6 when Unix was trim and lean?

			Steve Haflich, MIT-EMS
			genrad!mit-eddie!smh