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

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: <Pine.LNX.4.64.0609281707190.27484@blonde.wat.veritas.com>
Date:	Thu, 28 Sep 2006 17:42:08 +0100 (BST)
From:	Hugh Dickins <hugh@...itas.com>
To:	Stas Sergeev <stsp@...et.ru>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Ulrich Drepper <drepper@...hat.com>, Valdis.Kletnieks@...edu,
	Arjan van de Ven <arjan@...radead.org>,
	Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: [patch] remove MNT_NOEXEC check for PROT_EXEC MAP_PRIVATE mmaps

On Thu, 28 Sep 2006, Stas Sergeev wrote:
> Hugh Dickins wrote:
> > since executables are typically mapped MAP_PRIVATE, I suspect
> > your patch will simply break mmap's intended MNT_NOEXEC check.
> The one with ld.so you mean? But its a user-space issue,
> I haven't seen anyone claiming the opposite (and you even
> explicitly confirmed it is).

I'm not sure what you're referring to there.  The idea that loader
should parse library pathname and /proc/mounts output, and thereby
enforce "noexec" by itself, rather than relying on the kernel's
mmap implementation to enforce it?  Well, I'm glad I won't need
to implement that, since the kernel's mmap _is_ doing the check,
and I still see no reason to change that after all this time.

> 
> > I think you need to face up to the fact that "noexec"
> > doesn't suit your mount, and just leave it at that.
> But noone have answered this question:
> Which configuration is more secure - the one where all
> the user-writable fs are mounted with "noexec" (in old
> sense of noexec), or the one without "noexec" at all
> because I should no longer use it here and there (actually,
> everywhere)?

I'll leave comparisons of security to those who know what they're
talking about.  But again and again I have to point out, just
because "noexec" has proved inconvenient to you here, does not
imply that it's useless everywhere, and does not imply that
the kernel should change its behaviour to suit you.

> 
> > But I do concede that I'm reluctant to present that patch Alan
> > encouraged, adding a matching MNT_NOEXEC check to mprotect: it
> > would be consistent, and I do like consistency, but in this case
> > fear that change in behaviour may cause new userspace breakage.
> I can't think of a single real-life example where it will
> break something over whatever is broken already by the mmap
> check. But I am not encouraging such a change of course.

There might be a loader which specifically seeks to avoid the
mmap check, by mmapping without PROT_EXEC then mprotecting with
PROT_EXEC.  Whether that's an argument for or against now adding
the test to mprotect depends on your standpoint.

But I think I've already said all I have to say on this.

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