On Mon, August 18, 2008 02:58, [email protected] 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."
Rob
On Mon, 18 Aug 2008, Rob Meijer wrote:
> On Mon, August 18, 2008 02:58, [email protected] 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