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: <45198395.4050008@aknet.ru>
Date:	Tue, 26 Sep 2006 23:46:29 +0400
From:	Stas Sergeev <stsp@...et.ru>
To:	Linux kernel <linux-kernel@...r.kernel.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Hugh Dickins <hugh@...itas.com>,
	Ulrich Drepper <drepper@...hat.com>, Valdis.Kletnieks@...edu,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps

Hi Guys.

Noone provided a reason for (or even tried to defend)
the fact that PROT_EXEC is rejected by "noexec" even
for MAP_PRIVATE, while, say, PROT_WRITE is *not* rejected
for "ro" filesystem for MAP_PRIVATE. What was argued is
only MAP_SHARED.
I take it as an indication that people basically agree
that "noexec" should not affect MAP_PRIVATE like that.
So how about the patch (like the attached one) which
changes only the behaveour of MAP_PRIVATE?

Reasons:
- MAP_PRIVATE should not behave like that, "ro" and PROT_WRITE
is a witness.
- This is not a security check - file-backed MAP_PRIVATE
can just be replaced with MAP_PRIVATE | MAP_ANONYMOUS
mmap and read().
- The programs (like AFAIK wine) use MAP_PRIVATE mmaps to
access the windows dlls, which are usually on a "noexec"
fat or ntfs partitions. Wine might be smart enough not to
break but fallback to read(), but this is slower and more
memory-consuming. Some other program may not be that smart
and break. So there is clearly a need for MAP_PRIVATE with
PROT_EXEC on the noexec partitions.

Please let me know why this patch should not be applied.

View attachment "mapx1.diff" of type "text/plain" (1053 bytes)