[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080805213659.596eac48@lxorguk.ukuu.org.uk>
Date: Tue, 5 Aug 2008 21:36:59 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Greg KH <greg@...ah.com>
Cc: Eric Paris <eparis@...hat.com>, malware-list@...ts.printk.net,
linux-kernel@...r.kernel.org
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for
on access scanning
On Tue, 5 Aug 2008 10:01:43 -0700
Greg KH <greg@...ah.com> wrote:
> On Tue, Aug 05, 2008 at 12:25:03PM +0100, Alan Cox wrote:
> > > Again, do it all in userspace (caching, and scanning). I still really
> > > don't see the need to do this in the kernel becides it being "the way
> > > people have always done it."
> >
> > We don't have notifiers for file segment changes that are scalable that
> > far.
>
> I agree, but if we did, would that help out a lot here? Lots of other
> groups of people are needing/asking for something like this and if
> someone can finally get it together to post something useful, that might
> be a very good thing.
A scalable notification scheme would certainly sort out content indexing
systems more nicely. Open notifiers that scale let you do path indexing
("People who opened file X also opened file Y" - both for optimising disk
layouts and for application level 'what do I prompt the user with' stuff)
The only thing I can see that is actually needed to get the whole thing
working sweetly even for the virus and HSM cases is an LSM willing to
bounce some opens via a user space helper. Even without that you could
label content 'dubious' on close and relabel it accordingly in the
asynchronous scanning app
Alan
--
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