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]

Date:	Wed, 27 Sep 2006 21:05:49 +0100 (BST)
From:	Hugh Dickins <hugh@...itas.com>
To:	Stas Sergeev <stsp@...et.ru>
cc:	Andrew Morton <akpm@...l.org>, 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 Wed, 27 Sep 2006, Stas Sergeev wrote:
> 
> 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).

Thanks for the CC Stas, but I'm sorry, I don't think you should
take our silence as agreement: certainly not mine anyway.

I can see absolutely no reason to distinguish MAP_PRIVATE from
MAP_SHARED here: the distinction between them is all to do with
modification (PROT_WRITE), nothing to do with PROT_EXEC.  And
since executables are typically mapped MAP_PRIVATE, I suspect
your patch will simply break mmap's intended MNT_NOEXEC check.

I think you need to face up to the fact that "noexec"
doesn't suit your mount, and just leave it at that.

I've not replied to your questions about the security of "noexec",
partly because I've other things occupying me, partly because I'm
naive in such matters, and my guesses not worth anyone's bandwidth.
I'm quite prepared to believe that "noexec" is about reducing the
likelihood of accidents rather than enforcing security, but that's
still no reason to change its accepted 3-year-old behaviour.

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.

Hugh

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