Re: Out of tree module using LSM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Nov 29, 2007 10:56 AM, Jon Masters <[email protected]> wrote:
> On Thu, 2007-11-29 at 10:40 -0800, Ray Lee wrote:
> > On Nov 29, 2007 9:36 AM, Alan Cox <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux