Subject: Re: Non executable mappings and compatibility options bugs
To: Erik E. Fair <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 06/22/2004 18:17:02
Content-Type: text/plain; charset=us-ascii
On Tue, Jun 22, 2004 at 05:23:18PM -0700, Erik E. Fair wrote:
> Since software from our own source tree is unaffected (or has been=20
> cleaned up already), it seems to me that the explicit enforcement of=20
> execution permissions needs to be a per-emulation flag, and that in=20
> our kernel configurations, those emulations that require the=20
> enforcement off should themselves be commented out by default with a=20
> clear notation of the security threat that they pose. We can change=20
> each emulation's flag and "commented out" status when they clean up=20
> their acts (presuming they ever will; emulations of EOL'd operating=20
> systems will just have to endure whatever state they turn out to be=20
I agree, except I think a better default would be to leave the emulation=20
in and on. We will be leaving the emulation exactly like it was in 1.6. We=
then note that non-exec stacks are a feature of NetBSD, not necessarily=20
the OS we emulate. I do like the idea of a sysctl, so that we can easily=20
turn this behavior on and off.
Maybe I'm unique, but I've always considered if you're running an emulated=
program, you are not necessarily getting all the security and features of=
current NetBSD programs.
> This keeps us "default secure" which I presume is still our project=20
> policy. People will grumble, I'm sure, but better that than to end up=20
> singing "mea culpa" when systems running NetBSD get compromised in=20
> the field.
Our project policy, when it comes to emulations, actually has been (to the
extent we have a policy) to do what the emulated OS does. I'm thinking
about ip6.v6only as a specific example. To be honest, now that I
understand Itojun's comments about v6only, I think it's a bigger security
concern than non-exec stacks.
As a total aside, I've been informed that current Linux (Fedora Core 1)=20
has non-exec stack support. For Linux, the compiler will figure out if it=
needs an executable stack or not, and will indicate in the final program=20
if the stack should be exec'able or not. And there's a knob to turn exec=20
stacks off for the whole OS.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----