[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <g7qccj$6m0$1@taverner.cs.berkeley.edu>
Date: Mon, 11 Aug 2008 21:53:23 +0000 (UTC)
From: daw@...berkeley.edu (David Wagner)
To: linux-kernel@...r.kernel.org
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon
access scanning
David Collier-Brown writes:
>Arjan van de Ven wrote:
>> we do still appreciate your description, since I don't think there's a
>> clear "here's what we really try to protect against" statement yet.
>
> Perhaps I could try: the AV folks are trying to prevent the
>execution of either modified normal binaries/files or
>specifically exploit binaries/files, by machines for which the
>files are executable or interpretable.
1. We already know how to prevent/detect modifications to
normal binaries. See Tripwire etc. As far as I know, no new
kernel technology is needed.
2. Preventing execution of exploit binaries/files is not a
well-defined problem, because there is no reliable way to recognize
an exploit binary. If this is the problem definition, then in
practice it will probably be impossible to meet this goal exactly.
So this sounds like a kind of "aspirational" goal, but presumably
it's not the whole story and it's not a full problem statement, and
we need to know more precisely what the goals do and don't include.
At some point we have to get beyond slogans and philosophies and
move on to specifics.
3. Let me point out that you snipped a key line from Arjan van
de Ven's email:
Answering Ted's questions would be a really good start...
And in particular you haven't answered Ted's questions. I agree
with Arjan's email: I think we have to know the answer to Ted's
questions before we can have a meaningful technical discussion.
What's the threat model? What problem, specifically, are we
trying to solve? What are the security goals? Given that there
are no silver bullets and there's no way to stop all attacks, which
class of risks are or aren't in scope?
Bottom line: It's helpful to try to understand each other's point
of view and where we're each coming from, and this may be a start
on that, but I don't think this answers the questions yet. It seems
like we're still talking past each other.
--
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