Bug#690737: at least on 3.10
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!
Reply to: