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]

Date:	Sat, 23 Sep 2006 20:38:11 +0400
From:	Stas Sergeev <stsp@...et.ru>
To:	Hugh Dickins <hugh@...itas.com>
Cc:	Andrew Morton <akpm@...l.org>, Ulrich Drepper <drepper@...hat.com>,
	Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps

Hi.

Hugh Dickins wrote:
> nor with shm_open.  It's just that the kernel is not allowing
> mmap PROT_EXEC on a MNT_NOEXEC mount.  Which seems reasonable
Even for the MAP_PRIVATE mmaps? But what does that solve?
Even if you restrict mprotect() too, the malicious app will
simply read() the code in the anonymously mapped region,
while the properly-written code just breaks.
Is it documented in any spec or done in any other system?

> If that's a problem for something, don't mount "noexec"
Yes, I myself think "noexec" is rather useless and can always
be bypassed. But whether that particular handling is correct,
doesn't look obvious to me.

>> Thanks for the pointer, but that looks like the user-space
>> issue to me. Why ld.so can't figure out the "noexecness" and
>> do the right thing itself?
> That would be tiresome work.
>> Or does it figure out the "noexecness"
>> exactly by trying the PROT_EXEC mmap and see if it fails?
> Exactly.
So do you mean such a checks were added as a quick hack till
the proper solution is implemented? That may explain the issue,
at least partially...

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