From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761394AbYHPEQl (ORCPT ); Sat, 16 Aug 2008 00:16:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758530AbYHPEJ6 (ORCPT ); Sat, 16 Aug 2008 00:09:58 -0400 Received: from casper.infradead.org ([85.118.1.10]:34804 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758611AbYHPEJz (ORCPT ); Sat, 16 Aug 2008 00:09:55 -0400 Date: Fri, 15 Aug 2008 21:09:42 -0700 From: Arjan van de Ven To: "Peter Dolding" Cc: david@lang.hm, rmeijer@xs4all.nl, "Alan Cox" , capibara@xs4all.nl, "Eric Paris" , "Theodore Tso" , "Rik van Riel" , davecb@sun.com, linux-security-module@vger.kernel.org, "Adrian Bunk" , "Mihai Don??u" , linux-kernel@vger.kernel.org, malware-list@lists.printk.net, "Pavel Machek" Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon access scanning Message-ID: <20080815210942.4e342c6c@infradead.org> In-Reply-To: References: <18129.82.95.100.23.1218802937.squirrel@webmail.xs4all.nl> Organization: Intel X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 16 Aug 2008 13:57:50 +1000 "Peter Dolding" wrote: > Anti-Virus has been for years about chasing the threat. Lets try to > get in front of it. You thread model needs a major update its > incomplete. > The problem TALPA is trying to solve is only part of the puzzle. Everyone recognizes that. It's a very relevant part of the puzzle (in corporate context at least), but it's very much so not a complete puzzle. Does that mean we shouldn't deal with this just because it's incomplete? Absolutely not! (nor should we do something that has no value.. but that's not the case; the model that Erik described is quite well defined as "do not give ''bad' content to applications/exec". There is clearly value in that (even though it's not defined what 'bad' is other than 'program X or Y says so', but for now we have to live with that; if it bothers you just think "clamAV"). The implementation idea (have a flag/generationnr in the inode for 'known good', block on read() and mmap(), and schedule async scans in open or on dirty) seems to be quite solid although several details (async queueing model for example but also the general dirty notification system) need to be worked out. Sadly what you're doing is throwing up smoke and just saying "it doesn't solve world hunger as well so it's bad". Please do yourself a favor and stop that before people totally start ignoring you. -- 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