Mounting filesystems with "noexec"

Borja Marcos borjamar at
Thu Sep 22 04:11:05 PDT 2005


I've been playing a bit with the "noexec" flag for filesystems. It  
can represent a substantial obstacle against the exploitation of  
security holes.

However, I think it's not perfect yet.

First thing, an attempt to execute a program from a noexec-mounted  
filesystem should be logged. It is either a very significant security  
event, or it can drive nuts an administrator trying to install  
software. (I like to mount with noexec filesystems such as /var, /var/ 
www, /var/spool, /var/tmp, /tmp, /home whenever the users are not  
supposed to install software...).

I opened a PR (a change request, actually) years ago about this, and  
it was closed with a reasonable answer. 

However, as far as I know there is no such general logging facility.  
Wouldn't it be possible for especially sensible events to be logged?  
The patch I submitted is ugly, but it's better than nothing.

There is another change about which I would like to read some  
opinions. Right now, the "noexec" flag is an all-or-nothing, which  
greatly reduces its usefulness. Packages and ports use to run  
programs from /var/tmp or /tmp, and the noexec flags applied to those  
filesystems won't allow software to be installed.

Of course, you can upgrade the status of the filesystems with a mount  
-u, but that opens a window of opportunity; while the noexec flag has  
been removed, it is possible for any user to run programs from those  

I think that it would be useful to have a man point here. What about  
allowing root, and only root, to run programs from a noexec mounted  
fs? Its behavior could be changed (for example) with a sysctl variable.

My point here is this: I want to prevent a privilege escalation, so I  
want to prevent a user from executing a file he/she has just written.  
If it's not possible to execute programs from a directory where a  
normal user can write, either a public-write directory (/tmp et al)  
or a directory owned by him (take, for example, a directory with  
temporary files written by a PHP program or a CGI) it will be very  
difficult to achieve a privilege escalation.

And, anyway, if the intruder found a way to achieve it, he could  
remove the noexec restriction with a mount -u.

I know, both situations have their own caveats (and I can imagine an  
intruder leaving a periodic process trying to run a program from /var/ 
tmp), but imho this new behavior can make the noexec feature much  
more useful.


More information about the freebsd-security mailing list