Re: [PATCH 1/2] LSM: Do not apply mmap_min_addr check to PROT_NONE mappings
From: Linus Torvalds
Date: Sat Oct 22 2011 - 14:33:07 EST
On Sat, Oct 22, 2011 at 8:24 PM, Roland McGrath <roland@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/