Subject: Re: Non executable mappings and compatibility options bugs
To: Thor Lancelot Simon <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 06/21/2004 22:22:32
Content-Type: text/plain; charset=us-ascii
On Tue, Jun 22, 2004 at 12:40:15AM -0400, Thor Lancelot Simon wrote:
> 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:
> > > I strongly disagree; this would be a regression, with no warning to t=
> > > user, in system security. Adding a COMPAT_ option shouldn't punch a =
> > > hole in a fundamental security mechanism.
> > How is this a regression? My understanding of the discussion is we woul=
> 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.
I don't think it's a regression, because it strikes me that to really=20
emulate another OS, we need to map things in the same way it does. For us=
to impose non-execness on other OSs strikes me as over-eager at best, and=
a bug at worst.
> 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 somethin=
> we should do without warning the user when the kernel's built and when it=
I also don't think that this behavior is that sacrosanct. Yes, it is a big=
deal, and I'm very glad NetBSD has it. Yes, I do understand how it can=20
close a lot of security vulnerabilities in one act.
But it has neither been in NetBSD for a year nor has it made it into a
NetBSD release. So I do not think that making emulations have the same
security level in 2.0 that they had in 1.6 will be a surprise. As for
advertizing, we need only mention that we added non-exec stacks to only
NetBSD programs, and use it as a reason to favor running programs native.
And to be honest, if we're going to worry about emulations being less
secure than native apps, I think we should be much more scared of Linux=20
> Obviously, if other operating systems have busted dynamic loaders such th=
> 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 use=
> would have any reason to expect, and doing it without huge glaring warnin=
> 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?
We probalby should allow jumping there. :-)
If I understood one of Charles's other posts, a.out NetBSD apps (i.e. =20
our old shared loader) will also be hit with this issue.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----