Hi.
Hugh Dickins wrote:
nor with shm_open. It's just that the kernel is not allowing
mmap PROT_EXEC on a MNT_NOEXEC mount. Which seems reasonable
Even for the MAP_PRIVATE mmaps? But what does that solve?
Even if you restrict mprotect() too, the malicious app will
simply read() the code in the anonymously mapped region,
while the properly-written code just breaks.
Is it documented in any spec or done in any other system?
If that's a problem for something, don't mount "noexec"
Yes, I myself think "noexec" is rather useless and can always
be bypassed. But whether that particular handling is correct,
doesn't look obvious to me.
Thanks for the pointer, but that looks like the user-space
issue to me. Why ld.so can't figure out the "noexecness" and
do the right thing itself?
That would be tiresome work.
Or does it figure out the "noexecness"
exactly by trying the PROT_EXEC mmap and see if it fails?
Exactly.
So do you mean such a checks were added as a quick hack till
the proper solution is implemented? That may explain the issue,
at least partially...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]