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

Hello.

Arjan van de Ven wrote:
> but really again you are degrading what noexec means.
I actually want to return some of the former use of it.
Right now it is not usefull at all. Previously it was a
good idea to put "noexec" on every user-writable partition.
That was a guarantee that at least until someone wrote a
loader *script*, the attacker can't execute his binaries.
Such a script is AFAIK not written up to now, so that worked.
Right now the policy is: don't put "noexec" to /dev/shm tmpfs
or the apps will break. Don't put it on the non-native
partitions or the emulators (like Wine) will became slow
and memory-hungry (using read()) or will break.
Basically, there now seem to be no use for "noexec" at all.
And leaving at least a single fs (/dev/shm) without "noexec"
is almost as bad as not using it completely, as there is
already a space to execute the malicious binaries.

> It now starts to mean "only don't execute a little bit"
It means "don't execute the binaries with the exec call".
That used to work and I think this is what the other OSes
have.

> rather than
> "deny execute requests"....
Please, explain me, what exactly you can deny? File-backed
MAP_PRIVATE mmap is only a more effective way of doing the
MAP_PRIVATE|MAP_ANONYMOUS mmap and read(), which is not affected.
So you force the normal progs to fall-back to the less effective
methods, while the malicious ones are not affected at all.
What is that magic value in denying the fast and memory-efficient
method of doing something, and to force people to use the slow
one? How can it be related to security at all?
Making a problem to an attacker up to forcing him to write a
loader script, is good. Making him no problems at all by
forcing people to not use "noexec" on /dev/shm and friends,
or, at best, forcing him to replace file-backed mmap with the
anonymous mmap in his malicious loader, is IMHO not security-
wise at all.

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