After having some problems with the quality of the virus database for clamav, I looked into this software.
I came up with a number of very serious flaws in the software, that ultimately led to deciding that it was not worth the effort needed to make it work in a sane and secure manner.
The first problem came up during the installation – to a CentOS 6.5 server running postfix+amavisd, and in need of a mechanism to protect those poor people using an inferior OS from the various things that threaten them. The first part of the installation itself, was find. “rpm -ivh file.rpm”. The second step, however, wanted to do something that was really quite inappropriate – build and install two kernel modules, that are, frankly, useless. Something to do with real-time on-access virus scanning. Yeah, maybe they would be marginally useful on a fileserver running samba, but not on an email server. There was no way to avoid performing this step except to modify the post-setup.sh script and comment out lines 405-423.
That done, I ran the setup script and got the system working somewhat.
Of course, everything in the configuration file (etc/COMODO.xml – why such a ■■■■■ for caps???) is poorly documented, since it is designed by wondoze users FOR wondoze users. This is linux pal, there is no GUI on a linux server, which means that ALL configurations need to be DOCUMENTED, and all executables need to work from the console.
So turned out the section was … cmdtcpd and had to change the from 0x4e0 to 0x1a0 to make any sense at all.
And then starting and restarting the service… was unreliable. Sometimes it started correctly and worked, other times it would just randomly fail. That is really unacceptable! It needs to start up RELIABLY.
The manual database update binary… why does it need X? I don’t have X. Not even installed. You can’t forward X if you don’t HAVE X!!!
But all of this was manageable, since I could run a script to retry starting the stupid thing until it actually worked, and with the right adjustment, the database will update itself automatically (supposedly). The straw that broke the camel’s back was that there was no way to prevent it from running as ROOT.
Really? You expect me to run a binary AS ROOT? No source code to audit, and still AS ROOT? The program doesn’t do ANYTHING for which it needs root access. Amavisd feeds in emails, it checks those emails against a database and feeds the result back in to the email system. Clamav does NOT run as root. Spamassassin does NOT run as root. Amavisd does NOT run as root. Postfix does NOT run as root. Why should this 3rd party virus (cleaner?) run as root?
And yes, I tried modifying the startup scripts to run as a normal user… no dice, because the stupid thing bails when it detects that its not running as root. They try so hard that it even sees through fakeroot. I’m sure that with some work, I could get it working acceptably, but if they’re trying THAT hard to make the system non-sane and such a serious violation of normal security practices, then they can keep it.
If anybody here needs a virus scanner that actually works, and has determined that the clamav database is simply not updated frequently enough, know that clamav works very well with 3rd party databases. There is a very nice and configurable script that pulls in a bunch of 3rd party virus databases for clamav, and it really works!