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:32:38 +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 8:24 PM, Roland McGrath <roland@...k.frob.com> wrote:
>
> It's exactly the case that I did mention: an application's own attempt to
> ensure robustness by doing a PROT_NONE mmap of the [0,0x10000) region.  An
> application cannot presume that this region is already precluded from being
> used by any non-MAP_FIXED mmap across all systems and configurations, so
> it's defensive coding to explicitly block it off with a PROT_NONE mapping.

Quite frankly, I don't think that's an interesting case.

The app can try to be robust by doing the mmap(PROT_NONE), but if that
fails, then the app should just let it go.

Why should the kernel make its own security more complex (and thus fragile)?

So I think that it's perfectly ok for some user-level app to do

    mmap(NULL, 64k, PROT_NONE, MAP_FIXED|MAP_ANON, -1, 0);

to try to create a PROT_NONE mapping at NULL, but then just ignore the
error if that fails. That way the app can handle the case of "maybe
the system is set up to allow NULL mappings, so I'll harden it
myself".

But that's no reason for the kernel to *allow* the mapping.

And if the app actually *fails* due to the mmap failing, then the app
is just buggy and stupid. So again, there's no reason for the kernel
to allow it.

IOW, either the app is fine with the kernel not letting it do a
PROT_NONE mapping, or the app is so braindamaged as to not be worth
worrying about. In neither case do I actually see any reason to apply
your patch.

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".

                  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/