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:	Sun, 02 Dec 2007 14:44:48 -0500
From:	Valdis.Kletnieks@...edu
To:	Pavel Machek <pavel@....cz>
Cc:	tvrtko.ursulin@...hos.com, Andi Kleen <andi@...stfloor.org>,
	ak@...e.de, linux-kernel@...r.kernel.org
Subject: Re: Out of tree module using LSM

On Sat, 01 Dec 2007 08:43:32 GMT, Pavel Machek said:

> So what you are trying to do is 'application may never read bad
> sequence of bits from disk', right?

No, in many of the use cases, we're trying to do "if application reads certain
specified sequences of bits from disk we know about it", which is subtly
different.  Often, *absolute* prevention isn't required, as long as we can
generate audit trails and/or alerts...

> Now, how do you propose to solve mmap(MAP_SHARED)? The app on the other cpu may
> see the bad bits before kernel has chance to see them.

For many usage cases (such as virus scanners), mmap() isn't really an issue,
because if another process is *already* trying to mmap() the file before it's
even finished downloading from the network interface, you have other problems.
In that case, what you *really* want to be hooking is read() from a network
socket, not a disk file - and I don't think you can mmap() a socket anyhow,
right?

Similarly, if you're using these exit points to do *indexing*, you really don't
care if it got mmap()'ed - at worst, it isn't indexed until the other CPU gets
around to it.

Content of type "application/pgp-signature" skipped