Klamav

[John Aldrich]

On Saturday 18 April 2009, Kevin Kofler wrote:
> John Aldrich wrote:
> > What sort of sense does it make to provide Klamav, but to not include
> > Dazuko? If KlamAV *requires* Dazuko, then you should provide it when
> > you install Klamav. However, if there's no need for it, why does
> > KlamAV refuse to work without Dazuko?
>
> Klamav _works_ without Dazuko, you can scan files with it just fine.
> What does not work is on-access scan, which is what Dazuko provides.
>
> The big problems with Dazuko are:
> * It's an out-of-tree module, so it's unlikely to be allowed into Fedora
> proper (the kernel maintainers would have to accept the patch,
> standalone kernel module packages are banned in Fedora) unless/until it
> gets merged upstream. It would have to be packaged for RPM Fusion.
> * Until recently it kept breaking with stock Fedora kernels. There used
> to be 2 ways to use Dazuko with a 2.6 kernel:
> - As a LSM module: impossible without recompiling the kernel because the
> capabilities module which is builtin (not a module) in the Fedora kernel
> doesn't allow stacking any other LSM module on top of it. (At least that
> was the case at a time.)
> - By hooking some system calls: this kept running into Fedora's
> anti-rootkit protections. I got it working at one point (I submitted a
> patch to Dazuko upstream which unprotects the memory page before
> overwriting the syscall, drawing much ire from the Fedora kernel
> maintainer), but security got strengthened and this no longer works (I'm
> sure it's still possible to unprotect the memory in some way as the
> module runs inside the kernel, but nobody had the time or willingness to
> figure it out).
> These days, with DazukoFS, that problem should be finally solved though.
> That said, stackable file systems may have their own problems, I'm not
> familiar with DazukoFS as I've never tried it. One documented serious
> issue
>
> is this:
> > - DazukoFS does not support writing to memory mapped files. This
> > should not cause the kernel to crash, but will instead result in the
> > application failing to perform the writes (although mmap() will appear
> > to be successful from the application's viewpoint!).
>
> which looks badly broken to me, a lot of applications will just not work
> and even silently lose data over DazukoFS!
> * I'm not sure anybody audited Dazuko for TOCTOU (time-of-check
> time-of-use) issues: some on-access scanners can be bypassed by
> exploiting those race conditions.
> * ClamAV is too slow for on-access scanning. If you try having ClamAV do
> on-access scanning on your entire system, it slows down a lot.
>
> Keeping in mind that GNU/Linux is not a prime target for viruses, I'm
> not sure on-access scanning is that useful. You may want to just
> explicitly scan those files you're exchanging with other operating
> systems instead (and you can do that with Klamav without Dazuko).
>
If Dazuko is not required, why did KlamAV complain that it wasn't 
installed? I installed the F10 package and when I went to do a scan it 
griped about missing Dazuko. So, someone, somewhere (in my opinion) forgot 
to tell KlamAV that it no longer requries Dazuko.

I do realize that GNU/Linux is not a good target for virii, however, that 
doesn't mean that we don't want to scan for virii, as some people will be 
allowing windows users to read/write files, including Windows executables on 
their systems.