Mounting filesystems with "noexec"
Borja Marcos
borjamar at sarenet.es
Thu Sep 22 04:11:05 PDT 2005
Hello,
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. http://www.FreeBSD.org/cgi/
query-pr.cgi?pr=15435
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
directories.
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.
Borja.
More information about the freebsd-security
mailing list