Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for onaccess scanning

From: tvrtko . ursulin
Date: Wed Aug 06 2008 - 04:42:42 EST


Eric Paris wrote on 05/08/2008 01:32:54:

> On Mon, 2008-08-04 at 15:32 -0700, Greg KH wrote:
> > Why would userspace care about these meta-file things, what does it
want
> > with them?
>
> Honstely? I don't know. Maybe someone with access to the black magic
> source code will stand up and say if most of this metadata is important
> and if so how.

In general this metadata provides more context to the event that happened.
For example reporting - log message/UI popup/centralised something can be
displayed saying which user running which application was involved with
bad stuff. Also we can find out where the user is logged in and send him a
message there.

It is more descriptive than just failing the access with -EACCESS which
becomes ambigious.

> > > 10. Filesystem exclusions
> > > -------------------------
> > > One pretty important optimization is not to scan things like /proc,
/sys
> > > or similar. Basically all filesystems where user can not store
> > > arbitrary, potentially malicious, content could and should be
excluded
> > > from scanning.
> >
> > Why, does scanning these files take extra time? Just curious.
>
> Perf win, why bothering looking for malware in /proc when it can't
> exist? It doesn't take longer it just takes time having to do
>
> userspace -> kernel -> userspace -> kernel -> userspace
>
> just to cat /proc/mounts, all of this could probably be alliviated if we
> cached access on non block backed files but then we have to come up with
> a way to exclude only nfs/cifs. I'd rather list the FSs that don't need
> scanning every time than those that do....

Agreed.

> > > Closing remarks
> > > ---------------
> > > Although some may argue some of the filters are not necessary or may
> > > better be implemented in userspace, we think it is better to have
them
> > > in kernel primarily for performance reasons.
> >
> > Why? What numbers do you have that say the kernel is faster in
> > implementing this? This is the first mention of such a requirement,
we
> > need to see real data to back it up please.
>
> In kernel caching is clearly a huge perf win. I couldn't even measure a
> change in kernel build time when I didn't run a userspace client. If
> anyone can explain a way to get race free in kernel caching and out of
> kernel redirection and scanning I'd love it :)

When you don't run an userspace client cache should not come into play
because nothing will be cached (in this iteration at least). So I guess
you meant something different here? Like not running an userspace client
and having the filter disabled (or even not) will produce very little
overhead, probably not observable without micro-benchmarking. Having an
userspace client which just replies with "allow" should have even less
performance impact because most inodes will get cached which means filter
chain will be shorter on subsequent accesses to the same inode.

In either case it will become obvious how huge performance win is to have
in kernel caching once you get the numbers. Let me know if I can help you
with that somehow.

Tvrtko


Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.

Company Reg No 2096520. VAT Reg No GB 348 3873 20.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/