phil.rice%rand-relay@sri-unix.UUCP (06/22/83)
From: Bill.LeFebvre <phil.rice@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@rice> ARPANet: <phil.rice@Rand-Relay> uucp: ...!lbl-csam!rice!phil
Michael.Young%cmu-cs-g@sri-unix.UUCP (06/22/83)
One good reason for allowing ioctls on a tty you have a writeable descriptor for is to allow setuid-someone-else (but maybe not root) programs to do neat things for you (like present a visual display of some sort). It seems to me that writing on someone else's terminal has almost as much negative potential as ioctl'ing it. Don't let your tty be writeable. [With 4.2, one ought to be able to set up an ipc port which can provide controlled (by tty owner) access to one's tty.] Michael
nrh@inmet.UUCP (06/25/83)
#R:sri-arpa:-241100:inmet:10300004:000:1822 inmet!nrh Jun 24 15:28:00 1983 ***** inmet:net.unix-wizar / sri-arpa!rice@rand-relay / 6:06 pm Jun 21, 1983 From: Bill.LeFebvre <phil.rice@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@rice> ARPANet: <phil.rice@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.
smh@mit-eddi.UUCP (Steven M. Haflich) (06/28/83)
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
phil.rice%rand-relay@sri-unix.UUCP (07/06/83)
From: Bill.LeFebvre <phil.rice@rand-relay> Oops! I wasn't thinking clearly when I composed that letter. It was an idea off the top of my head and I didn't stop to think about the consequences. I rescind my previous suggestion "allow only the owner of a terminal to change the terminal mode". But I just can't stop thinking that somehow the owner of the terminal can be worked into a solution for this security problem. Perhaps allow only the owner to change SOME of the terminal modes? No, I'm afraid that's a bit too hackish for my taste. I quite agree, however, that no matter how many restrictions you place on ioctl's that change a terminal's state, you still have the problem of anyone in the world writing any control sequence they wish to your terminal. For some reason, setting the terminal to mode 600 and having write and such set-uid rubs me the wrong way. It must just be the set-uid paranoia that is running rampant on UN*X systems these days. Thank you all for staying awake when I was quite obviously asleep at my terminal! Bill LeFebvre CSNet: phil@Rice ARPAnet: phil.Rice@Rand-Relay uucp: ...!lbl-csam!rice!phil