jbc@ut-ngp.UUCP (06/16/83)
Uh .... This ( bug | feature ) may well have been discussed before, but:
* I've never seen it
* others may not have seen it
* I found it alive and kicking on three supposedly well-maintained
systems (2.8 w/ TCP/IP, 4.1, 4.1c) (hmmm....)
Berkeley UNIX provides a pair of line ioctl's, TIOCSDTR and TIOCCDTR, to
set/clear the DTR bit. Fine; in fact I wanted TIOCCDTR for a hack I was
working on, but in the process of looking over that ioctl source I
discovered no associated permission checks to speak of.
Suppose Joe Fubar is logged in on a dialup, say /dev/ttyxx with mode 622
(typical). Let's also say LNOHANG is clear (again, typical). Then suppose
the (obnoxious) user on /dev/ttyzz opens /dev/ttyxx and clears its DTR
bit, which he *can* do ... well, the result is predictable, anyway. There's
some debate around here as to whether this is a bug or not.
The flavor of fix is pretty obvious, but in slightly different places
on each version. Look in d[hz].c, and, for starters, compare to
the TIOCSTI check in tty.c. What about the desirability, though? And
what about those other line ioctl's?
A colleague contends that it makes little difference, since, if your
terminal is writable, a malicious user could 'foul you up' by just
scribbling on your terminal. Depending on what I'm doing, however,
I see a difference between that and being logged out. In an environment
such as the one here, where almost all lines are on modems, I favor
making a change.
Opinions? Comments? Thoughts on restricting other calls (e.g. other
line ioctl's)? Thoughts on making UNIX more restricted in general?
Arguments in favor of leaving things as they are (there must(?) be a
reason for perpetuating this across releases)? But please, not
another flame-a-thon like /dev/mem....jbc@ut-ngp.UUCP (06/16/83)
Gee! Less than 24 hours and flame mail already! I'm impressed.... One. I stated that I observed the problem "...on three supposedly well-maintained systems (2.8 w/ TCP/IP, 4.1, 4.1c)...." Some people have taken this to mean 1) that I think that UCB provides support similar to what has been promised for System V, or 2) that I think they should and was being sarcastic. Neither is correct. My statement should have been: "I have observed the problem on three different hosts, one running 2.8 w/ TCP/IP, one running 4.1bsd, and one running 4.1cbsd. All three systems are supposedly well-maintained [implying if this had been posted before, then 1) it would have made it into at least one of them, or 2) it wasn't considered a bug]." My apologies for confusion, hurt feelings, and delusions of persecution resulting from this ambiguity. Two. My thanks to all the kind people who have suggested that I write-protect my terminal (and thanks in advance to those who are going to -- please don't). What if I want to carry on a conversation with someone using write(1)? Do I unprotect my terminal and leave it vulnerable? Do I make write setuid root, insuring that someone's nroff output will be fouled eventually? Someone just suggested a '.writerc' file to (dis)allow writing ... that's the ugliest idea I've heard yet. And what about multi-user multi-terminal games that expect a writable terminal? And ... I think that 1) it's basically right that a terminal be writable most of the time; 2) it's basically wrong that a process be able to substantially affect a terminal which is not its control tty; 3) this whole discussion is going to wind up in net.flame Real Soon Now....
ejs@whuxlb.UUCP (06/17/83)
I agree with your colleague. Some terminals allow escape sequences that, in addition to other potentially nasty things, drop CD low for a sec (ESCf in an hp2621), causing a modem disconnect. Beau Shekita BTL-Whippany whuxlb!ejs
CSvax:Pucc-H:acg@pur-ee.UUCP (06/17/83)
We have a local mod on the PUCC systems that only permit an ioctl to proceed if the process has IREAD permission on the inode or if the device is the process's controlling tty. We have yet to see anything that this breaks. Philosophically, this is justifyable if one considers executing an ioctl on a terminal in the same class as forcing characters to the terminal's input stream. Permission to execute an ioctl on a terminal should be bound to input (read) permission not write (output) permission. - Jeff Schwab Purdue University Computing Center <pur-ee!pucc-h:acg> <jrs@purdue>
ka@spanky.UUCP (06/17/83)
Providing security is a major problem if you assume that your users are required to cooperate but are avidly waiting to move in for the kill the moment they find a hole in another user's security. There are capability based schemes which do relatively well at providing this, but UNIX was designed more with environments like the Bell Labs in mind. Barring a major re-design of the UNIX security mechanisms, you can a) Forget about using write. I prefer mail or a phone call anyway. b) Make your terminal mode 620, and only talk to people in your group. Preventing processes from doing a stty on a terminal other than the control terminal doesn't really solve the problem since many terminals are upset by various escape sequences, and it's just one more hack to confuse people on sites that don't need it. Kenneth Almquist
WrongLogin@erewhon.UUCP (06/18/83)
I'm going to echo Kenneth Almquist's comment that we shouldn't hack the terminal drivers to prevent one user from stty'ing another user's writable terminal when escape sequences are just as bad. Two years ago, there was a discovery at Berkeley that the press mangled into "Nasty college students find HUGE security hole in UNIX" (The "UNIX" being a computer made by DEC.) What really happened was a rediscovery of the fact that many computer terminals respond to escape sequences. On an HP terminal, a escape sequence will cause the terminal to echo whatever is currently on the screen, and the computer or course assumes that this was typed by the user. Thus you could write: stty 0 <magic-escape-sequence> onto somebody's terminal, and zap him/her just as badly. (For that matter, there is a "Disconnect Modem" sequence that will do the same job much faster. I once had a good game of rogue interrupted by someone who had been discussing UNIX security with me.) Ann Nonymous @ erewhon
dmmartindale@watcgl.UUCP (Dave Martindale) (06/19/83)
I don't believe that ioctl calls should have any sort of special restrictions requiring anything other than the permissions on the tty special file. If someone can open your tty for writing, why should they not be allowed to use whatever ioctl they please? If you don't trust the other users on the machine to act responsibly, then you don't want general write permission on your terminal at all. If this requires that inter-user communications programs such as "write" be setuid, so be it. While plugging holes, you should also make write check the characters it is passing along and strip control characters that might do funny things to the recipient's terminal. An even better scheme is something like the "talk" program posted recently, where the recipient voluntarily joins the conversation and writing to his screen is done only by a process which is run by him.