lkml.org 
[lkml]   [2008]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access scanning
    On Wed, 13 Aug 2008 06:46:46 -0400
    "Press, Jonathan" <Jonathan.Press@ca.com> wrote:

    > > -----Original Message-----
    > > From: Pavel Machek [mailto:pavel@suse.cz]
    > > Sent: Wednesday, August 13, 2008 6:28 AM
    > > To: Press, Jonathan
    > > Cc: davecb@sun.com; Arjan van de Ven; Mihai Don??u; Adrian Bunk;
    > > tvrtko.ursulin@sophos.com; Greg KH; linux-kernel@vger.kernel.org;
    > linux-security-
    > > module@vger.kernel.org; malware-list@lists.printk.net
    > > Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a
    > linuxinterfaceforon access
    > > scanning
    > >
    > > > I think everyone understands one side of the threat model, that is
    > Linux machines
    > > being carriers of infections aimed at other platforms. There are
    > > many
    > ways that
    > > such infections can be stored, and many ways in which they can be
    > communicated
    > > to the target machines. There are so many that it would not be
    > effective or efficient
    > > for each such transfer application to be able to handle its own
    > malware scanning,
    > > which is the short statement of why centralized AV protection with
    > notification
    > > assistance from the kernel is appropriate.
    > > >
    > >
    > > No.
    > >
    > > Proposed kernel solution did not work -- there still was write
    > > vs. read race. You are right that it is not ok for each application
    > > to do its own malware scanning, but libmalware.so that handles the
    > > scanning seems very reasonable.
    > >
    > > And as applications _need_ to be modified for the write vs. read
    > > race to be solved, libmalware.so looks like a way forward.
    > >
    > Pavel
    >
    > I am not sure what you are suggesting, and I may have missed the
    > libmalware proposal (I don't see any mention of that specific idea in
    > any other message). However, just to be clear... At no point did we
    > suggest that the kernel would do any scanning. What we have been
    > interested in is a mechanism that can allow a scanning application to
    > be notified by the kernel of specific i/o events, for those events to
    > be blocked by the kernel until a user-space scan is done, and then the
    > user-space scan sends back allow or deny, at which point the i/o event
    > returns to the caller -- either success or error. This is the only
    > way that malware can be guaranteed of being detected when it is used
    > (for local application purposes or for transmission to another
    > platform) or created.

    this is a very broad statement that ignores the LD_PRELOAD approach,
    and thus not true.


    >
    > Also, a solution that requires applications to be modified will not
    > work, because there is no way that we would be able to get ALL
    > applications on the machines to be modified in the required ways. If
    > ANY applications are not so modified, then you have an unacceptable

    you don't need to modify applications to make them use a library...


    --
    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-13 15:57    [W:4.303 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site