Subject: Re: Non executable mappings and compatibility options bugs
To: None <tech-kern@netbsd.org, tech-security@netbsd.org>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: tech-security
Date: 06/22/2004 00:40:15
On Mon, Jun 21, 2004 at 09:26:42PM -0700, Bill Studenmund wrote:
> On Mon, Jun 21, 2004 at 09:55:17AM -0400, Thor Lancelot Simon wrote:
> > On Sun, Jun 20, 2004 at 10:55:23AM -0700, Chuck Silvers wrote:
> > > 
> > > it would be safest to default to making everything executable for other
> > > emulations until it can be verified that those binaries work ok with
> > > non-executable mappings.  this seems fine to me.
> > 
> > I strongly disagree; this would be a regression, with no warning to the
> > user, in system security.  Adding a COMPAT_ option shouldn't punch a giant
> > hole in a fundamental security mechanism.
> 
> How is this a regression? My understanding of the discussion is we would 

I would think that it would be quite simple to see how it's a regression:
currently, code can be executed from no process's stack.  The proposed
change would allow it to be executed from _some_ processes' stacks.

Causing the mere naive addition of COMPAT_FOO to a kernel config file to
make that fundamental change to the semantics of what user processes can 
and can't do violates the principle of least surprise and is not something 
we should do without warning the user when the kernel's built and when it's 
run.

Obviously, if other operating systems have busted dynamic loaders such that
this change is required to run them, it's necessary to allow correct
emulation.  But it's still a regression in security, and not one that users
would have any reason to expect, and doing it without huge glaring warnings
is wrong, wrong, wrong.

Not to mention that, as Charles noted, the case mentioned in the beginning
of this thread may not even be an example of what we think it is; the
address in question is in the GOT, and we probably _should_ allow jumping
there, no?