Re: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps

[Stas Sergeev <stsp@aknet.ru>]

Hi.

Hugh Dickins wrote:
> > 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
That was actually a bad english on my side, sorry
(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 that
> you simply have a mount where "noexec" presents more problems than
> it solves: so don't use it there.
I am not at all an expert in a security but I think the point
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:
> not every mmap involves PROT_EXEC, not every mount demands execution.
I think it is now more useless than before because that
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
partition executable.
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/