noexec on /dev/shm

[Lennart Poettering]

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.

So, in the long run, I believe /etc/fstab should only list real disk and
network file systems, and all the API file systems should not be visible
there. The list of API file systems mounted and the list of API file
systems configured in this file usually has been differing anyway, and
hence I would simply not list them by default there anymore at all. You
could even say that this brings /etc/fstab back to its traditional
roots, since the glut of virtual API file systems is actually a very
recent change in history, and for the longest time /proc was really the
only one ever used. So, Unix-Lovers, please say "thank you", we are
bringing back to you a piece of good old Unix/Linux, that has long been
taken away from you, by evil Unix-haters!

[ and again, "not listing by default" by no means means that you couldnt
list them there if you wanted to to or that your options would be ignored
by design -- as soon as the aforementioned bug is fixed ]

(Sorry for no responding more timely. i have been (and still am)
backpacking through India, and my access to the Internet has been only
sporadic and slow)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.