open and euid security flaw in 5.0-Current?

[Poul-Henning Kamp]

In message <Pine.NEB.3.96L.1030517102700.42953A-100000 at fledge.watson.org>, Robe
rt Watson writes:
>
>On Sat, 17 May 2003, Killing wrote:
>
>> Thanks for that Robert will do some more investigation as it does break
>> screen :(
>
>Try replacing the devfs_access() contents with solely a call to:
>
>	return (vaccess(vp->v_type, de->de_mode, de->de_uid, de->de_gid,
>	    ap->a_mode ,ap->a_cred, NULL));
>
>This should restore the traditional access controls for the controlling
>terminal.  Again, I'm not sure what the rationale is for the  new access
>controls, and want to find out before we make any changes to the base
>system, but it does strike me that screen breaking is gratuitous :-).

This is one of those areas, where the hackish way (ie: /dev/tty)
which something were implemented, leaves us with the problem of
guessing what the underlying intent actually was/is.

It used to be that /dev/tty had its own pseudo device driver, which
would do weird stunts to act on the applicable real tty device driver
for the controlling terminal of the current process.

The resulting semantics of this is that a process can always open its
controlling terminal, by opening "/dev/tty", but inconsistently, is
not guaranteed to be able open it by name:

	ssh machine -l user1
	...
	user1% date > /dev/tty		# works
	user1% date > `tty`		# works
	user1%  ls -l `tty`
	crw--w----  1 user1  tty    5,   1 May 17 20:24 /dev/ttyp1
	user1%  su - user2
	user2% date > /dev/tty		# works
	user2% date > `tty`		# doesn't work.

The change I did, was to use the "on demand device creation" feature
of DEVFS, to make /dev/tty a sort of "variant symlink" to the current
process' controlling terminal device, and thereby getting rid of a
lot of hackish code, which amongst other things, complicated locking.

	critter phk> ls -l /dev/tty `tty`
	crw--w----  1 phk  tty    5,   3 May 17 20:40 /dev/tty
	crw--w----  1 phk  tty    5,   3 May 17 20:40 /dev/ttyp3

This means that VOP_OPEN checked against the _real_ permissions of
the tty breaking the the following scenario:

	ssh machine -l user1
	...
	user1%  ls -l `tty`
	crw--w----  1 user1  tty    5,   1 May 17 20:24 /dev/ttyp1
	user1%  su - user2
	# user2 has no access to /dev/ttyp1, so /dev/tty cannot
	# be opened.

Therefore, the access check was changed to always allowing the
controlling terminal to be opened resulting in the following
much simpler semantics:
	
	% date > /dev/tty		# always works.
	% date > `tty`			# always works.

This IMO, reflects the intentions of the original /dev/tty, and
since it is simpler and contains no exceptions, I also think it
correctly reflects the "UNIX[*] philosophy" much better than
the previous behaviour.

I have no idea why or what screen(1) is doing, but from your
description it seems to rely on the undocumented fact that in certain
specific situations
	user2% date > `/dev/tty'
would fail.

In my eyes, that is a clear bug in screen(1).

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.