Re: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps

[Stas Sergeev]

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