Klamav

[Kevin Kofler]

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).

        Kevin Kofler