Subject: Re: chroot jail for ftpd
To: None <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 10/18/2001 14:54:11
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
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.