noexec on /dev/shm

[Lennart Poettering]

On Tue, 14.12.10 21:11, Nicholas Miell (nmiell at gmail.com) wrote:

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

These are good and valid points. I have now dropped noexec from the
default flags for /dev/shm.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.