Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753260AbYHRMRc (ORCPT ); Mon, 18 Aug 2008 08:17:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751946AbYHRMRW (ORCPT ); Mon, 18 Aug 2008 08:17:22 -0400 Received: from mail.lang.hm ([64.81.33.126]:40264 "EHLO bifrost.lang.hm" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750947AbYHRMRV (ORCPT ); Mon, 18 Aug 2008 08:17:21 -0400 Date: Mon, 18 Aug 2008 05:16:58 -0700 (PDT) From: david@lang.hm X-X-Sender: dlang@asgard.lang.hm To: rmeijer@xs4all.nl cc: Casey Schaufler , Peter Dolding , 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 , malware-list@lists.printk.net, Pavel Machek , Arjan van de Ven Subject: Re: scanner interface proposal was: [TALPA] Intro to a linux interface for on access scanning In-Reply-To: <17956.82.95.100.23.1219056651.squirrel@webmail.xs4all.nl> Message-ID: References: <17956.82.95.100.23.1219056651.squirrel@webmail.xs4all.nl> 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: 2464 Lines: 56 On Mon, 18 Aug 2008, Rob Meijer wrote: > On Mon, August 18, 2008 02:58, david@lang.hm wrote: >> since many people apparently missed this writeup I'm re-sending it. >> >> please try to seperate disagreement with the threat model this is >> addressing with disagreement with the design. > > agreed. > > >> 3. (and the biggest batch) statements that this won't protect against >> problem X (where X was not in the threat model) >> >> arguing againt this design is the wrong thing to do. argue against the >> threat model instead, preferrably by proposing a different threat model >> and allowing for a debate of which is appropriate. >> >> the threat model that was sent out (by others, not by me) basicly boils >> down to "don't allow programs to access/execute 'unscanned' data. don't >> try to defend against actions of programs already running or >> malicious user actions" there were further comments listing things it's >> not trying to cover. > > I have multiple issues with this model: > > 1) It is basically the model used by black-list centric virus scanners. > Recent demonstrations have shown how apparently easy it is to bypass > blacklist technology, thus investing in providing hooks for technology > that is arguably quickly becoming obsolete is IMO questionable. > 2) Whitelisting, while a great partial solution is insufficient to become > a solution all by itself. It does not lend itself to the single > allow or kill approach above. > 3) Most of the malware problem comes from the fact that software runs with > all of the user her privileges while it could run with much less (least > even) without (much) possibilities of doing malice. > > The combination of these makes me come to the conclusion that a much more > viable alternative model would be: > > "Don't allow (whitelist) unscanned programs to run with user privileges. > Allow unscanned and untrusted programs to run with (dynamic) least > authority. No blacklist scanning." I think this model can support your mode of operation since the checking software is run in userspace (initially as the user) couldn't the 'scan' kicked off by the absense of a 'scanned-by-' tag trigger the 'least authority' mode? 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/