Re: Out of tree module using LSM
From: Ray Lee
Date: Thu Nov 29 2007 - 14:12:00 EST
On Nov 29, 2007 10:56 AM, Jon Masters <jonathan@xxxxxxxxxxxxxx> wrote:
> On Thu, 2007-11-29 at 10:40 -0800, Ray Lee wrote:
> > On Nov 29, 2007 9:36 AM, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> 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.
> >
> > In some sense it seems like the same problem faced by dynamic
> > translators such as Qemu. They really want to vet a dirtied or faulted
> > page before allowing the app to run unhindered. It's be nice to have
> > some way to do that without virtualizing the whole of userspace.
>
> Like I hinted at, you can't just "vet a page". Because a page alone is
> meaningless garbage, unless it happens to be an extremely small program,
> with headers, all nicely aligned. Most likely you don't know if a random
> page of data is code from a COFF file, ELF file, or some random crap I
> typed in at a terminal after having too much coffee.
>
> So. You'd need to scan *all the pages* of *the entire file*, every time
> that you performed any type of operation.
*blink* Really? 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. If
there's a partial match that ends at the page boundary, mark the page
as questionable, but let execution/reading continue. On the next
linear page, if the match finishes, mark that one as bad, and disallow
access. That wouldn't be very expensive (in terms of scanning effort).
But I'm by no means an anti-malware guy, so perhaps I'm spouting crap,
especially given that I've thought about this a total of five minutes.
Regardless, thanks for doing the coordination work with them, and for
interfacing them with the kernel community. I'm really going to shut
up now.
-
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/