[Bug 203585] New: Feature Request for filesystems that support noexec/exec mount options

[Bug 203585] New: Feature Request for filesystems that support noexec/exec mount options

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=203585

            Bug ID: 203585
           Summary: Feature Request for filesystems that support
                    noexec/exec mount options
           Product: File System
           Version: 2.5
    Kernel Version: all
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: ext4
          Assignee: fs_ext4@kernel-bugs.osdl.org
          Reporter: Speeddymon@gmail.com
        Regression: No

Greetings,

I want to ask for a new mount flag to be considered which enhances the
noexec/exec flag for filesystems that support those flags.

What I would like to do is to designate in /etc/fstab that a filesystem with
either flag can be bypassed by certain users.

For example, there is a web app that insists on writing a file to the root of
/tmp, (a shared object library) in order to then load that file into memory to
perform some operation. Why it is done this way, I don't know, but we have /tmp
set to noexec for security reasons. The app is required to be able to execute
the file in order to load it into memory it seems, because the app fails when
we have noexec flag set on the /tmp filesystem, and it works fine without that
flag.

So, I was hoping that in the future, we might be able to work around this
dilemma by having a "exec_users=/noexec_users=" type mount option. Where, if a
filesystem has "noexec", you could do: "noexec,exec_user=john", and conversely
if a filesystem has "exec" and you want to lock down a certain user/set of
users, you could do "exec,noexec_user=paul"

If this is considered useful enough, and is able to be implemented without much
fuss -- BTW I'm HOPING that since the kernel does permissions checks for
file/directory access, it can also do those checks for noexec/exec access --
then could you please also extend the mount options to have
group_noexec/group_exec flags as well?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 203585] Feature Request for filesystems that support noexec/exec mount options

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=203585

Theodore Tso (tytso@mit.edu) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |tytso@mit.edu
         Resolution|---                         |WILL_NOT_FIX

--- Comment #1 from Theodore Tso (tytso@mit.edu) ---
This is not at all trivial to implement, for a number of reasons:

*)  The kernel doesn't have access to the username to uid map.   It might be in
/etc/passwd; but you might also be using LDAP or Yellow Pages for the
username->uid map.   This could done by adding support for this to each file
system which implements this feature request's /sbin/mount.FSTYP, but...

*) This also begs the question of how to handle user namespaces.

The simplest way of solving this problem may be to change the web application
to write its temporary file in some other directory, and let that directory be
writable only by the web application's user id, and let that directory be
mounted without the noexec flag.  If you are using tmpfs, you can mount
multiple tmpfs instances, and create a special one which has mount options just
for that web application, with an fstab entry like this:

tmpfs /run/user/1042 tmpfs
rw,nosuid,nodev,relatime,size=2048k,mode=700,uid=1042,gid=1042 0 0

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 203585] Feature Request for filesystems that support noexec/exec mount options

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=203585

--- Comment #2 from Thomas Spear (Speeddymon@gmail.com) ---
Thanks for updating so quickly.

An acceptable workaround for the uid mapping would be to just list the uids in
the fstab.

I appreciate the suggestion to modify the web app, and yes it would be great if
we could. Unfortunately its a 3rd party app with vendor support, and its hard
coded to write to the root of /tmp -- we can't even get it to write to a
folder, though I am considering suggesting a chrooted environment for the app
so that we can virtualize the access to /tmp that way.

I saw mention of getting around it by using bind mounts over on stack overflow,
but that would also require the ability to make it write somewhere other than
/tmp.

The app team is trying to push for acceptance of the risk of removing noexec
from /tmp (RHEL7 defaults to noexec for /tmp so its a change to the current
policy), but everything I've ever understood about /tmp being world writable
tells me that noexec on /tmp is a sane default and should be left that way.

Anyways, I could see having noexec_user= for exec filesystems being useful in a
variety of circumstances, but the rest of the request is a bit niche, so I
don't guess it would get much support from the community.

Thanks again for the help.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.