linux-kernel - Re: [PATCH 1/2] LSM: Do not apply mmap_min_addr check to PROT

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:	Sat, 22 Oct 2011 21:41:08 +0300
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Roland McGrath <roland@...k.frob.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	James Morris <jmorris@...ei.org>,
	Eric Paris <eparis@...isplace.org>,
	Stephen Smalley <sds@...ho.nsa.gov>, selinux@...ho.nsa.gov,
	John Johansen <john.johansen@...onical.com>,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] LSM: Do not apply mmap_min_addr check to PROT_NONE mappings

On Sat, Oct 22, 2011 at 9:32 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> So I was looking for some *other* reason for the patch.
>
> Because, quite frankly, "security hardening" is absolutely *not* a
> reason to do it - complex security is not "hardened", it's just
> "harder and more likely to be buggy".

Btw, if the only concern is "you don't want to elevate the selinux
denial to be some user-visible thing", then I'd suggest attacking
*that* issue directly.

For example, maybe we could fail the PROT_NONE mmap (ie not actually
create any mapping at all, and certainly not create anything that is
then mprotectable), but return success and not elevate it to be
reported.

But then it really is important to return success, because otherwise
it would be a "silent probe" of the security model (ie a bad user
could use the mmap(PROT_NONE) to see if min_mmap_addr is on or not
without triggering any selinux warnings).

And unlike your patch, it wouldn't open up some new interface
(mprotect) to worry about.

So I think it might be valid to say "always allow mmap(PROT_NONE)
under mmap_min_limit, by simply turning it into a no-op".

                       Linus
--
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/