[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20111022172450.0BCCE2C0A9@topped-with-meat.com>
Date: Sat, 22 Oct 2011 10:24:50 -0700 (PDT)
From: Roland McGrath <roland@...k.frob.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
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
> So I'm not against this, but I'm wondering what triggers the need for it?
>
> It does make the security checks more complicated, since now
> mprotect() suddenly has to care about mmap_min_addr. So I don't think
> it's a security enhancement ("attempt to ensure robustness").
>
> But if there is some actual use-case that is shown to be helped,
> please document that n the explanations for the changeset.
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.
Since we know mmap_min_addr-type constraints might exist, we start at 0 and
move up a page as long as mmap fails. That works fine to cover e.g. the
[0x1000,0x10000) region when mmap_min_addr is set to 4096, as is common.
However, under SELinux these harmless attempts are diagnosed as MMAP_ZERO
avc denials, which percolate up to the user as scare warnings that the
application was prevented from doing something dangerous and possibly
malicious, when that's not the case at all.
Thanks,
Roland
--
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/
Powered by blists - more mailing lists