linux-kernel - [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: <451ACE29.4080005@aknet.ru>
Date:	Wed, 27 Sep 2006 23:16:57 +0400
From:	Stas Sergeev <stsp@...et.ru>
To:	Andrew Morton <akpm@...l.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>,
	Linux kernel <linux-kernel@...r.kernel.org>
Subject: [patch] remove MNT_NOEXEC check for PROT_EXEC MAP_PRIVATE mmaps

Hi Andrew.

It looks like in a course of a discussion people
agreed that at least for MAP_PRIVATE the MNT_NOEXEC
check makes no sense (no one spoke up otherwise, at least).

The attached patch removes the check for MAP_PRIVATE but
leaves for MAP_SHARED for now, as this was not agreed on.

Reasons:
- MAP_PRIVATE should not behave like that, "ro" and PROT_WRITE
is a witness ("ro" doesn't deny PROT_WRITE for MAP_PRIVATE).
- This is not a security check - file-backed MAP_PRIVATE mmaps
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.

Sign-off: Stas Sergeev <stsp@...et.ru>

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