On 27 Jan 2007 at 19:40, gentoo-hardened-ml-01 bumpin.org wrote:
> If I paxctl -PS the ioquake3 binary it crashes on
startup with the error:
>
> PAX: execution attempt in: /dev/zero
>
> logged to the syslog. If I paxctl -ps ioquake3 it runs
fine. Of course
> mprotect is disabled in both cases.
this is then a sign that the application doesn't create its
mappings
with proper access rights, that is, it's mmap'ing without
PROT_EXEC
and then tries to execute code in there. having grepped
through the
quake3 sources i can't find any mention of /dev/zero, so it
might be
a library or something, only further debugging can reveal it
(and it's
an application bug somewhere, so it should be found and
fixed).
second, i also looked at how the quake3 engine generates
code at runtime
and i think the i386 port should follow that amd64 version
which puts
it into a file then mmap's it - this can run with full PaX
permissions
(of course, this mitigates the issue to filesystem access
control, but
is still better than in-memory JIT compilation).
third, the Makefile has the HAVE_VM_COMPILED option, if you
set it to
false, it should use the interpreter instead and would again
allow full
PaX enforcement (but i guess it also costs performance,
would be worth
a measurement).
> If I use the SSP-enabled toolchain, I'll loose my
ability to toggle this
> protection off and on at will right?
correct.
> Am I correct that the only work arounds in this case
would involve
> some kind of recompiling with per-package flags, etc.?
it's not some kind of recompiling, it's recompiling . and the
way
to control ssp use is via gcc specs file, that is, you'd
have to switch
to a nossp profile before emerging quake3.
--
gentoo-hardened gentoo.org mailing list
|