> -----Original Message-----
quoted text
> From: David.Collier-Brown@sun.com [mailto:David.Collier-Brown@sun.com] On
> Behalf Of David Collier-Brown
> Sent: Monday, August 11, 2008 12:11 PM
> To: Arjan van de Ven
> Cc: Mihai Donțu; Adrian Bunk; tvrtko.ursulin@sophos.com; Greg KH; Press,
> Jonathan; 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
> 
>   Perhaps I could try: the AV folks are trying to prevent the
> execution of either modified normal binaries/files or
> specifically exploit binaries/files, by machines for which the
> files are executable or interpretable.
> 
>   The experience of those communities is predominantly
> with DOS/Windows executables and interpretable files, which
> they have difficulty generalizing from.
> 
>   In principle, they could be targeted at any machine, so any
> mechanisms should be applicable to native executables and
> interpretables as well as foreign ones.


You know, that's actually a very good statement of the model.

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.

So, putting that aside, David's statement is a reasonable summary of the nature of the other side of the model, the native attacks we are trying to protect against.  That is, on any platform, not just Linux, we don't always know ahead of time what kind of attack can be launched and how it would be done.  Experience has shown that no one knows enough about every piece of software on every machine to be able to know ahead of time what vulnerabilities there are that can be exploited.  Therefore, we adopt a methodology that allows us to be fairly general.  The signature matching approach allows us to find the signatures of either specific exploit binaries or corrupted normal binaries that our collection and research activities have identified as malware.

It is true that most of our experience is with DOS and Windows, and that the types of attacks that can be launched there are not easy to generalize to other platforms.  However, that does not mean that non-Windows platforms like Linux are therefore immune, or that we are tilting at windmills to say that we address non-Windows infections.  There are many specific forms of malware on non-Windows platforms that we identify in the same way that we identify them on Windows.

In a sense the reason I have found the question about "threat model" to be so difficult to answer is that the basic unpredictability of the attack makes the answer in essence:  "Anything".  That is, it essentially doesn't matter what the threat is or how malware is implemented, except that we know that it exists, both in theory and in practice, and we have an effective way of detecting and removing it.


Jon Press