freebsd security - Aug 2003 - killing UUCP

Hey *, I'm getting an audit coming down the pipes and I have 2
4.6 release boxes to clean up.  I say "clean up" because they
have some requirements that I missed despite due diligence.  My
specific question is: To what extent can I get rid of UUCP?  

Aside from the SUID/SGID stuff that pops up via my finds, I
simply see no reason to have any UUCP stuff on these boxes.  Is
this stuff simply around because it is legacy and turned off so
it's a low priority?

====-----------------------------------------------------------
Emo is what happens when the glee club goes punk.       
-----------------------------------------------------------

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

On Tue, 5 Aug 2003, twig les wrote:
> Aside from the SUID/SGID stuff that pops up via my finds, I
> simply see no reason to have any UUCP stuff on these boxes.  Is
> this stuff simply around because it is legacy and turned off so
> it's a low priority?
i may just be thinking of another case, or not thinking at all...  but i
recall buildworld issues if certain users weren't in the password file.
(granted, this memory is coming from 2-3 years ago.)  as a result, i've
always just removed the SUID/SGID bits and pointed the uucp user's shell
to nologin.  i would also clean uucppublic, in particular, as it can
create a local DoS of sorts...  providing a world-writable place for local
users to fill /var (bad if your logs go there too).  however, now that
make.conf has,

#NOUUCP=      true    # do not build uucp related programs

you may be able to define that and do away with the user all together.
someone else can confirm (i've built with NOUUCP=true, but i have not
tried deleting the uucp user.)

-mrh

--
From: "Spam Catcher" <spam-catcher@adept.org>
To: spam-catcher@adept.org
Do NOT send email to the address listed above or
you will be added to a blacklist!