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@xxxxxx> wrote:

-----Original Message-----
From: Pavel Machek [mailto:pavel@xxxxxxx]
Sent: Wednesday, August 13, 2008 6:28 AM
To: Press, Jonathan
Cc: davecb@xxxxxxx; Arjan van de Ven; Mihai Don??u; Adrian Bunk;
tvrtko.ursulin@xxxxxxxxxx; Greg KH; linux-kernel@xxxxxxxxxxxxxxx;
linux-security-
module@xxxxxxxxxxxxxxx; malware-list@xxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--
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/

Relevant Pages