Date:	Wed, 6 Aug 2008 07:23:26 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	tvrtko.ursulin@...hos.com
Cc:	"Press, Jonathan" <Jonathan.Press@...com>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	malware-list@...ts.printk.net, Rik van Riel <riel@...hat.com>
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@...hos.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@...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@...ux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists