RE: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforonaccess scanning

[Press, Jonathan]

> -----Original Message-----
> From: Theodore Tso [mailto:tytso@xxxxxxx]
> Sent: Friday, August 15, 2008 7:35 AM
> To: Alan Cox
> Cc: Rik van Riel; Pavel Machek; Press, Jonathan; davecb@xxxxxxx;
Adrian Bunk;
> Mihai Don??u; linux-kernel@xxxxxxxxxxxxxxx;
malware-list@xxxxxxxxxxxxxxxx; linux-
> security-module@xxxxxxxxxxxxxxx; Arjan van de Ven
> Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to
alinuxinterfaceforonaccess
> scanning
> 
> On Fri, Aug 15, 2008 at 09:35:13AM +0100, Alan Cox wrote:
> > We shouldn't need to care what people do with good interface. What
> > matters is in your airport example is that at the infrastructure
level
> > there is a point you can choose to do scanning and we agree where.
> > Whether people use this to provide a Starbucks or goons with rubber
> > gloves who take away babies milk is an application layer problem.

An interesting example is (please don't scream everyone -- it's just an
illustration of one approach to the problem) NetWare.  (In fact, we
still have a lot of active NetWare customers, so the fact that it is an
archaic OS is not really the issue.)  NetWare takes the kitchen-sink
approach.  It has an interface that allows notification on a whole host
of i/o events, way more than we have ever found useful, and the
application can register for the ones it wants and go from there.  The
kernel does not care what the application's inherent logic is, as long
as the application passes control back with some appropriate return
information (in other words, allow or deny in the context of malware)
within a reasonable amount of time.  I have no idea what purpose it was
written for originally, and there are flaws to be sure, but I know that
it is used successfully for HSMs and anti-malware products.  


> If it's a good interface that also happens to address HSM/DMAPI
> functionality, as well as a more efficient way for trackerd to work, I
> agree completely.  I think you will agree the proposed TALPA interface
> is a bit too virus-scanner specific, though?  Especially with explicit
> talk of specialized (persistent or not) "clean/dirty/infected" bits
> that the kernel would store in the inode for the benefit of the AV
> scanner?  That's rather optimized for the goons-with-rubber-gloves
> that-make-mothers-drink-their-own-breast-to-prove-it's-not-explosives
> crowd, I think...

That may just be a question of terminology.  If the bits are construed
not as clean/dirty/infected, but as "I care about this file" vs. "I
don't care about this file" then the rubber gloves come off.


Jon Press

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