linux-kernel - Re: scanner interface proposal was: [TALPA] Intro to a linux interface for on 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] [day] [month] [year] [list]

Date:	Mon, 18 Aug 2008 05:16:58 -0700 (PDT)
From:	david@...g.hm
To:	rmeijer@...all.nl
cc:	Casey Schaufler <casey@...aufler-ca.com>,
	Peter Dolding <oiaohm@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, capibara@...all.nl,
	Eric Paris <eparis@...hat.com>, Theodore Tso <tytso@....edu>,
	Rik van Riel <riel@...hat.com>, davecb@....com,
	linux-security-module@...r.kernel.org,
	Adrian Bunk <bunk@...nel.org>,
	Mihai Don??u <mdontu@...defender.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	malware-list@...ts.printk.net, Pavel Machek <pavel@...e.cz>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: scanner interface proposal was: [TALPA] Intro to a linux     
 interface for on access scanning

On Mon, 18 Aug 2008, Rob Meijer wrote:

> On Mon, August 18, 2008 02:58, david@...g.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/