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



    \
     
     \ /
      Last update: 2008-08-05 20:07    [W:4.182 / U:0.236 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site