New: noexec on file level (acl)

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

Summary: noexec on file level (acl)
Product: File System
Version: 2.5
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: enhancement
Priority: P1
Component: ext3
AssignedTo: [email protected]
ReportedBy: [email protected]
Regression: No

kernel really needs option to dissalow running executable (dynamic linker) programs more specific that whole filesystem (mounting with noexec). I guess right place for this would be acl where you could specify which users could or could not run executables. Also its important to specyfy default deny for some locations where files will be created.

Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

Theodore Tso <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #1 from Theodore Tso <[email protected]> 2011-02-16 15:02:19 --- You can already turn off execute permission either using traditional Unix permissions or via the current, existing ACL facility.

Note that it's actually pretty hard to stop a user from executing a file, since it only requires one file system that is mounted w/o noexec, and then they can simply copy the file (assuming they have read access) from its original location to a location in their home directory, or /tmp perhaps, and execute it there.

So it would first be useful if you were to describe exactly what your high level goal is with having more fine-grained noexec capability. What are you trying to do?

Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

--- Comment #2 from [email protected] 2011-02-16 15:35:03 --- Dissalowing access to binary programs like nmap, sendmail, perhaps ping is a good practice on shared system. User can however put his own copies in his home dir of these programs. If /home is mounted without noexec he can run those. With noexec he can't. Of course scripting languages still can be actually used but there are less of a treat for now.
(mounting /tmp and /dev/shm is also common security practice) There are situations when it would be very wasteful and inconvenient to mount whole filesystem with noexec. Perhaps you want to execute code in some directories on /home, perhaps you want to allow some users to execute code od /home or perhaps you want to disallow execution in some locations recursively and still allow it in other locations. I'm not sure what is the best form of setting and storing data for such functionality as I doubt anyone will catch this and want to program it into kernel.
However more precise noexec for specific locations in filesystem, not just whole filesystem, is what I've been looking for years now.

Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

--- Comment #3 from [email protected] 2011-02-16 18:20:41 --- denying executing code has little to do with filesystem. Noexec was implemented as mount flag so there is no problem of specifing more precice paths to dissalow exec-ing - laziness

fs/open.c

        if ((mode & MAY_EXEC) && S_ISREG(inode->i_mode)) {
                /*
                 * MAY_EXEC on regular files is denied if the fs is mounted
                 * with the "noexec" flag.
                 */
                res = -EACCES;
                if (path.mnt->mnt_flags & MNT_NOEXEC)
                        goto out_path_release;
        }

if there were next if but with checking against list of paths in a file (if not xattr) instead of MNT_NOEXEC. I'm not good in c so I have no way of programing this stuff any time soon.

Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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

[email protected] changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
         Resolution|                            |PATCH_ALREADY_AVAILABLE

Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.