Re: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps

From: Stas Sergeev
Date: Sun Sep 24 2006 - 12:30:09 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/