Messages in this thread |  | | | Date | Thu, 28 Sep 2006 08:52:10 +0400 | | From | Stas Sergeev <> | | Subject | Re: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |