Message-ID: <9a8748490609271638q590f10c3o8fb7d5e478e4dec2@mail.gmail.com>
Date:	Thu, 28 Sep 2006 01:38:49 +0200
From:	"Jesper Juhl" <jesper.juhl@...il.com>
To:	"David Wagner" <daw-usenet@...erner.cs.berkeley.edu>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps

On 28/09/06, David Wagner <daw@...berkeley.edu> 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 ld.so,
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
majority).

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
trouble.


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
implementing.


-- 
Jesper Juhl <jesper.juhl@...il.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists