Hi!

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

No.

Proposed kernel solution did not work -- there still was write
vs. read race. You are right that it is not ok for each application to
do its own malware scanning, but libmalware.so that handles the
scanning seems very reasonable.

And as applications _need_ to be modified for the write vs. read race
to be solved, libmalware.so looks like a way forward.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/