Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Al Viro <viro <at> ZenIV.linux.org.uk>
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access scanning
Newsgroups: gmane.linux.kernel.lsm
Date: Tuesday 5th August 2008 21:05:24 UTC (over 9 years ago)
On Tue, Aug 05, 2008 at 01:38:32PM -0700, Arjan van de Ven wrote:

> This does assume that at some point you have a transition from "ok"
> program to the first time you run a "bad" one (via exec or open); and
> that you catch it at that point.
> 
> I don't yet buy the argument "but what if the virus corrupted your ld
> preload", because if it can do that your own virus scanner is also
> corrupted.
> 
> 
> Can you explain what gap is left after you do these two things?

Actually, the real question (and the reason why I question the personal
integrity of the people in "AV community" pushing that kind of trash)
is very simple:

Where Is Your Threat Profile?

Various people had been asking for _years_ to define what the hell are you
trying to prevent.  Not only there'd been no coherent answer (and no, this
list of requirements is _not_ that - it's "what kind of hooks do we want"),
you guys seem to be unable to decide whether you expect the malware in
question to be passive or to be actively evading detection with infected
processes running on the host that does scanning.

Moreover, the answer seems to be changing back and forth to suit the needs
of the moment in the argument.  Slightly exaggregated it goes like this:

-- Why don't you do $FOO?
-- Running virus would be able to evade $FOO, of course!
-- No shit, Sherlock; it would also be able to evade much more intrusive
$BAR
you are proposing; here's how 
-- Oh, but that's not a problem; think of Linux server with Windows clients
and Windows viruses...
--
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
CD: 3ms