linux-kernel August 2008 archive
Main Archive Page > Month Archives  > linux-kernel archives
linux-kernel: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a li

Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interfaceforon access scanning

From: Greg KH <greg_at_nospam>
Date: Tue Aug 05 2008 - 18:11:41 GMT
To: "Press, Jonathan" <Jonathan.Press@ca.com>

  1. No.
  2. Should I include quotations after my reply?

On Tue, Aug 05, 2008 at 02:04:26PM -0400, Press, Jonathan wrote:
> I'm not sure if this is off the direct idea of this thread, or if I am
> possibly missing the whole point.

I think you might be missing the point a bit here, as the traditional Unix model that Linux has prevents much of what the "traditional AV" products need to do, right?

> 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.

Great, then put a hook in glibc and catch all closes and then kick off your scanning.

> 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.

But this proposed patchset does not do much to prevent all of these, right?

> 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.

So how are you going about preventing the "infection from arriving" with this proposed patchset?

Isn't that something that SELinux or another LSM can prevent better?

thanks,

greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html