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. -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
