ka@hou3c.UUCP (01/01/70)
> On 4BSD (and V7?) a tty must be opened for writing in order for a > process to set the tty's modes. This does make a certain amount of > sense; if you don't want someone to write on your tty, then you usually > don't want them to set your tty's mode either. It certainly does not make sense to me. Why would you give somebody read permission on your tty but not write permission? Kenneth Almquist
donn@utah-cs.UUCP (Donn Seeley) (08/14/84)
From Guy Harris (guy@rlgvax.UUCP): The USG UNIX solution is, I think, better; the USG "stty" command acts on its standard *input*. There is a reason for the curious behavior of the Berkeley 'stty', as I'm sure Guy knows, and it's probably useful to mention it in passing. On 4BSD (and V7?) a tty must be opened for writing in order for a process to set the tty's modes. This does make a certain amount of sense; if you don't want someone to write on your tty, then you usually don't want them to set your tty's mode either. It was decided that it was simpler to get and set modes on the same descriptor, hence the output to stderr and so on. I'm not sure how USG Unix handles this: does the tty merely have to be writable, as opposed to being opened for writing? Does 'stty' get modes from stdin and set them on stdout? Does it care how the descriptor was obtained? The second of these alternatives (get stdin, set stdout) would work on 4BSD... If there was a '-c' option for copying modes, you could perhaps say 'stty -c < /dev/ttyz1 > /dev/ttyz2' and copy the modes from one tty to another. 'stty -g' sounds useful, except that the output of 'stty' is already so close to being input to 'stty' that it's a pity (ouch) it wasn't extended a little farther so that 'stty < /dev/ttyz1 > file; stty `cat file` > /dev/ttyz2' could work. More wishful thinking, Donn Seeley University of Utah CS Dept donn@utah-cs.arpa 40 46' 6"N 111 50' 34"W (801) 581-5668 decvax!utah-cs!donn
ron@BRL-TGR.ARPA (08/14/84)
From: Ron Natalie <ron@BRL-TGR.ARPA> Actually, people more jealously guard their TTY's read permission than their write permissions. In mundane UNIX systems all kinds of things expect to be able to write on other user's terminals, but allowing reads/sttys is a real hassle/security violation. -Ron
gwyn@brl-tgr.UUCP (08/14/84)
Relay-Version: version B 2.10 5/3/83 based; site houxm.UUCP Posting-Version: version B 2.10.1 6/24/83; site brl-tgr.ARPA Message-ID: <3954@brl-tgr.ARPA> Date: Tue, 14-Aug-84 12:24:30 EDT Date-Received: Mon, 20-Aug-84 15:28:50 EDT tty' uses stdout instead of stdin Organization: Ballistics Research Lab Lines: 8 So long as ioctl requires a file descriptor, the normal access permissions on a terminal special file suffice for protection. At BRL, general terminals do not have write permission enabled; rather, the execute bit indicates whether a "write" or "talk" connection is permitted, and the utilities dealing with this have all been changed to understand the convention. This pretty much solves the problem of obnoxious users messing around with your terminal from elsewhere.
bsa@ncoast.UUCP (The WITNESS) (08/17/84)
[The world is a Klein bottle] > From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) > At BRL, general terminals do not have write permission enabled; > rather, the execute bit indicates whether a "write" or "talk" > connection is permitted, and the utilities dealing with this > have all been changed to understand the convention. This pretty > much solves the problem of obnoxious users messing around with > your terminal from elsewhere. I have two questions about this: (1) Why the heck is ioctl not protected? I would think that "owner or root" would be a darned good idea; is there something complex about this that pre- vents protecting the ioctl() system call? (2) This suggestion would be enhanced by (1) above, but is workable anyway; if you can tell that you are doing an ioctl get, why not GET from fd 0 and SET from fd 1? This would be MUCH easier on everyone; and makes for a logical shell syntax: (this is v7 stty I show) $ stty -l </dev/tty1 ; : this reads ioctl info from tty1 ... $ stty cbreak >/dev/tty1 ; : this is likely to get the guy on tty1 upset... I can't see any problems with this way of doing it; am I missing something? --bsa -- Brandon Allbery: decvax!cwruecmp{!atvax}!ncoast!bsa: R0176@CSUOHIO.BITNET ^ Note name change! 6504 Chestnut Road, Independence, OH 44131 <> (216) 524-1416 "The more they overthink the plumbin', the easier 'tis tae stop up the drain."
muller@sdccsu3.UUCP (08/19/84)
If you have any kind of security requirements for protecting users from each other and you are running 4.2, you *must* prevent general user programs from being able to perform an open on another users tty. There are a lot of real nasty things that can be done once you have that open file descriptor. Keith Muller UCSD Computer Center
gwyn@brl-tgr.UUCP (08/21/84)
Relay-Version: version B 2.10 5/3/83 based; site houxm.UUCP
Posting-Version: version B 2.10.1 6/24/83; site brl-tgr.ARPA
Message-ID: <4139@brl-tgr.ARPA>
Date: Tue, 21-Aug-84 11:49:54 EDT
Date-Received: Tue, 28-Aug-84 06:15:09 EDT
tty' uses stdout instead of stdin
Organization: Ballistics Research Lab
Lines: 16
Ioctl() is not the only problem; consider
cat /unix >/dev/tty01
where some fool has left his terminal (/dev/tty01) writable to the world.
Worse yet, send him a character sequence like
HOME CR LF cd; find . -exec chmod 777 {} \; &
CLEAR_TO_END_OF_SCREEN HOME DUMP_SCREEN CLEAR
(using the appropriate codes for his terminal type) and you will get him
to chmod all his files so you can play with them. Short of refusing to
purchase terminals with a DUMP_SCREEN feature (or programmable function
keys that can be both programmed and played back under computer control),
the only way to avoid this security bug (which could be REALLY bad if the
victim is super-user at the time) is to prevent writes on terminals by
other users except via trusted system code.
When a user is not logged in, the terminal can be writable. This is
handy for daisy-wheel printers, for example.guy@rlgvax.UUCP (Guy Harris) (08/22/84)
If anybody remembers the Great Security Hole in UNIX that was "found"
about a year ago, even write permission on a terminal can be a security
hole, if your terminal can be made to transmit the contents of the screen
or some part thereof.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guyron@BRL-TGR.ARPA (08/22/84)
From: Ron Natalie <ron@BRL-TGR.ARPA> If you make ioctl require owner, then any setuid programs that you run will no longer be able to do ioctls. If you do the GET from fd0 and the SET to fd1, you'll really piss off the guy on tty1 because you will set his terminal with the modes from your terminal plus cbreak. -Ron