[grsec] difference between "new" and "legacy" toolchain

Ned Ludd solar at gentoo.org
Mon Nov 1 15:10:39 EST 2004


On Sat, 2004-10-30 at 20:37, Marcel Meyer wrote:
> Thank you all for answering my question. :-)
> 
> Am Samstag, 30. Oktober 2004 20:15 schrieb pageexec at freemail.hu:
> > > enabling the PAX features requires your applications beeing compiled
> > > with "a new toolchain". Now I'm wondering what's that exactly. Does
> > > this only mean, I need simply a quite recent gcc/coreutils/etc. or
> > > what's so special about the needed toolchain?
> >
> > you need only a new binutils (ld) and you can find the patch on the
> > PaX homepage. gentoo already includes it by default, [...]
> Ah, ok. That explains my confusion. It did work with my current toolchain 
> (using gentoo) but I did not need to patch it...
> 
> Thanks for mentioning it.
> 
> BTW: I read through some docs and decided to add the following flags. Are 
> they OK for the toolchain mentioned above together with PAX/GRsecurity or 
> too less/much (I mean do they interfere or are simply useless with the 
> special patched toolchain)?
> 

> CFLAGS="-O2 -march=i686 -pipe -fomit-frame-pointer -fstack-protector-all 
> -fPIE -fPIC"
> LDFLAGS="-Wl,-z,now -Wk,-z,relro"

Adding these flags to your global CFLAGS/LDFLAGS can be problematic in
some ebuilds due to general mislogic in many Makefiles. 
It's recommended to use the hardened toolchain which was designed to
provide the optimal ELF when using PaX/grsec.

You should remove -fPIC -fPIE -fstack-protector-all and your LDFLAGS
from your global make.conf 

If you not already then to make the switch to the hardened-x86 profile
you would do

cd /etc/ && \
rm make.profile && \
ln -s ../usr/portage/profile/hardened/x86 make.profile

cd /usr/portage/scripts/
sh ./bootstrap.sh -p -v ; # (pretend verbose. remove when happy)
emerge -e world

--
For other distributions out there (deb/redhat/fedora/slack/vanilla/most
others) really only have legacy toolchains at this time. Most people
will want to opt for adding both EI_PAX and PT_PAX_FLAGS while making
the transition to PT_PAX_FLAGS only and filing bugs with your respective
distributions to add the binutils/glibc patches before EI_PAX gets
removed from the PaX kernel all together.

Or just use the RBAC system to control runtime executable markings as
you should. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://grsecurity.net/pipermail/grsecurity/attachments/20041101/d9ca8efb/attachment.pgp


More information about the grsecurity mailing list