Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756776AbYHOFiv (ORCPT ); Fri, 15 Aug 2008 01:38:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751065AbYHOFin (ORCPT ); Fri, 15 Aug 2008 01:38:43 -0400 Received: from mail.lang.hm ([64.81.33.126]:51850 "EHLO bifrost.lang.hm" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750982AbYHOFim (ORCPT ); Fri, 15 Aug 2008 01:38:42 -0400 Date: Thu, 14 Aug 2008 22:38:13 -0700 (PDT) From: david@lang.hm X-X-Sender: dlang@asgard.lang.hm To: Eric Paris cc: 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 , Arjan van de Ven Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon access scanning In-Reply-To: Message-ID: References: <20080813125638.GB6995@ucw.cz> <20080813135207.CC08C3765BC@pmx1.sophos.com> <20080814125410.GA2262@elf.ucw.cz> <2629CC4E1D22A64593B02C43E855530304AE4BE3@USILMS12.ca.com> <20080814223918.GC6370@elf.ucw.cz> <20080814200005.6b363716@bree.surriel.com> <20080815004335.GF13048@mit.edu> <1218769209.16613.31.camel@localhost.localdomain> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1409 Lines: 30 On Thu, 14 Aug 2008, david@lang.hm wrote: > On Thu, 14 Aug 2008, david@lang.hm wrote: > >> again, libmalware.so is not referring to any specific body of code, it's >> referring to the concept that the handling of open/mmap/read/etc and >> scanning is done via a userspace library rather then by the kernel. if >> everyone can agree on that concept then hashing out the details of _which_ >> library it gets put in is a smaller detail. > > one reason to layer scanners is that you could have one that just checks to > see if the file was deployed from a OS package, if it was (and still has the > same hash as the package manager thinks it should have) it sets a flag that > other scanners could look for (if they see it they can skip scanning the > file) actually, instead of trying to have one scanner trust the results of another, a better approach would be for libmalware to look for the package manager approval and if it finds that it could skip asking the other scanners to look at it. this sort of thing can easily be done in userspace libraries, but you definantly would _not_ want to do in a kernel-level enforcement mechanism. David Lang -- 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/