On Sun, Jul 18, 2004 at 09:56:29PM +0200, Emmanuel Dreyfus wrote:
> >> I agree that we should not make kernels insecure by default in order
> >> to please broken emulations. On the other hand, we should document
> >> and explain why emulations break and provide a sysctl to let broken
> >> emulated programs run until we supply the tools you mention above.
> >> This sysctl should default to "off" and users should be strongly
> >> cautioned against turning it "on".
> 
> > well, the tools will be much easier to write than the sysctl, so I'm only
> > going to do the tools.  I'd prefer that the sysctl thing never actually be
> > done, since it opens a big can of worms.
> 
> On the other hand, the sysctl is the right fix.

actually, the right fix is for the applications in question to not assume
that mapped data is executable if they haven't explicitly requested it.


> The patching program has several drawbacks.
> 
> What if we want to run a binary from a R/O media? We can union mount
> something on the top of it to use the modified binary, but it does not
> sounds very appealing

sounds fine to me.


> What if we ever encounter a binary that checks its own sum?

if we had to patch such a thing to fix assumptions about executability
of mappings, then we could patch the checksum that it's looking for as well.


> What if we encounter a binary that really wants an executable stack (or
> heap)? 
> 
> The latter problem is not specific to emulations and should probably be
> addressed system-wide. After all, while it's a major security
> improvement, no standard document said the stack and heap should be non
> executable. 

no written standard requires that the heap or stack be executable by default
either.  any netbsd-native program that assumes that these regions of memory
are executable by default has a bug.


> For that reasons, a sysctl in the proc subtree seems useful. Is it
> really hard to implement? We could have a p_flag about non exeutable
> mappings. In how many places we'd have to check for it?  

it's not a question of whether it's hard to implement, it's whether or not
it's really a good idea.  at this point I'm saying that it's not.

-Chuck