Cc: <davecb@...>, Arjan van de Ven <arjan@...>, Mihai Don??u <mdontu@...>, Adrian Bunk <bunk@...>, <tvrtko.ursulin@...>, Greg KH <greg@...>, <linux-kernel@...>, <linux-security-module@...>, <malware-list@...>
linux-security-
linuxinterfaceforon access
Linux machines
ways that
communicated
effective or efficient
malware scanning,
notification
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.
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
malware hole. The only solution that really works is one that
guarantees that all applications are involved, which is why the kernel
has to be involved in some way. It's the only centralized authority
that can stick its nose into all of the required activities.
Whether the specific proposal currently on the table handles all the
issues or not is to me a separate point.
Jon Press
--
