linux-kernel - Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access scanning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080806141656.8B44B2FE94A@pmx1.sophos.com>
Date:	Wed, 6 Aug 2008 15:16:02 +0100
From:	tvrtko.ursulin@...hos.com
To:	Arjan van de Ven <arjan@...radead.org>
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

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:

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/