Bug 29212 - noexec on file level (acl)
Summary: noexec on file level (acl)
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Alias: None
Product: File System
Classification: Unclassified
Component: ext3 (show other bugs)
Hardware: All Linux
: P1 enhancement
Assignee: fs_ext3@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-16 06:03 UTC by krzf83
Modified: 2011-02-16 18:56 UTC (History)
1 user (show)

See Also:
Kernel Version:
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description krzf83 2011-02-16 06:03:33 UTC
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.
Comment 1 Theodore Tso 2011-02-16 15:02:19 UTC
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?
Comment 2 krzf83 2011-02-16 15:35:03 UTC
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.
Comment 3 krzf83 2011-02-16 18:20:41 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.