--oFbHfjnMgUMsrGjO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=
he
> > > user, in system security.  Adding a COMPAT_ option shouldn't punch a =
giant
> > > hole in a fundamental security mechanism.
> >=20
> > How is this a regression? My understanding of the discussion is we woul=
d=20
>=20
> 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=
=20
to impose non-execness on other OSs strikes me as over-eager at best, and=
=20
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=
=20
> and can't do violates the principle of least surprise and is not somethin=
g=20
> we should do without warning the user when the kernel's built and when it=
's=20
> run.

I also don't think that this behavior is that sacrosanct. Yes, it is a big=
=20
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
and IPv6.

> Obviously, if other operating systems have busted dynamic loaders such th=
at
> 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=
rs
> would have any reason to expect, and doing it without huge glaring warnin=
gs
> is wrong, wrong, wrong.
>=20
> 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.

Take care,

Bill

--oFbHfjnMgUMsrGjO
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFA18IYWz+3JHUci9cRAmCuAJ95xm6nQDrXOSTPVwvRduZlBMmo2wCcDxHz
OhaPsKm5bFOoCpQ+wqK4DgQ=
=MJts
-----END PGP SIGNATURE-----

--oFbHfjnMgUMsrGjO--