clamd handicraft work

[Stephen J. Smoogen]

On 7/19/05, Warren Togami <wtogami at redhat.com> wrote:
> Nathan Grennan wrote:
> >
> >   I am willing to work with someone on creating clamav-(package)
> > packages if it is what it takes to get rid of the current clamav
> > package.
> >
> 
> Are you totally missing the point?  The clamav-(something) packages are
> only instances of service script files to provide a service for a
> specific user of clamd.
> 

I think the main problem I see with these clamav conversations is a
lack of understanding between the packagers and the people using it. 
It might help if the design decisions need to be better communicated
than telling someone to go to bugzilla.us to find out why things were
done this way. Adding a %doc Fedora-Packaging-Design-Faq.txt would be
useful. [It is useful to have this in the package because there are
too many situations where you have to troubleshoot a security package
and you dont have internet access for some reason.]

Here are the questions that I have asked myself about clamav:

Why did you not use the DAG model for packaging up clamav?

[We did a thorough security review and realized that there were
possible problems with the DAG packaging of clamav. These included...
]

Why is clamav-data and clamav-update seperate from clamav when they
get updated at the same time and are pretty much needed for every box
using clamav?

[We thought it was a fun and new way to package up things.]

How does one write a clamav-amavis, clamav-exim, clamav-mimedefang,
clamav-postfix, etc RPM?

[Answer seems to be "Help the developer update scripts in clamav-devel
to meet your needs." ]

Why are these written as seperate script instances?

[Answer seems to be "The best security design for running clamav is to
seperate each use of clamav to a seperate user or UID. This helps from
any possible compromises in clamav from affecting multiple services."]

Why doesnt clamav run as root?

[Answer seems to be "Running clamav as root is not a good idea. ..
fill in the usual compromise as root problems.]




-- 
Stephen J Smoogen.
CSIRT/Linux System Administrator