Message-Id: <1196729221.27258.72.camel@perihelion>
Date:	Mon, 03 Dec 2007 19:47:00 -0500
From:	Jon Masters <jonathan@...masters.org>
To:	7eggert@....de
Cc:	Ray Lee <ray-lk@...rabbit.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, tvrtko.ursulin@...hos.com,
	Al Viro <viro@....linux.org.uk>,
	Casey Schaufler <casey@...aufler-ca.com>,
	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org, Valdis.Kletnieks@...edu
Subject: newlist: public malware discussion [Re: Out of tree module using
	LSM]


On Mon, 2007-12-03 at 23:45 +0100, Bodo Eggert wrote:
> Jon Masters <jonathan@...masters.org> wrote:
> > On Thu, 2007-11-29 at 11:11 -0800, Ray Lee wrote:
> >> On Nov 29, 2007 10:56 AM, Jon Masters <jonathan@...masters.org> wrote:
> >> > On Thu, 2007-11-29 at 10:40 -0800, Ray Lee wrote:
> >> > > On Nov 29, 2007 9:36 AM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> 
> >> > > > > closed. But more importantly further access to it can be blocked
> >> > > > > until appropriate actions are taken which also applies with your
> >> > > > > example, no? Is
> >> > > >
> >> > > > That bit is hard- very hard.
> 
> >> To lift Alan's example, a naive first implementation
> >> would be to create a suffix tree of all of ESR's works, then scan each
> >> page on fault to see if there are any partial matches in the tree.
> > 
> > Ah, but I could write a sequence of pages that on their own looked
> > garbage, but in reality, when executed would print out a copy of the
> > Jargon File in all its glory. And if you still think you could look for
> > patterns, how about executable code that self-modifies in random ways
> > but when executed as a whole actually has the functionality of fetchmail
> > embedded within it? How would you guard against that?
> 
> 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.

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
with a summary and some followup.

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

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.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists