A security hole

[John M Chambers x7780 1E342]

In article <7521 at ncoast.UUCP>, allbery at ncoast.UUCP (Brandon Allbery) writes:
> If I wasn't *real* careful with the (setuid) program which grabs incoming
> sources.misc submissions, someone could gain write access to any of my files.
> Such as my .login.  This isn't a potential security hole?  (The alternative
> is to make a certain directory world-writeable; not a sound idea in this case.)

OK, I'll bite.  Here are the permissions on my home directory and .login: 

drwxrwxr-x 21 jc       wheel        2560 Mar 24 08:30 .
-rw-r--r--  2 jc       wheel         250 Jan 29 14:53 .login

And here's the rnews command:

22531 -rwsr-sr-x 2 news news 114688 Mar 17 13:33 /news/bin/rnews   

Explain to me how someone could use this setuid-news, setgid-news program
to write into my .login file.  Now need to explain further; I do appreciate
why I wouldn't want you to do that.  But I don't quite see how this setup
makes it possible.

I do understand why I wouldn't want to turn off these setuid and setgid bits.
In my experience, rnews is very often triggered by things (like cron) that
are run by root, and I've seen a lot of problems caused by news files ending
up owned by root rather than news.  I wouldn't trust news run by root, and I
don't trust cron to correctly run things under other ids;  I've had too many
surprises there to believe that I can reliably control cron.  So the setuid
and setgid bits are needed to guarantee that cron can't start rnews up with
root permissions.  This seems to me to restrict incoming news to only those
directories with news write permissions.  If I'm wrong, I'd like to know, so
I can start looking for other ways to do the job.


-- 
[Send flames; they keep it cool in this lab :-]

Am I the same John Chambers as jc at minya?  You decide....
Hint:  That guy over at ut-sally is an imposter.  (;-)