Messages in this thread | | | Date | Wed, 6 Aug 2008 07:23:26 -0700 | From | Arjan van de Ven <> | Subject | Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access scanning |
| |
On Wed, 6 Aug 2008 15:16:02 +0100 tvrtko.ursulin@sophos.com wrote:
> Arjan van de Ven wrote on 06/08/2008 14:44:18: > > > On Wed, 6 Aug 2008 08:10:53 -0400 > > "Press, Jonathan" <Jonathan.Press@ca.com> wrote: > > > > > However... This question about arguing for a flawed security > > > technique is a good one, and in a way it gets to the heart of the > > > philosophy of security. Scan-on-close is admittedly incomplete > > > as an anti-virus tool. But I don't agree that that make it > > > flawed. It is part of a repertoire of techniques for preventing > > > malware from residing on a machine. > > > > this indeed gets to the heart of the problem. > > several of us here are trying to argue that scan-on-close isn't very > > good, BUT that if you do scan-on-change (say with inotify) you do > > reach the same goal but with much better results. > > > > notice the "but" in there. What I hope will happen is that one or > > more people from the AV side (eg you and tvrtko) will actually read > > the "but" part rather than just dismissing it outright because of > > not liking your solution in the first part of it. Part of the > > answer could be "nice however our goal is <THIS> so it won't work > > because of <THAT>". At least as long as <THIS> isn't "scan on > > close" because that's not a goal, that's a means. > > > > this kind of thing seems to be indicative of the entire discussion. > > For lkml proposals, both sides need to be willing to accept > > alternative solutions for a problem (I know I am, just need to see > > why ;-).. and explain the WHY and the goal if it's not clear. > > Problems with inotify as far as I know:
finally some useful discussion ;-)
> > You can't do something like inotify("/") (made up API) but you have > to set up a watch for every directory you wan't to watch. That seems > like a waste of resources. > > Then you get back a file name, if you wan't to report it or attempt* > to scan it you have to build a pathname yourself, which means you > have to maintain the whole tree of names in memory. Even bigger waste. > > When I say attempt to scan it above I mean that we are back into the > pathanme teritorry. It is not guaranteed we will be able to open and > scan using that pathname. I don't know what inotify reports with > chroots and private namespaces, but it can certainly fail with NFS > and root_squash. So it is less effective as well as being resource > intensive.
one argument against the namespaces one is that of security; on the one hand I can see the argument of running the virus scanner in its own container, on the other hand I can see the argument of not liking cross-container access of data as a security issue by itself.
> > I think this is a good amount of flaws which shows inotify isn't > really ideal.
that is a fair list of complaints.. the question is can inotify be fixed....
-- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org
| |