Re: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps

[Stas Sergeev <stsp@aknet.ru>]

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)