noexec on /dev/shm

[Garrett Holmstrom]

On 12/14/2010 21:28, Lennart Poettering wrote:
> On Tue, 14.12.10 12:08, Bill Nottingham (notting at redhat.com) wrote:
>
> Thanks, Bill, for replying in so much detail.
>
> Here are a few other points:
>
>> - systemd mounts API filesystems without them needing to be in
>>    /etc/fstab. This is for a variety of reasons - having every system
>>    installer have to write /proc, /sys, and so on is pretty wasteful. It
>>    also can give inexperienced admins the idea that it's configuration
>>    that can be changed - they then rename the mount point from /proc
>>    to /processes and *kaboom*.
>
> The main reason we mount /sys and /proc and friends in C code this early
> is that we simply need them ourselves. To do what systemd does, it must
> be able to rely that it can read process data from /proc, or device
> information from /sys, or cgroup information from /sys/fs/cgroup.
>
> There is simply no way around this, and just to make a point, Upstart
> mounts some of those FS too, in C code (however not /dev/shm), there's
> very little effective difference here, and if people whine and say
> "things have never een done this way, you a are breaking UNIX", then I
> can only reply, that that's simply wrong.
>
> Having said all this I actually believe that there is very little point
> in listing "API" file systems like these in /etc/fstab. They are after
> all API, hence only relevant for application code, not really useful for
> direct interaction or even reconfiguation by the user. Or in other
> words: While it definitely makes sense to ount /dev/sda5 to whatever
> mount point the user chooses, the mount point and options for the API
> file systems are pretty much an implementation detail for the OS, and
> there should never be a need to change them.
>
> 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.
>
> That said, because we anticipated that there are some valid uses to
> change the settings of these mount points (e.g. change size= for tmpfs)
> we actually do apply the options from /etc/fstab, if the file system is
> listed there. So if you really really want to misuse /dev/shm, you
> may. Apparently this particular feature was broken (see Bill's comments),
> and hence please file a bug about this.

I'm fine with that as long as it is documented, particularly in the 
fstab man page and as commentary in /etc/fstab on newly-installed 
systems so people who read it and notice missing filesystems don't 
panic.  Thanks for explaining your thought process.

It sounds like /tmp would be a better location to remove noexec from 
than /dev/shm if one needs memory-backed storage for things and doesn't 
want to create a new filesystem for that purpose.