| Main Archive Page > Month Archives > linux-kernel archives |
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