![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2006-09-24 10:03 [W:0.241 / U:0.090 seconds] ©2003-2008 Jasper Spaans | |||||||||||||