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: <4516B2C8.4050202@aknet.ru>
Date:	Sun, 24 Sep 2006 20:31:04 +0400
From:	Stas Sergeev <stsp@...et.ru>
To:	Ulrich Drepper <drepper@...hat.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Hugh Dickins <hugh@...itas.com>, Andrew Morton <akpm@...l.org>,
	Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps

Hi.

Ulrich Drepper wrote:
>> The one that goes to /dev/shm should allow PROT_EXEC, yet
>> not allow executing the binaries with execve().
> Why on earth would you want this?  Previously you already acknowledged
> that this kind of "protection" can be worked around by using ld.so
> directly.
I have not acknowledged this but rather was pointed out
to that fact and to that the checks were supposed to solve
this problem.
I agree the problem does exist, but isn't it a user-space
problem? Hugh Dickins points out that the failure of PROT_EXEC
mmap is a quick way for ld.so to find out the fact that the
partition is mounted with "noexec". But are there really no
other ways? Maybe (just maybe, I am unaware about details) ld.so
can look into /proc/mounts or similar and do the right thing
itself?

> Either all executable mapping is forbidden or none.  No middle ground
> can exist.
Exactly. So why such a "middle-ground" solution is currently
there? I can:
1. mprotect() the existing mapping to PROT_EXEC and bypass the
checks (but you can easily restrict that by patching mprotect()).
2. Do the anonymous mmap with PROT_EXEC set, then simply read()
the code there, then execute. This you *can not* restrict!

On the other hand: such a checks hurts the properly-written
code *only*, no malicious loaders can be affected. The properly-
written code breaks because it uses MAP_SHARED mmaps - that's
what you can restrict. The malicious loader will simply read
the code into the area previously mmaped anonymuosly - it doesn't
need MAP_SHARED. As you pointed out, such a malicious loader can
probably be a script. So, by rejecting the file-backed mmaps with
PROT_EXEC set, you hurt the good programs, while the bad ones are
completely unaffected.
Now, the breakage of the properly-written programs forces people
to stop using "noexec" on /dev/shm-mounted tmpfs. As far as I
understand, having the single writeable and executable mountpoint
is almost as bad as having all of them. The attacker will now simply
put his binary into /dev/shm.
IMHO, allowing people to use "noexec" for /dev/shm and making ld.so
to use other ways of finding the "noexecness" will solve the
problem, at least to the much better state than currently.

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