Wow, thank you for your fast answer!
El jue, 29-08-2013 a las 10:31 +0200, Bastian Blank escribió: > On Wed, Aug 28, 2013 at 09:05:01PM -0300, Carlos R. Pasqualini wrote: > > can we have this option by default at least on Testing? > > Also for you the question: What does it bring for our users? The possibility to have a more efficient way of having an AV looking on the filesystem level for mailware, on our fileservers that runs Debian. Here we are an University on which we have ~2000 end users, using shared folders over NFS and Samba on Debian Servers. So, searching for a way to have clamav on filesystem level we go to: http://www.clamav.net/lang/en/download/third-party-tools/3rdparty-fs/ * The only open source solution that we can implement there on Debian is ClamFS which runs on userspace and the few times i have tested it had a few issues. * Samba-vscan does not seems to be maintained any more, and i haven't found anything like that for Samba4 (here, we are studying the deploy of Samba4, may be using jessy in a near future, so this is a must for us). * AVfs [http://www.fsl.cs.sunysb.edu/docs/avfs-security04/index.html] dates from 2003, http://packages.debian.org/wheezy/avfs sems not to be that project. * Dazuko has been discontinued in favor of a 'fanotify implementation' (see [http://dazuko.dnsalias.org/wiki/index.php/Linux_Submission], where the developer says "The patches here do not reflect the latest version of DazukoFS. Because of the lack of interest in DazukoFS from the Linux community, no further submissions were made. Since then, the Fedora-backed fanotify project has been accepted into mainline Linux and could be used as a replacement for DazukoFS") which is where we find "Skyld AV", which is something like DazukoFS but relying on the fanotify infrastructure. * If we can have the kernel to support SktldAV on the stock Debian Kernel, may be we can get to have an almost working solution on Jessy's freeze; if that's too optimistic, we can target jessy+1. It seems that SktldAV is almost stable by now but we need a lot more testing. > > Why does "Skyld AV" fail if it can't actually deny access but only do > passive observation? i cannot understand completely your affirmation, may be the original poster (the developer of "Skyld AV") can bring some better insight on this. With passive observation, you mean to scan for virus in a post-write step? if this is your affirmation, i think you are worng: the hole point of this type of infrastructures is to prevent the malicious code to been written on a (may be shared) partition. > > > i have googled around and cannot find any report that this option makes > > any side effect, may be i'm just looking in the wrong place. > > It is pretty deep in the access control machinery, so it can produce a > DoS. Thanks for this! i'll take it into account Best Regards / Saludos! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org