RE: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interfaceforon access scanning

["Press, Jonathan" <Jonathan.Press@ca.com>]

I'm not sure if this is off the direct idea of this thread, or if I am
possibly missing the whole point.

However, I want to point out that scanning on close is still an integral
part of AV protection, even if intercepting opens and execs
theoretically catches everything.

You can say that there are four parts to the malware life cycle --
getting on a machine, residing there, causing local damage, and
propagating elsewhere.  It is part of the philosophy of AV protection
that you do everything you can to prevent all of them.  That's why there
are scans on close, scheduled scans, and scans on open.  Most of our
users employ all three and do not rely on one or two.  If an infection
arrives on a machine and finds a home because it is assumed that it will
be caught when it is opened for use, then it is just one more compromise
away from doing damage and/or spreading.


Jon Press



-----Original Message-----
From: Arjan van de Ven [mailto:arjan@infradead.org] 
Sent: Tuesday, August 05, 2008 1:39 PM
To: Eric Paris
Cc: Press, Jonathan; Greg KH; linux-kernel@vger.kernel.org;
malware-list@lists.printk.net; linux-security-module@vger.kernel.org
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux
interfaceforon access scanning

On Tue, 05 Aug 2008 13:19:56 -0400
Eric Paris <eparis@redhat.com> wrote:

> If you can outline the design of a better method that meets your needs
> I'd be glad to try to code it.  In your mind how do you see programs
> being able to exclude others while not being a security risk? 


ok so lets be specific.
You are trying to prevent an application from opening a "damaged" file,
or from someone starting a "damaged" file.
You are not trying to prevent anything once you have executed a damaged
file; once you execute one of these for this part it's game over (to
limit the damage other tools like selinux exist, but are outside the
scope of talpa).

So... as long as /sbin/init isn't compromised... intercepting exec and
open (in all variants) is all you need.

And this can be done from userland with the preload: the "workaround"
from the preload assumes you've already executed malicious code, which
is outside of your protection scope.

What am I missing?

-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org