Re: [gentoo-hardened] Gcc4.1.1 with hardened

[Kevin F. Quinn]

On Tue, 12 Sep 2006 15:02:16 -0400
7v5w7go9ub0o <7v5w7go9ub0o@×××××.com> wrote:

> (O.K....... I'll be the sacrificial bozo :-) )
>
> I've been running hardened kernels for a year or so with hardened pic
> in make.conf; but never changed my profile to hardened. PAX seemed to
> work fine (killed some flakey stuff), as did grsecurity.
>
> So IIUC, I now have 4.1.1 with neither PAX nor SPP (wondered why
> Xorg worked so well without paxctl tweaks).
>
> IIUC, I have at least four alternatives:
>
> a. Change my profile, revert to 3.4, and recompile everything - in
> anticipation of upgrading to 4.1.1 when it becomes hardened-capable.
> (two big upgrades - not my favorite alternative)

Well, you would only need to rebuild the stuff you've built with the
4.1.1 compiler.  You can find out what compiler version a package was
built with by rifling through
the /var/db/pkg/<category>/<package-version>/environment.bz2 files and
checking which compiler version was first in line on the PATH variable.

> b. Wait 'til 4.1.1 becomes ready and then compile everything with a
> hardened profiles. (one big upgrade)
>
> c. Wait 'til 4.2.x is issued and then compile everything......

You don't really need to rebuild everything all in one go, provided you
keep the previous compiler versions installed, so you could take a
phased approach to it.

> d. (?) Hand-job my gcc settings somehow (e.g.):
>
> "...the current toolchain implements the equivalent of CFLAGS="-fPIE
> -fstack-protector-all" LDFLAGS="-Wl,-z,now -Wl,-z,relro"
> automatically through GCC's specfile which is a more proper solution.

Note; the comment about CFLAGS and LDFLAGS is really only to help
illustrate what the hardened toolchain does.  If you tried setting the
above in CFLAGS and LDFLAGS things would go wrong - especially putting
'-fPIE' in CFLAGS, which will cause TEXTRELs to appear in shared
libraries, and probably interferes with preloading.

As far as tweaking the specs yourself goes, you're welcome to try but I
wouldn't recommend it unless you're confident you know what you're
doing :)

> For older hardened-gcc users, add USE="hardened pic" to
> your /etc/make.conf and then upgrade with the following commands
> # emerge --oneshot binutils gcc virtual/libc
> # emerge -e world"
>
> So, given that I'm a newbie, and that my next move is all about
> timing, the questions are:
>
> 1. How long 'til 4.1.1 will be released to hardend profiles (this is
> not a nag, just need a planning window)?

Well, I'm kinda aiming to have it done this year, but bear in mind even
then it'll be "experimental" (like Grsecurity/PaX is on a 2.6 kernel) -
mainly because the SSP implementation in 4.x is completely new, so we
have little experience of it.

> 2. Will alternative d. even work? If so, would reemerging the
> hardened profile undo those tweaks when 4.1.1 is harde``ned ready?

You don't emerge a profile, you just set the /etc/make.conf soft link.
The profile just has the default USE flags, default packages and
masking.  As such it only changes what happens when you use emerge in
the future; it doesn't change what you have now.

> 3. How long 'til 4.2.x becomes hardened available, and will it be a
> emerge world?

4.2 is likely to be less of a jump than from 3.4 to 4.1 (we're
skipping 4.0 as it didn't have any SSP).  Once we have it sorted for 4.1
I'm expecting it'll just move forward with each release as it did for
3.x.  As to when - well, I'd worry about that later.  

> > Unmasking gcc-4.1.1 will work in as much as it'll build stuff that
> > runs fine, but it'll compile everything vanilla unless you modify
> > the specs file yourself.           <=======
>
>
> > This means that you won't get PIE executables (so PaX
> > ASLR won't do anything), you won't be building with the stack
> > protector, stuff won't be RELRO/BIND_NOW.
> >
> > See the docs on the project website for more information
> > http://www.gentoo.org/proj/en/hardened/ <===  Yep.... with a
> > microscope :-)

-- 
Kevin F. Quinn