lkml.org 
[lkml]   [2008]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning
    From
    Date
    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.



    \
     
     \ /
      Last update: 2008-08-06 10:45    [W:6.563 / U:0.184 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site