Messages in this thread | | | Date | Wed, 13 Aug 2008 06:54:01 -0700 | From | Arjan van de Ven <> | Subject | Re: [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
| |