Date:	Sun, 23 Oct 2011 11:52:43 -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

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

Indeed the application does not get unhappy about the mmap failing.  It
does need to try it in a loop, moving up a page after each failure, though.
Its own robustness requirement mandates that space up to 0x10000 be blocked
off, even if the system is only enforcing it up to 0x1000, for example.

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

I don't have a problem with that.

> So I was looking for some *other* reason for the patch.

As I explained, the rationale was not to have any LSM modules (such as
SELinux) complaining about the attempt.

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

That's fine with me too.

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

That works, though AFAICT it needs this slightly more complex logic
repeated in each different LSM.

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

Agreed.

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

I agree that is better.  What's important is that the application can rely
on the low memory range never being made accessible by any mmap.

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

Note that there is also CONFIG_LSM_MMAP_MIN_ADDR to consider, but yes.

> On Sun, Oct 23, 2011 at 2:08 AM, Kevin Easton <kevin@...rana.org> wrote:
> >
> > Won't this still allow silent probing, because the malicious user can
> > just try to create the mapping, then check in /proc/self/maps to see
> > if it really worked?
> 
> Yup, right you are.

Not if the application is already running inside a sandbox that prevents
direct access to /proc (e.g. in a private FS namespace, as my application
in fact is).

> So we shouldn't do that either, and probably just leave the current
> semantics, unless Roland (or others) can convince me that complicating
> the kernel  mmap security model really is worth it.

I'm really only concerned with two things:

1. The application can do something after which it can rely, with maximal
   paranoia, on the [0,0x10000) range never being used by any later
   non-MAP_FIXED mmap, regardless of kernel variant or local system
   configuration.
2. Whatever LSM stuff might be in use distinguishes the actions that ensure
   this from a "potentially malicious" attempt to do a usable mapping in
   that range.

So either the "pretend to succeed" or the "fail without LSM whining" models
can fit those needs as well as the "really succeed for PROT_NONE only"
model I proposed.  (Though I agree with your point above that "pretend to
succeed" is a little bit better because of potentially revealing less about
the exact constraints the system is imposing.)  In the status quo today,
AIUI the only way to do "fail without whining" under SELinux is with a
"dontaudit" policy rule for the MMAP_ZERO permission check for the given
application--but that doesn't distinguish the harmless PROT_NONE attempts
from an actual "malicious" attempt, so it's suboptimal.  (And I don't know
about other LSM implementations that might do their own kinds of whining.)

So it may be sufficient just to change SELinux (and perhaps other LSM
implementations) to treat PROT_NONE specially for purposes of the whining.
LSM folks will have to say how best to make that happen.


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