Messages in this thread | | | Date | Tue, 03 Oct 2006 23:40:47 +0400 | From | Stas Sergeev <> | Subject | Re: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps |
| |
Hello.
Ulrich Drepper wrote: > You really don't get it, do you. Yes, sorry. :)
> The way ld.so works can be implemented > in many other forms with other programs. Having "noexec" (in its older form) on *every* user-writable mount makes it harder for an attacker to run his own loaders, so implementing it in other forms was useless in the past.
> With some time and energy you > likely can write a perl or python script to do it. This is solvable the same way too - "chmod 'o-x' perl" and run the scripts via binfmt-misc (not sure if this is really suitable though). You need a trivial kernel patch to make that possible.
>> And allow an attacker to store his files on that partition, >> and then execute them. > They can do it anyway. With having "noexec" (in its older form) on every user-writable partition - how they can do it?
>> I have already proposed another solution for ld.so problem >> 3 times. > And for obvious reasons I ignored it. Some explanation could do better, but oh well.
> noexec mounts the way _you_ want them are completely, utterly useless. But I used them. And having them on _every_ user-writable mounts at least used to give some results.
> nonexec mounts as they are today plus an upcoming mprotect patch give As was pointed out by Hugh, such a patch is unlikely.
> fine grained control. Control of what? The malicious loader will always work - it is unaffected by both mmap and mprotect changes. So what you can control is only how many apps you break.
> You have to use additional mechanism like SELinux > to fill in all the holes but that's OK. Yes, selinux is the only solution here.
> nonexec mounts give a great > deal more of flexibility. Any real-life examples of what problem does this solve? (except of the already discussed partially-solved ld.so problem)
- 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/
| |