ioctl-ability, the TIOCCDTR problem - (nf)

[nrh at inmet.UUCP]

#R:sri-arpa:-241100:inmet:10300004:000:1822
inmet!nrh    Jun 24 15:28:00 1983

***** inmet:net.unix-wizar / sri-arpa!rice at rand-relay /  6:06 pm  Jun 21, 1983
From:  Bill.LeFebvre <phil.rice at rand-relay>

I find allowing ioctls to any writeable terminal distasteful and
dangerous.  The owner of a file is the only person who can chmod it,
why not allow only the owner of a terminal to change the terminal mode
(with an ioctl such as TIOCCDTR)?  It only makes sense...

			William LeFebvre

			CSNet:   <phil at rice>
			ARPANet: <phil.rice at Rand-Relay>
			uucp:	 ...!lbl-csam!rice!phil
----------


Aaargh!  Yes, the idea makes sense if all you want to do is make it
so that talk need not be su, but it throws a real monkey wrench into
the operation of non-privileged programs when they are called on to
control more than one terminal.  Perhaps if we look at this a little
more carefully:

	1. The problem: people can shut other people's terminals off,
	change their baud rate, put them in no-echo mode, and send
	load of anonymous characters,  send chars which lock up the
	keyboard, and much worse.

	2. The reason bad guys could do this is that other people have
	terminals in mode 622.  In other words, they can open the tty
	device for writing.

	3. Phil's suggestion is to change the significance of having
	a device open for writing -- that is, make it so that
	having a device open for writing does not imply the ability to
	change its parameters (baud rate, mode)

	4. BUT -- that still leaves the problem of the anonymous garbage,
	and also makes non-prived programs unable to execute ioctls
	on devices (such as, say, the tape drive) that they do not own.

	5. Backtracking -- all this is no problem if "write" were 
	privileged, people's tty-file  modes were 0600, and write
	checked something else before permitting communication.
	This is how it worked at Harvard, and it worked rather well.