noexec on /dev/shm

[Nicholas Miell]

On 12/14/2010 07:28 PM, Lennart Poettering wrote:
> In order to make things secure we minimize what is allowd on the various
> API file systems we mount. That includes that we set noexec and similar
> options for the file systems involved. The interface how to access
> /dev/shm is called shm_open(), and given that this is how it is there is
> very little reason to allow people to execute binaries from them. Of
> course, this is a very recent change, and at this point while we assume
> that this will not break any valid use of this directory, we cannot be
> sure about this, so we'd be very interested to learn why exactly you
> want the noexec to be dropped. What is your application that needs that?
> If there is a point in dropping the noexec, we'll definitely be willing
> to do so, but if the only reason would be "I always misused /dev/shm as
> a scratch space", then we won't be very convinced. The API fom /dev/shm
> is shm_open(), and if you place other stuff in there, then you are
> misusing it and actually creating all kinds of namespacing problems
> (since /dev/shm is actually an all-user shared namespace), and we aren't
> particularly keen to support such misuses by default.
> 

shm_open() takes the standard mode flags, and mmap() with PROT_EXEC on a
+x fd returned by shm_open() is a legitimate operation that is required
by POSIX.

This is a perfectly reasonable thing to do on a SELinux-enabled system
which requires e.g. a JIT to write generated code to the writable
mapping and execute that code from the executable mapping of the same
shared memory object.