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: <20080806064418.6afa0672@infradead.org>
Date:	Wed, 6 Aug 2008 06:44:18 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	"Press, Jonathan" <Jonathan.Press@...com>
Cc:	"Rik van Riel" <riel@...hat.com>, "Greg KH" <greg@...ah.com>,
	"Eric Paris" <eparis@...hat.com>, <linux-kernel@...r.kernel.org>,
	<malware-list@...ts.printk.net>,
	<linux-security-module@...r.kernel.org>
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon
 access scanning

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.

-- 
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/