noexec on /dev/shm

[David Airlie]

----- "John Reiser" <jreiser at bitwagon.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.
> 
> The claim "The API for /dev/shm is shm_open()" is incorrect.
> Very early in the history of shm [late 1970's at the Columbus, Ohio,
> USA
> branch of Bell Telephone Laboratories], then shm_open, shmget, etc.,
> were
> the only means of access; the objects had names that were 32-bit
> binary
> integers.  In fact, when shm became more widely used then there were
> denial-of-service attacks based on the premise that enumerating
> objects
> in shm required 2**32 exhaustive search via shmget.  As soon as
> /dev/shm
> was integrated into the filesystem, then creat, open, read, write,
> close,
> lseek, execve, etc. (any filesystem API) became additional access
> paths.
> This integration began appearing by about the mid 1980's, around 25
> years
> ago, and since then applications have been using /dev/shm via
> ordinary
> files system APIs in addition to shmget etc.
> 
> Why?  Because *fast* operations on small numbers of
> small-to-medium-sized
> files can be a big advantage for performance.  /tmp often is much
> slower
> because /tmp often is a harddrive: the need for space in /tmp often
> exceeds
> the size of physical RAM.  Also, mounting /tmp as tmpfs can meet
> resistance
> because tmpfs does not support all features that applications expect.
> A ramdisk might be used, except that early ramdisks allowed at most a
> few megabytes (comparable to the capacity of a floppy disk), which is not
> large enough to support typical simultaneous usage.  Applications
> also cannot rely on ramdisks because superuser privileges usually are
> required to access a ramdisk.  In many cases ramdisks have been
> replaced
> by:  /dev/shm !!
> 


You are conflating shm_open and shmget which are two completely separate things,

I'm not sure you actually know what you are talking about, AFAIK /dev/shm is a Linux only thing,
that provides an interface for Posix SHM to glibc from the kernel, nothing more. Its even mentioned in the man page for shm_open.

It sounds like what you really want is to configure your systems with a RAM disk somewhere that you can exec from.

Dave.