In article <20040712023153.GA9150@spathi.chuq.com>,
Chuck Silvers <chuq@chuq.com> wrote:
>since it's getting to be a bit late in the game to put any kernel changes to
>conditionally map stuff executable even when the mapping is supposed to be
>non-executable, I have some alternate proposals.  there are only two
>varieties of emulated binaries that we know to have problems so far,
>so I'll talk about those individually.
>
> (1) linux powerpc
>
>     here, the problem is due to a linker bug that made the ELF load section
>     containing the GOT non-executable when it should have been executable.
>     this bug was present in the version of binutils used in the linux
>     distribution that pkgsrc installs on powerpc (Suse 7.3).  more recent
>     ppc distributions (such as yellowdog 3.0) are using a fixed version of
>     the binutils, so it would be helpful if pkgsrc encouraged people to use
>     a more modern distribution.  (suse 7.3 is also marked as "discontinued",
>     so I'd think it's probably time to move to a more recent distribution
>     for all architectures.  but anyway.)
>
>     in addition to that, it would simple to write a tool to patch the
>     ELF headers and turn on the execute bit in ELF binaries that need it,
>     so that the effects of the linker bug are undone.  it appears that
>     only statically-linked binaries are affected by the bug, so this
>     shouldn't be much of a hardship.
>
>
> (2) netbsd a.out sparc
>
>     sparc appears to be the only architecture where the hardware supports
>     non-executable mappings and netbsd ever used a.out.  in this case, the
>     permissions bits that are wrong are embedded directly in an instruction
>     in every dynamically-linked executable (where the data segment of ld.so
>     is mapped non-exectuable even though parts of it need to be executed).
>     however, I think we can come up with a heuristic for patching that
>     instruction so that we can write another tool for fixing these
>     executables as well.
>
>
>in both of these cases, the fixed binaries would continue to run fine
>anyplace they used to run, but they would work under 2.0's emulation as well.
>
>so at this point, I'm advocating not changing the kernel to deal with
>this issue at all.  that will avoid any security issue, while still allowing
>use of the legacy binaries (after a one-time procedure to fix them).
>of course, we would need to document all this in the 2.0 release notes.

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".

christos