Setuid write command

rsm%brl-bmd at sri-unix.UUCP rsm%brl-bmd at sri-unix.UUCP
Sat Jul 9 12:44:53 AEST 1983


From:      Robert S. Miles <rsm at brl-bmd>

       If you change write to be set-uid root, you must add in two things:
   One is a setuid(geteuid()) before the exec for a shell escape.  almost
   as important, but less obvious, is that you must scrutinize the optional
   ttyname arguement to prevent things like
 
	   write user ../etc/passwd

   This would of course be disasterous...

First -- If you do a setuid(geteuid()) before the shell escape you're
probably going to be **very** sorry later.  I hope "andrew" meant to
say setuid(getuid())!  There IS a big difference!  I think it would be
even better if the program did the setuid(getuid()) immediately after
opening the terminal since the open() is all that it needs its privileges
for anyway.

Second -- All the write commands I've ever seen only let you write to
a terminal name which exactly matches one of those currently in use, as
specified in /etc/utmp, so there shouldn't be much of a problem unless
you happen to leave /etc/utmp writable.  But this is a valid concern.

Last -- if you're going to go to all this trouble to keep terminals
protected then also remember to close the file descriptor to the terminal
before doing the shell escape in the child!  For systems that have it, you
might just want to set "close on exec" (FIOCLEX) after opening the terminal.
That way you're sure that no unauthorized programs will get a chance to
write any data onto that terminal.

Wizards:  How many programs do you have that forget to close down file
descriptors before handing them off to the shell which then hands them
off to some other program that may be happy to use them in ways which
were not intended?  Many programs which use shell escapes that I've
encountered forget to close down private file descriptors before forking
off children unrelated to their original purpose.  Given the right
circumstances oversites like this could cause "severe data integrity
loss", a.k.a. security problems.

					-Bob Miles, rsm at BRL



More information about the Comp.unix.wizards mailing list