Re: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps

From: Jesper Juhl
Date: Wed Sep 27 2006 - 19:39:12 EST

On 28/09/06, David Wagner <daw@xxxxxxxxxxxxxxx> wrote:
Arjan van de Ven wrote:
>but really again you are degrading what noexec means.

As far as I can tell, noexec never really did mean anything particularly
coherent in the first place, so I find it hard to get upset about any
potential degradation.

(Second, as far as I can tell, it sounds like it may be more accurate
to characterize this as "revert some of it back to the way the semantics
were a year ago" than as "degrade noexec". But even if it is a degradation,
I fail to see why that is a problem.)

Have you read my other email? I notice that things got awfully quiet
on this thread once I started asking some pointed questions about what
exactly noexec is trying to solve and what exactly the threat model is.
I'm still waiting to hear any answers to those questions or any dispute
to my characterization of noexec.

Below are some examples of how I've used noexec in the past and found it useful.
Please not that I'm well aware that it can be circumvented via,
interpreters etc, so it's not a complete solution and not 100% secure,
I'm not trying to say it is. Still, it has its uses.

1) Providing home directories for users that are mounted noexec
prevents the situation where a user downloads a malicious program and
accidentally executes it (for example by clicking on it in his GUI
filemanager by mistake). With the dir mounted noexec the application
fails to run and the user (and admin) is spared some grief and
possibly backup restores.

2) serving static web pages from a filesystem mounted noexec offers a
bit of protection against script kiddies who have found a hole in my
webserver allowing them to exec a program from the web filesystem. It
won't protect against clever attackers who have found a security hole
big enough to allow them to work around noexec, but it does protect
against lot of script kiddies who just found some "hackme.exe" that
tries to just execute a few things (which I believe are the vast

3) I've often used noexec on filesystems used to store backup data,
simply to guard against my own mistakes. Working with many shells on
many boxes you sometimes make mistakes about what box you are on and
if the backup box holds a complete copy of a filesystem hierarchy
similar to the box you think you are on you may try executing some app
on the backup box - possibly with the bad result of modifying your
backup data. I know I've made that mistake in the past, but having the
backup fs noexec prevented the programs to run and saved me some

All of the above could be solved more completely with SELinux, but
that's a lot more complicated than just using noexec, and in
situations where I just want to guard against mistakes or cassual
abuse (and where I have backups just in case someone does circumvent
it), noexec is often a lot easier and good enough - certainly far
better than nothing.
As long as you are aware of the limitations of the security you are
implementing and you accept the risks that limited security implies,
then sometimes weak security that you actually manage to implement is
a lot better than perfect security that you never get around to

Jesper Juhl <jesper.juhl@xxxxxxxxx>
Don't top-post
Plain text mails only, please
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at