From: Andrew Morton <akpm@linux-foundation.org>
To: Will Drewry <wad@chromium.org>
Cc: linux-kernel@vger.kernel.org, mcgrathr@google.com,
Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Al Viro <viro@zeniv.linux.org.uk>, Eric Paris <eparis@redhat.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Mel Gorman <mel@csn.ul.ie>, Rik van Riel <riel@redhat.com>,
Nitin Gupta <ngupta@vflare.org>, Hugh Dickins <hughd@google.com>,
Shaohua Li <shaohua.li@intel.com>,
linux-mm@kvack.org
Subject: Re: [PATCH] mmap: add sysctl for controlling ~VM_MAYEXEC taint
Date: Tue, 16 Aug 2011 14:54:27 -0700 [thread overview]
Message-ID: <20110816145427.78f2f8c9.akpm@linux-foundation.org> (raw)
In-Reply-To: <1313441856-1419-1-git-send-email-wad@chromium.org>
On Mon, 15 Aug 2011 15:57:35 -0500
Will Drewry <wad@chromium.org> wrote:
> This patch proposes a sysctl knob that allows a privileged user to
> disable ~VM_MAYEXEC tainting when mapping in a vma from a MNT_NOEXEC
> mountpoint. It does not alter the normal behavior resulting from
> attempting to directly mmap(PROT_EXEC) a vma (-EPERM) nor the behavior
> of any other subsystems checking MNT_NOEXEC.
>
> It is motivated by a common /dev/shm, /tmp usecase. There are few
> facilities for creating a shared memory segment that can be remapped in
> the same process address space with different permissions. Often, a
> file in /tmp provides this functionality. However, on distributions
> that are more restrictive/paranoid, world-writeable directories are
> often mounted "noexec". The only workaround to support software that
> needs this behavior is to either not use that software or remount /tmp
> exec.
Remounting /tmp would appear to have the same effect as altering this
sysctl, so why not just remount /tmp?
> (E.g., https://bugs.gentoo.org/350336?id=350336) Given that
> the only recourse is using SysV IPC, the application programmer loses
> many of the useful ABI features that they get using a mmap'd file (and
> as such are often hesitant to explore that more painful path).
>
> With this patch, it would be possible to change the sysctl variable
> such that mprotect(PROT_EXEC) would succeed. In cases like the example
> above, an additional userspace mmap-wrapper would be needed, but in
> other cases, like how code.google.com/p/nativeclient mmap()s then
> mprotect()s, the behavior would be unaffected.
>
> The tradeoff is a loss of defense in depth, but it seems reasonable when
> the alternative is to disable the defense entirely.
>
> ...
>
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -89,6 +89,9 @@
> /* External variables not in a header file. */
> extern int sysctl_overcommit_memory;
> extern int sysctl_overcommit_ratio;
> +#ifdef CONFIG_MMU
The ifdef isn't needed in the header and we generally omit it to avoid
clutter.
afaict this feature could be made available on NOMMU systems?
> +extern int sysctl_mmap_noexec_taint;
The term "taint" has a specific meaning in the kernel (see
add_taint()). It's regrettable that this patch attaches a second
meaning to that term. Can we think of a better word to use?
A better word would communicate the sense of the sysctl operation. If
a "taint" flag is set to true, I don't know whether that means that
noexec is enabled or disabled. Something like
sysctl_mmap_noexec_override or sysctl_mmap_noexec_disable, perhaps.
This patch forgot to document the new feature and its sysctl.
Documentation/sysctl/vm.txt might be the right place.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-08-16 21:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-15 20:57 Will Drewry
2011-08-16 9:33 ` Mel Gorman
2011-08-16 17:07 ` Roland McGrath
2011-08-16 19:40 ` Mel Gorman
2011-08-16 19:46 ` Roland McGrath
2011-08-16 19:50 ` Will Drewry
2011-08-16 19:50 ` Will Drewry
2011-08-17 23:22 ` Valdis.Kletnieks
2011-08-16 21:54 ` Andrew Morton [this message]
2011-08-16 22:35 ` Will Drewry
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110816145427.78f2f8c9.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=a.p.zijlstra@chello.nl \
--cc=aarcange@redhat.com \
--cc=eparis@redhat.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mcgrathr@google.com \
--cc=mel@csn.ul.ie \
--cc=mingo@elte.hu \
--cc=ngupta@vflare.org \
--cc=riel@redhat.com \
--cc=shaohua.li@intel.com \
--cc=viro@zeniv.linux.org.uk \
--cc=wad@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox