Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access scanning

[Arjan van de Ven <arjan@infradead.org>]

On Tue, 5 Aug 2008 16:15:32 -0400
"Press, Jonathan" <Jonathan.Press@ca.com> wrote:

> 
> > Also, it seems to me that for my purposes, close is discrete enough.
> It
> > tells me that there is now something out there that should be looked
> at.
> 
> So, if you hook glibc to catch all calls to close, is that sufficient?
> 
> [JON PRESS]  Let's see...I'm going to use inotify for some events,
> glibc for others, and this API for the rest.  Would you really want
> to write an application like that?

so you have to do 2 cases:

1) inotify to notice files changing
 (no need to hook glibc for that, and no need to hook close() since you
 already get a notify for the change)

This is to catch the *creation* of "bad" content (say a browser saving a
download or somesuch)

By nature this is asynchronous for both performance and "what could you
do if" reasons.
(but so would the close() scan be, and again please explain how you
deal with write-to-mmap-after-close)

2) A synchronous check on open() or exec()

This is to prevent *use* of "bad" content, either by an application
opening a bad file, or by executing a "bad" program. 

For neither do you need to hook the kernel; ld preload works great for
this. 

This does assume that at some point you have a transition from "ok"
program to the first time you run a "bad" one (via exec or open); and
that you catch it at that point.

I don't yet buy the argument "but what if the virus corrupted your ld
preload", because if it can do that your own virus scanner is also
corrupted.


Can you explain what gap is left after you do these two things?



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