Re: [patch] remove MNT_NOEXEC check for PROT_EXEC mmaps

[Stas Sergeev <stsp@aknet.ru>]

Hello.

Alan Cox wrote:
> > 2. Do the anonymous mmap with PROT_EXEC set, then simply read()
> > the code there, then execute. This you *can not* restrict!
> Its a non-finite turing machine, you can also execute an interpreter.
Exactly. So the question is: what does the current checks
prevent from working if the above is always possible? Answer -
the properly-written apps. Or am I missing something?

> > Now, the breakage of the properly-written programs forces people
> > to stop using "noexec" on /dev/shm-mounted tmpfs. As far as I
> But you've already just argued that this isn't useful anyway ?
Until the malicious loader *script* is written, there is at least
the use. You can easily write the malicious non-script loader,
but you'll have problems invoking it from the noexeced partition.
Most of the current security techniques makes the attack more
difficult but not eliminate it entirely. Without such a magic
script, noexec does its work rather effectively I think (provided
that ld.so is fixed too).
The point is: adding such a checks for mmap() does *not* make
that work of noexec any more effective, but instead breaks the
existing apps or configurations, forcing people to resort to the
weaker configurations. Except for the very suspicious help for
ld.so, noone so far mentioned a *single* advantage of such a
checks, or I might have been blind. :)

> > understand, having the single writeable and executable mountpoint
> > is almost as bad as having all of them. The attacker will now simply
> > put his binary into /dev/shm.
> SELinux
... while before, the "noexec" could do the trick quite right.
That's what I was saying: "noexec" is becoming useless after
such a change, the one now needs SELinux to achieve the same
goal without breaking the existing apps.
I am not at all in favour of noexec. But before, it did one simple
task (fail exec calls) and it was clear where to use it and
where not. Now it pretends to do something more, but in fact,
compared to the older behaviour, the only difference is that now
it breaks apps where before it could be used safely. There are
no other differences, or at least I haven't seen them.

-
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/