Date:	Sat, 16 Aug 2008 00:27:53 -0700 (PDT)
From:	david@...g.hm
To:	Valdis.Kletnieks@...edu
cc:	Arjan van de Ven <arjan@...radead.org>,
	Peter Dolding <oiaohm@...il.com>, 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 Sat, 16 Aug 2008, Valdis.Kletnieks@...edu wrote:

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

this is why there was so much preasure for them to define their threat 
model. they have donw so. if you disagree with that please suggest a 
different threat model rather then just listing various threats that their 
model doesn't cover.

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

it may not be appropriate to lock down root, it depends on what threats 
the box is under.

on the other hand, locking down root perfectly, but readily serving 
windows virii to other systems isn't good in some cases either.

security is not 'one size fits all'

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

so how _so_ you handle detecting bad data before anyone defines it as bad?

remember, the 'bad data' may be a $propriatary_media format that only 
causes problems when run with $propriatary_software on $proptiatary_OS. Or 
the 'bad data' could be a document in an open format that complies with 
the specs of that format, but a common client doesn't handle the 
legitimate file correctly.

there is no possible way to detect these ahead of someone defineing them 
as bad. you can prevent them from being exploited on the Linux system (or 
limit the damage of the exploit), that's what SELinux aims at.

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

again, that's why the push for a threat model.

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

more precisely the model is defined as "do not give 'unchecked' data to 
applications/exec" how they are checked is not defined, providing the 
hooks so that checking can be done is what we are trying to define.

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

one _very_ nice thing about the hooks currently being proposed is that 
they are useful for things besides anti-virus tools, tools that have no 
security implications at all. so even if there were no security benifit 
the hooks are still worth considering. but the fact is there is a threat 
model here that is not addressed well with other mechanisms, that is 
useful to cover.

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/

Powered by blists - more mailing lists