linux-kernel - Re: Out of tree module using LSM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 Nov 2007 11:11:29 -0800
From:	"Ray Lee" <ray-lk@...rabbit.org>
To:	"Jon Masters" <jonathan@...masters.org>
Cc:	"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: Re: Out of tree module using LSM

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.
> >
> > 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/