In message <20011018143836.J19512@dr-evil.shagadelic.org>Jason R Thorpe writes
>On Thu, Oct 18, 2001 at 04:47:30PM -0400, Thor Lancelot Simon wrote:

> > Yeah, let's do a special-purpose hack instead of actually enforcing the
> > consistent rule that executable code has to come from an executable file.
>
>Nevermind that you could mmap w/ PROT_READ only, allocate a new
>buffer, copy the code there, mprotect() it, etc.

uh....  I thought Thor's point is that he is trying to tie down a
system where users can execute only code which he has put into a
"safe" place.  Presumably Thor (or someone trusts) has audited the
source-code he puts in his safe place (ATA flash).  This gives a 
relativey secure  sandbox.

In that model, users cannot mmap/PROT_READ/then execute [[or skip the
mprotect() altogether, on arches which dont distinguish
PROT_READ/PROT_EXEC and I-cache consistency "just works']].  The
assumption is that the audited code in the sandbox doesn't let the
user to mmap(), mprotect(), and execute code that isnt already part of
the sandbox.

Setting LD_LIBRARY_PATH to point to a writable filesystem, and putting
a "trojan" shared library there, gives any user a trivial way to break
out of the sandboxes.  Thor is asking to close that loophole.

I think a real fix requires changing LD_LIBRARY_PATH and friends from
searching into (or through) filesystems mounted with "noexec".  The
mount(8) manpage says mount -noexec doesn't acutally prohibit users
from doing chmod +x, it just stops the kernel honouring the x bit.
Perry's change doesn't acutally close Thor's loophole: I think that
needs LD_LIBRARY_PATH to not load libraries from -noexec filesystems,
regardless of the permissions on the .so* file.