Re: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps
From: Stas Sergeev
Date: Sun Sep 24 2006 - 06:00:12 EST
Hugh Dickins wrote:
That was actually a bad english on my side, sorry
Since "noexec" was already rendered useless - yes.
I'm very puzzled. The intention of "noexec" is to prevent execution
of files on that mount. You're saying it's useless because it's
(English is not my native lang). Instead of "useless"
I meant to say "changed to the point where it cannot be
effectively used any more".
preventing execution of files on that mount?
What exactly the "execution" consist of here? You are
not going to prevent an execution of some perl scripts
etc, dont you? So IMHO that applies to only the execution
of the native binaries, ie, similair to just removing the
exec permission from all the files on that partition. Or
at least that's how I understand it. And clearing an exec
permission doesn't disable PROT_EXEC, AFAIK.
It seems to me thatI am not at all an expert in a security but I think the point
you simply have a mount where "noexec" presents more problems than
it solves: so don't use it there.
of "noexecing" the partitions was to make it difficult for an
attacker to put his own binaries somewhere and execute them.
In this case (but I may be wrong) leaving tmpfs without noexec
prevents that goal from being achieved even if all the other
writeable partitions are noexeced, because an attacker will
use /dev/shm for his binaries then. Just my guesses though.
That doesn't mean it's useless:I think it is now more useless than before because that
not every mmap involves PROT_EXEC, not every mount demands execution.
restriction breaks *only* the properly written apps, while
the malicious ones are completely unaffected. That forces
the people to use it rarely than before (not on tmpfs), and
so it looses its use almost completely, leaving at least that
Why only the properly-written apps breaks is because they use
MAP_SHARED - that you *can* effectively protect from PROT_EXEC,
provided you restrict also mprotect(). The malicious apps are
unaffected because they will not use MAP_SHARED, but instead
just read() the binary into the anonymously mapped area with
PROT_EXEC set. ld.so could certainly do that work on his own,
but I don't know how difficult it could be. (I guess it could
retrieve the "noexec" flag from /proc/mounts or something like
that, instead of trying PROT_EXEC and see if it fails).
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/