Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!tut.cis.ohio-state.edu!mailrus!b-tech!zeeff
From: zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff)
Newsgroups: news.software.b
Subject: Re: Cnews security
Message-ID: <9500@b-tech.ann-arbor.mi.us>
Date: 28 Jun 89 15:13:15 GMT
References: <9482@b-tech.ann-arbor.mi.us> <1989Jun24.204900.24693@utzoo.uucp> <9490@b-tech.ann-arbor.mi.us> <1989Jun25.175214.13599@utzoo.uucp> <9493@b-tech.ann-arbor.mi.us> <1989Jun27.171443.2044@utzoo.uucp>
Reply-To: zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff)
Organization: Branch Technology Ann Arbor, MI
Lines: 30

>>One weak link in the chain is all it takes.  The easy secure way is 
>>for rnews (ie, the initial entry point) to be a tiny suid root program 
>>(in /usr/bin or something) that does a setuid(NEWS), setgid(NEWS) 
>>before execing the real rnews...
>
>In case you haven't noticed, relaynews does those setuids immediately on
>startup.

I've noticed and my point stands.  News owns a program that people 
will be executing with their id exposed.  This is a security problem 
if anyone ever breaks news.  You have recognized and addressed most of 
this problem by making most things bin owned.  My point is that "most" 
isn't worth much.  A suid root "wrapper" at the entry points 
eliminates the problem (you can even let news own the stuff in 
/usr/lib/newsbin, which can be convenient if the news maintainer 
doesn't have root).  

>It even goes through such a tiny setuid-root program if your
>system does not support setuid(geteuid()), which is the preferred way of
>doing this.

This is the right idea, but it's done too late (a news owned program 
has already been executed by the user) and it would have been more 
efficient to just run the setuid root program first on systems that 
need it (do it at configuration time, not run time).  


-- 
Are you making the world     |  zeeff@b-tech.ann-arbor.mi.us
a better place?              |  Ann Arbor, MI