Subject: Re: chroot jail for ftpd
To: Robert Elz <kre@munnari.OZ.AU>
From: Thor Lancelot Simon <email@example.com>
Date: 10/19/2001 13:43:59
On Fri, Oct 19, 2001 at 06:07:31PM +0700, Robert Elz wrote:
> Date: Thu, 18 Oct 2001 19:38:36 -0400
> From: Thor Lancelot Simon <firstname.lastname@example.org>
> Message-ID: <20011018193836.B8908@rek.tjls.com>
> | So what? I suggest that the treatment should be exactly the same as for
> | executable files: the x bit should not be honored if noexec is set, and
> | if the x bit is not present or not honored, the code should not be executed.
> Like many arguments that seem to happen here (and elsewhere) part of this
> comes down to what the 'x' bit actually means, or should mean.
> Leaving aside directories, where it is completely different, and irrelevant
> here (and probably sockets, fifos and all kinds of other weird things), 'x'
> can mean either "contains code that can be executed" or "this is a file that
> it is reasonable to exec(2) (and if that fails, to emulate somehow)"
> Until recently (in comparative terms) it made no difference, as the only
> code that was ever executed got to be executed because of exec() (in any
> normal environment anyway).
> Now however, code gets to be executed from shared libraries, dll's, and
> possibly other ways, aside from exec(). It isn't at all clear that the
> 'x' bit is the right way to control that.
> Personally, I think I prefer to keep the 'x' bit clear on anything that
> isn't meant to be run as a command of some kind (and directories...).
> That lessens the confusion that happens when someone sees the 'x' set,
> assumes they must be able to run it, the magic number test fails, and so
> something decides it must be some kind of shell script and asks a shell
> to run the thing.
I'm persuaded by this argument. I now agree that simply having the
"noexec" mount flag checked before mapping with PROT_EXEC probably does
what I want: prevent shared libraries on "noexec" volumes from being used.