linux-kernel - Re: [patch] remove MNT_NOEXEC check for PROT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <efhs1o$h5d$1@taverner.cs.berkeley.edu>
Date:	Fri, 29 Sep 2006 01:14:32 +0000 (UTC)
From:	daw@...berkeley.edu (David Wagner)
To:	linux-kernel@...r.kernel.org
Subject: Re: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps

Jesper Juhl wrote:
>Below are some examples of how I've used noexec in the past and found
>it useful.

Ok, but every one of those examples is pretty much orthogonal to how
the Linux kernel treats mmap(PROT_EXEC).  The only thing you are relying
upon is that ld.so knows how to avoid unintentionally execute programs
that live on noexec partitions.  As long as ld.so has some way to tell
the kernel "please check for me whether this program lives on a noexec
partition; if it does, please bail out", then you'll get all of the benefits
you list and all of your use cases will be unaffected, no matter what
other semantics are assigned to mmap().



Here were your examples:

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