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
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.
ron%brl-bmd@sri-unix.UUCP (06/20/83)
From: Ron Natalie <ron@brl-bmd> On our system write is Setuid. It checks the "execute" bits of the terminal it is planning to write on to see if the user wants to receive messages. A later modification caused the user to enter a message that gets printed to the invoker of write when the x bits on the terminal are off. (in addition our write prefaces each sent line with the tty name of the sender (and from time to time various non printing characters such as backspace, return, and escape have been blocked, depending on the mood of our user community). -Ron
obrien%rand-unix@sri-unix.UUCP (06/20/83)
This message is empty.
andrew@garfield.UUCP (Andrew Drasskoy) (06/22/83)
The TIOCCDTR "feature" was discovered on our system over a year ago.
The fix implemented here was to make write setuid to root and have most
of the tty protections set to 700 by default. The problem with this
approach is that write will always be able to open a terminal. The fix for
this is simple too, though not very obvious. The biff and mesg programmes
set *execute* permissions for owner and other, respectively, on the user's
terminal. When you want to write to someone, the write programme checks
the 001 protection bit to see if the person wants to accept messages or
not. The execute permission bits can be used for this since they are
otherwise meaningless on a terminal. This has worked very well here, and
there seem to be no problems with it, although it is a bit kludgey.
Andrew Drasskoy
{allegra,utcsrgv}!garfield!andrewrab@medman.UUCP (06/24/83)
Use of the execute bit on a tty device to indicate write permission was implemented back in the dark ages at Harvard. In fact, the people there (specifically at the Science Center) are forced by the ingenuity of their students to be so security conscious that they have had to implement "escape filters" in just about every program that writes characters to a terminal. (Imagine a user putting something nasty in his .plan...) The people at the Harvard Science Center have had lots of experience with protection of their UN*X systems from "hostile" student users. I'd suggest that you contact them for details (at least, as much as they're willing to say).
MCB%mit-mc@sri-unix.UUCP (06/25/83)
From: Michael A. Bloom <MCB@mit-mc> I assume, although you make no mention of it, that write's shell escape was properly handled?