You can't scan all possible code for malware:

Take a random piece of code, possibly halting. Replace all halting conditions

using a piece of malware. Scan it. If it were possible to detect the malware

without false positives, you'd have solved the halting problem.
In practice, this does not hinder virus scanners from preventing most damage.

Therefore I think it's OK to have one.
If I had to design a virus scanner interface, I'd e.g. create a library*

providing an {open|mmap}_and_scan() function that would give me a clean

copy/really-private mapping of a scanned file, and a scan_{blob,file}()

function that would scan a block of memory/a file. Then, it's up to the

application to ensure that it uses that library. As a result, you could

e.g. run "less eicar.sh", but you could not run "bash eicar.sh"**, and an

application receiving a strangely encoded piece of malware into it's

memory has a chance of avoiding an infection without writing it to a file.

Maybe gpg < eicar.gpg.sh|sh will unintendedly work, but I don't think

scanning pipes would be easy anyway. OTOH, maybe the library would make

it feasible at all, provided the malicious code is not located way before

the signature.
Off cause I'd need to do something about binaries. At first glance, this

does not seem too bad, since there is a way to run ld*.so. I'd just use it

to enforce a preloader for static binaries, too. (I'm glad I can leave the

implementation details to somebody else.-)
*  Without having a virus scanner installed, this library will just NOOP

   by default.
** Bonus: I can unzip open_office_file; rm macros; zip open_office_file.

   OTOH, the scanner should provide a cleaner for those simple cases.
--

Good. I think you got the point of my sarcasm. My *point* was that we

have two different camps of people here:
* Those who think some solution is better than none.

* Those who want an unobtainable, perfect solution.
I'm not criticising, each has their position. However, I was attempting

to explain that I do fully "get it" by running through an example of how

to work around more elementary on-access scanning schemes. I know that

(no matter what marketing exists to the contrary), it is never possible

to have perfect anti-malware software. But I do think there is a time

and a place for Linux to help make some folks feel safer - on access

file scanning isn't evil, and you don't have to use it! Freedom! :-)
Having spoken to a few people, I've created the following mailing list,

so we can rant away and come up with a list of requirements to present

for further discussion. Note that this is a case where I actually expect

people to be *happy* with yet another email list :-) 
http://lists.printk.net/cgi-bin/mailman/listinfo/malware-list
Please sign up, and encourage interested third parties to do so too.

Let's work this all out. Then I'll come back sometime over the holidays
Although I'm open to the idea, I'm almost 100% convinced that nobody is

going to buy modifying userspace applications one at a time. I think

there is a legitimate feeling of this needing to be massaged by the

kernel on some level. But I might be wrong - don't flame me.
Jon.
--

But we are talking about malicious programs, and so

there is a common motto:

"Poor Security Can Be Worse Than No Security", so

in this field often "none" is better that "some"
Really i don't understand why you push such module.

Malicious software in few generation (few years)

will use alternate methods. So the linux kernel

will be worse (and maybe will expose more bugs because

of complexity, and no problem are solved) but no

problem are solved.
See windoze: it is a patch after an other, so

the system is complex, unmaintainable and surely

not more secure. or do you want to change our behavior

as windows users: they compress files before to send

it, because of antiviruses policies.
If antiviruses will add security, we will not

have such big bot-nets and worms from the concurrent

OS.  Antiviruses offers only a short term cure.
ciao

--