In-Reply-To: <20080806064418.6afa0672@infradead.org>
To: Arjan van de Ven <arjan@infradead.org>
Cc: "Press, Jonathan" <Jonathan.Press@ca.com>, linux-kernel@vger.kernel.org,
       linux-security-module@vger.kernel.org, malware-list@lists.printk.net,
       Rik van Riel <riel@redhat.com>
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access
 scanning
MIME-Version: 1.0
From: tvrtko.ursulin@sophos.com
Date: Wed, 6 Aug 2008 15:16:02 +0100
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20080806141656.8B44B2FE94A@pmx1.sophos.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2726
Lines: 62

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:

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.

I think this is a good amount of flaws which shows inotify isn't really 
ideal.

Tvrtko


Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.

Company Reg No 2096520. VAT Reg No GB 348 3873 20.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/