Hardened Gentoo Adventures by radegand

Firefox 5 with MPROTECT on...of course!

2011-06-25T22:37:00.004+01:00

While the Firefox 4 ebuild is still warm, here comes Firefox 5! And yes - we want MPROTECT enabled on it too of course...! ;)

BTW, if you've ever wondered why I'm so preoccupied about the whole mrprotect story, I recommend reading my year old research on the topic which can be found here.

Well, it turns out to be, that with the release of the new Firefox things got much easier actually! There is no need to patch the source anymore, we just need to disable the 'jit' during source configuration. Not only this allows us to actually compile Firefox 5 on Gentoo hardened (sic!) but actually allows to run it with mprotect enabled too! But first things first...

An attempt to install Firefox 5 on Gentoo Hardened system is likely to end up with emerge failing and entry in kern.log similar to this:


grsec: denied RWX mmap of  by /var/tmp/portage/www-client/firefox-5.0/work/mozilla-release/obj-x86_64-unknown-linux-gnu/dist/bin/xpcshell[xpcshell:10891] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:10882] uid/euid:0/0 gid/egid:0/0                                                                                                            
xpcshell[10891]: segfault at 41ea0ddc ip 00006b9475051ed4 sp 000078b37e81b6f0 error 4 in libxul.so[6b9474031000+1823000]

While jit seems to like RWX memory pages a lot, Gentoo hardened users do not...;)

But fear not! The trustworthy hack for Firefox 4 works here too, and we don't need to hack the source, it's just enough to add --disable-methodjit the configure script. (For more information on how to create your local overlay have a look at my previous post or refer to your favourite search engine ;) . So basically you could add this to the ebuild, somewhere in the src_configure() section:


        if ! use jit ; then
                mozconfig_annotate '' --disable-methodjit
        fi

..recompile...and off you go! At the moment the firefox binary (/usr/lib/firefox/firefox-bin) is quite likely to have mprotect automatically disabled so you might need to enable it by hand by running:


paxctl -M /usr/lib/firefox/firefox-bin

Bear in mind that Firefox now runs plugins in a separate process - plugin-container. It can also be mprotect enabled or disabled, so you might want to check it too...it's worth noting that enabling mprotect on plugin-container will make Firefox crash probably on every use of Flash or Java, but hey, it's secure then, is it not...? ;)

Gentoo bug tracking all this can be found here.

Enabling MPROTECT on Firefox 4

2011-06-13T20:11:00.006+01:00

...so after nearly a year (sic!), here's the solution to get MPROTECT working with Firefox - browsing the Interwebs can be secure again! ;) Thanks to zakalwe on #grsecurity@OFTC for the patch and help! :)

So the problem of course is JIT - we need to disable it at all cost! (You'll be probably losing some JS performance, ya've been warned!). Well, it's not the most elegant solution, but it does work...The elegant solution would be of course to have an compilation option available to completely disable JIT...

Anyway - let's get our hands dirty, shall we?

The easiest way to do it, would be to create your local overlay (unless you've already got one). Assuming that you don't here's what needs to be done. Choose a folder where you will store you local ebuild - say /usr/local/portage. Next create there required folder structure:


mkdir /usr/local/portage
mkdir -p /usr/local/portage/net-libs/xulrunner

Yes, we actually need to amend the xulrunner ebuild and not the firefox one.

Now we need to copy the "original" ebuild along with the patches which will serve as a baseline:


cp /usr/portage/net-libs/xulrunner/xulrunner-2.0.1-r1.ebuild /usr/local/portage/net-libs/xulrunner/
cp -r /usr/portage/net-libs/xulrunner/files/ /usr/local/portage/net-libs/xulrunner/

Now open the copied ebuild in your favourite editor and locate the following code:


    mozconfig_annotate '' --with-default-mozilla-five-home="${MOZLIBDIR}"
    mozconfig_annotate '' --enable-extensions="${MEXTENSIONS}"
    mozconfig_annotate '' --disable-mailnews
    mozconfig_annotate '' --enable-canvas
    mozconfig_annotate '' --enable-safe-browsing
    mozconfig_annotate '' --with-system-png
    mozconfig_annotate '' --enable-system-ffi
    mozconfig_use_enable system-sqlite
    mozconfig_use_enable gconf

Add after the last mozconfig_annotate line the following code:


mozconfig_annotate '' --disable-jit
mozconfig_annotate '' --disable-methodjit

...so the whole chunk looks like this:


    mozconfig_annotate '' --with-default-mozilla-five-home="${MOZLIBDIR}"
    mozconfig_annotate '' --enable-extensions="${MEXTENSIONS}"
    mozconfig_annotate '' --disable-mailnews
    mozconfig_annotate '' --enable-canvas
    mozconfig_annotate '' --enable-safe-browsing
    mozconfig_annotate '' --with-system-png
    mozconfig_annotate '' --enable-system-ffi
    mozconfig_annotate '' --disable-jit
    mozconfig_annotate '' --disable-methodjit
    mozconfig_use_enable system-sqlite
    mozconfig_use_enable gconf

Halfway through! Now, unfortunately that is not enough - we'll have to patch xulrunners source too...so here we go!

First, create folder where we can save our patch to be automatically picked up during compilation. It could be added explicitly to the ebuild but this way is just easier and less scary for some perhaps ;)


mkdir -p /etc/portage/patches/net-libs/xulrunner

...and save in that folder file (under whatever name) with the content below:


diff -Nurp ./mozilla-2.0/js/src/assembler/wtf/Platform.h 
./mozilla-2.0.new/js/src/assembler/wtf/Platform.h
--- ./mozilla-2.0/js/src/assembler/wtf/Platform.h       2011-05-12 
22:06:56.000000000 +0100
+++ ./mozilla-2.0.new/js/src/assembler/wtf/Platform.h   2011-05-12 
22:12:35.000000000 +0100
@@ -918,15 +918,7 @@ on MinGW. See https://bugs.webkit.org/sh
 #if !defined(ENABLE_YARR_JIT)
 
 /* YARR supports x86 & x86-64, and has been tested on Mac and Windows. */
-#if (WTF_CPU_X86 \
- || WTF_CPU_X86_64 \
- || WTF_CPU_ARM_TRADITIONAL \
- || WTF_CPU_ARM_THUMB2 \
- || WTF_CPU_X86)
-#define ENABLE_YARR_JIT 1
-#else
 #define ENABLE_YARR_JIT 0
-#endif
 
 #endif /* !defined(ENABLE_YARR_JIT) */

Nearly there! Now, we need to create digest for our newly created ebuild,so:


# ebuild /usr/local/portage/net-libs/xulrunner/xulrunner-2.0.1-r1.ebuild digest
>>> Creating Manifest for /usr/local/portage/net-libs/xulrunner

...and tell portage to use our local ebuild:


echo PORTDIR_OVERLAY="/usr/local/portage" >> /etc/make.conf

Ready to compile! Emerging xulrunner should give you output similar to this:


# emerge -av xulrunner

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ~] net-libs/xulrunner-2.0.1-r1  USE="alsa crashreporter dbus ipc webm wifi -custom-optimization -debug -gconf -libnotify -startup-notification -system-sqlite" 0 kB [0=>1]

Total: 1 package (1 reinstall), Size of downloads: 0 kB
Portage tree and overlays:
 [0] /usr/portage
 [1] /usr/local/portage

As can be seen, our new ebuild is just about to be emerged!

Make sure that you see the code being patched (I named the patch jit.patch)


...
 *   5009_use_system_libffi.patch ...                                                                                                                                        [ ok ]
 * Done with patching
 * Applying mozilla-2.0_support_64bit_big_endian.patch ...                                                                                                                   [ ok ]
 * Applying user patches from /etc/portage/patches//net-libs/xulrunner ...
 *   jit.patch ...                                                                                                                                                         [ ok ]  
 * Done with patching
...

...and then when the summary of config options is displayed (seconds later), you will see this:


    --with-system-png               mozilla.org default
    --enable-system-ffi             mozilla.org default
    --disable-jit                   mozilla.org default
    --disable-methodjit             mozilla.org default
    --disable-system-sqlite         -system-sqlite
    --disable-gconf                 -gconf
==========================================================

Looks good! So after short while...perfect for a cup of coffee or a pint of your favourite lager, xulrunner is ready! Now we need to recompile firefox itself against it...


emerge firefox

The ebuild will still disable mprotect on Firefox as we haven't touched it. Just before we enable it using paxutils, we need to disable all the JIT options in Firefox itself. So start it up, type "about:config" in the address bar and hit enter. Don't be worry about loosing warranty ;) Type jit in the filter and disable any option that is set to 'true' (click twice on it to change its value). Close Firefox and we can enable mprotect now!


# paxctl -v /usr/lib/firefox/firefox 
PaX control v0.5
Copyright 2004,2005,2006,2007 PaX Team 

- PaX flags: -----m-x-e-- [/usr/lib/firefox/firefox]
        MPROTECT is disabled
        RANDEXEC is disabled
        EMUTRAMP is disabled

But that's not what we want! So:


# paxctl -M /usr/lib/firefox/firefox 
# paxctl -v /usr/lib/firefox/firefox 
PaX control v0.5
Copyright 2004,2005,2006,2007 PaX Team 

- PaX flags: ----M--x-e-- [/usr/lib/firefox/firefox]
        MPROTECT is enabled
        RANDEXEC is disabled
        EMUTRAMP is disabled

Start Firefox and...voila - it works! :)

It is worth noting, that plugins now run in a separate process: plugin-container which is normally located in /usr/lib/xulrunner-2.0/. To achieve best security, it should have the mprotect flag enabled as well. (Un)fortunatelly - flash will not work! So if you don't care about youtube and alike:


paxctl -M /usr/lib64/xulrunner-2.0/plugin-container

To verify that it is actually working you can find the PID of firefox running the ps command and then cat /proc/PID/status and at the bottom there will be something like this:


Cpus_allowed:   f
Cpus_allowed_list: 0-3
Mems_allowed:   00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches:     21023
nonvoluntary_ctxt_switches:  1664
PaX:  PeMRs

...where the capital 'M' stands for enabled MPROTECT. How cool is that? ;) Enjoy!

Grsecurity, Firefox, MPROTECT and You!

2010-07-28T20:45:00.003+01:00

Firefox is definitely one of this pieces of software where you want to have all of the available security options enabled :) And one of those features that you might REALLY want is MPROTECT (brought to you by the grsecurity ;)). Making long story short, it works by restricting the mprotect() system call which makes life of an attacker much more difficult because they cannot simply change protection of a specific memory region (mark it as executable if it wasn't originally executable) or create a new writeable&executable memory mapping using the mmap() call. Without this feature, all the 'non-executable memory regions' hype in your system is more or less useless, as the permission could be simply changed by the attacker. So far so good :)

However, you can notice that Gentoo by default disables this protection (without really telling user why!) as it usually wreaks havoc with flash and java plugins and sometimes the browser itself...but what if you don't really care about these and you do want to have this on? Well, it gets more interesting...historically, Firefox had issues with MROTECT every now and then, so how does it look like with the latest 3.6.8 release?

During the emerge process you can see this:


 * Legacy EI PaX marking -m
 *      /var/tmp/portage/www-client/firefox-3.6.8/image///usr/lib64/mozilla-firefox/firefox
 * PT PaX marking -m
 *      /var/tmp/portage/www-client/firefox-3.6.8/image///usr/lib64/mozilla-firefox/firefox

Which can be also confirmed by using the paxctl tool:


# paxctl -v /usr/lib64/mozilla-firefox/firefox 
PaX control v0.5
Copyright 2004,2005,2006,2007 PaX Team 

- PaX flags: -----m-x-e-- [/usr/lib64/mozilla-firefox/firefox]
        MPROTECT is disabled
        RANDEXEC is disabled
        EMUTRAMP is disabled

Not really what we wanted...let's reset it! (you need to run this command as root)


# paxctl -z /usr/lib64/mozilla-firefox/firefox 
# paxctl -v /usr/lib64/mozilla-firefox/firefox 
PaX control v0.5
Copyright 2004,2005,2006,2007 PaX Team 

- PaX flags: ------------ [/usr/lib64/mozilla-firefox/firefox]

That's better! Ok, but does it actually work?


$ firefox
Segmentation fault

Ooops...not good! So what's the problem? Last few lines of strace output show the answer:


mmap(NULL, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EPERM (Operation not permitted)
mprotect(0xfffffffffffff000, 69632, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 ENOMEM (Cannot allocate memory)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
unlink("/home/radegand/.mozilla/firefox/ekyjebvs.default/lock") = 0
rt_sigaction(SIGSEGV, {SIG_DFL, [], SA_RESTORER, 0x3434af56120}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [SEGV], NULL, 8) = 0
tgkill(26608, 26608, SIGSEGV)           = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault

The mmap() call above tries to create a writeable and executable memory mapping (which is not permitted by Grsecurity) which is followed by a call to mprotect() to set the same permission ('rwx'), which is also not permitted...so then it segfaults...:)

Luckily, there's a workaround! From information gathered on IRC, the following two options would allow Firefox to run with the MPROTECT feature on:


user_pref("javascript.options.jit.chrome", false); 
user_pref("javascript.options.jit.content", false);

They should be added in the prefs.js file located in the Firefox profile folder:


/home/[your_user]/.mozilla/firefox/[random_string].default/

...and then Firefox will run happily ever after...or so one would hope... ;)

Of course you could disable MPROTECT, start Firefox, go to about:config and add the options above. But do you really want to run your browser without this protection, even just for few seconds? ;) Well, if JIT really needs 'rwx' pages, given for instance this issue, I'm not sure if I would... ;P

Ok, but what is the real cause of the problem? Let's see...unpack the source code and have a poke around - Gentoo ebuild system comes handy here:


# ebuild /usr/portage/www-client/firefox/firefox-3.6.8.ebuild unpack
# cd /var/tmp/portage/www-client/firefox-3.6.8/work/
work # grep -R -i PROT_EXEC *
mozilla-1.9.2/js/ctypes/libffi/src/closures.c:   don't attempt PROT_EXEC|PROT_WRITE mapping at all, as that
mozilla-1.9.2/js/ctypes/libffi/src/closures.c:  ptr = mmap (NULL, length, (prot & ~PROT_WRITE) | PROT_EXEC,
mozilla-1.9.2/js/ctypes/libffi/src/closures.c:      ptr = mmap (start, length, prot | PROT_EXEC, flags, fd, offset);
mozilla-1.9.2/js/ctypes/libffi/src/closures.c:   with ((prot & ~PROT_WRITE) | PROT_EXEC) and mremap with
mozilla-1.9.2/js/ctypes/libffi/testsuite/libffi.call/ffitest.h:  page = mmap (NULL, size, PROT_READ | PROT_WRITE | PROT_EXEC,
mozilla-1.9.2/js/ctypes/libffi/testsuite/libffi.call/ffitest.h:  page = mmap (NULL, size, PROT_READ | PROT_WRITE | PROT_EXEC,
mozilla-1.9.2/js/ctypes/libffi/testsuite/libffi.special/ffitestcxx.h:  page = mmap (NULL, size, PROT_READ | PROT_WRITE | PROT_EXEC,
mozilla-1.9.2/js/ctypes/libffi/testsuite/libffi.special/ffitestcxx.h:  page = mmap (NULL, size, PROT_READ | PROT_WRITE | PROT_EXEC,
mozilla-1.9.2/js/src/nanojit/avmplus.cpp:    flags |= PROT_EXEC;
mozilla-1.9.2/js/src/nanojit/avmplus.cpp:                PROT_READ | PROT_WRITE | PROT_EXEC,
mozilla-1.9.2/layout/base/tests/TestPoisonArea.cpp:  return mprotect((caddr_t)page, PAGESIZE, PROT_READ|PROT_WRITE|PROT_EXEC);
mozilla-1.9.2/layout/base/tests/TestPoisonArea.cpp:  // (mmap(PROT_EXEC) may fail when applied to anonymous memory.)
mozilla-1.9.2/nsprpub/lib/msgc/src/unixgc.c:    addr = mmap(lastaddr, size, PROT_READ|PROT_WRITE|PROT_EXEC,
mozilla-1.9.2/nsprpub/lib/msgc/src/unixgc.c:    addr = mmap(base + oldSize, allocSize, PROT_READ|PROT_WRITE|PROT_EXEC,
mozilla-1.9.2/nsprpub/pr/src/md/unix/nextstep.c:                case PROT_EXEC:         mach_prot = VM_PROT_EXECUTE;    break;
mozilla-1.9.2/nsprpub/pr/src/md/unix/unix.c:    prot |= PROT_EXEC;
mozilla-1.9.2/toolkit/crashreporter/google-breakpad/src/google_breakpad/common/minidump_exception_mac.h:  /* EXC_I386_EXTOVRFLT =  9: mapped to EXC_BAD_ACCESS/(PROT_READ|PROT_EXEC) */

So here are your potential offenders...The next step would be to investigate the code further and try to remove the PROT_EXEC flag where it does not seem necessary, compile and test...believe it or not, it's sometimes much easier than it sounds!

...but more about it next time...

mplayer PIE on amd64 :)

2010-04-28T20:24:00.003+01:00

For ages it was not possible to compile mplayer as Position Independent Executable (at least not on amd64) - until today! To my greatest surprise it compiled fine using the default gentoo hardened gcc spec, including PIE support.

So simply sync your portage tree, emerge mplayer-1.0_rc4_p20100427 and enjoy! Watching your favourite movie has never felt so safe before! ;]


./checksec.sh --file /usr/bin/mplayer
RELRO           STACK CANARY      NX            PIE                     FILE
Full RELRO      Canary found      NX enabled    PIE enabled             /usr/bin/mplayer

...or alternatively:


readelf -h /usr/bin/mplayer
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0xcae48
  Start of program headers:          64 (bytes into file)
  Start of section headers:          9064016 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         10
  Size of section headers:           64 (bytes)
  Number of section headers:         27
  Section header string table index: 26

Enjoy the PIE! ;]

KVM setup with bridged networking

2010-04-15T18:45:00.009+01:00

The other day I hat to run my virtual machines on the same network as the host system itself and as I found information on the net to be a bit confusing I thought I could share how I came to terms with it :)

As usual I've used the following information resources - both of which have different view on the networking setup... ;) They do, however, mention all the prerequisites which have to met in order for the networking to work. So I assume that you have emerged bridge-utils and that kernel support for TUN/TAP device driver, "802.1d Ethernet Bridging" and "802.1Q VLAN Support" is enabled.

If you've been using NATed networking before, you need to remove vde from your start-up script:


rc-update vde del default

In my case my host and my VMs were getting addresses via DHCP. You could use static addresses as well - just specify the addresses for each interface manually and remember to add line for default route (see the links above for some examples on this). So below is my /etc/conf.d/net file.


bridge_br0="eth0 tap0 tap1"                                                                                           config_eth0=( "null" )
config_br0=( "dhcp" )
brctl_br0=( "setfd 0" "sethello 0" "stp off" )
rc_need_br0=( "net.tap0" "net.tap1" "net.eth0" )

config_tap0=( "null ")
tuntap_tap0="tap"
tunctl_tap0="-u radegand"
mac_tap0="00:a0:b0:c0:d0:f0"                                                                                                                                
config_tap1=( "null ") 
tuntap_tap1="tap"                                                                                
tunctl_tap1="-u radegand"
mac_tap1="00:a1:b1:c1:d1:f1"

Ok, section by section...
The first section defines the bridge to be comprised of three interfaces: one physical (eth0) and two virtual (tap0 and tap1). It then specifies that no ip address is required for eth0, instead it specifies that interface br0 will obtain it ip settings via DHCP. It also specifies some bridge options and sets dependencies for the br0 so when the init.d script is executed it can handle these properly.

The next two sections define tap0 and tap1 interfaces. It specifies that no IP address is needed for each of them (VM will get the IP instead - more on it later), the device type, the user who will have access to that device - this should be the same user who would run the VM itself. Finally - a specific mac address (you can be creative here! ;)) needs to be assigned to each tap device. You need such a section for each VM that will use the bridged network and each of such virtual interface can be used by one VM only.

Ok, time two start the new shiny interfaces! ;) Make sure that you have all the required links to start them:


ln -s /etc/init.d/net.lo /etc/init.d/net.tap0
ln -s /etc/init.d/net.lo /etc/init.d/net.tap1
ln -s /etc/init.d/net.lo /etc/init.d/net.br0

...and start them of course!:


/etc/init.d/net.tap0 start
/etc/init.d/net.tap1 start
/etc/init.d/net.br0 start

Remember to add them to a relevant boot level using rc-update when everything is tested and working fine...

Rite, now the interfaces should be up and ready to test! Let's see...


# ifconfig
br0       Link encap:Ethernet  HWaddr 00:aa:bb:cc:dd:ee  
          inet addr:192.168.0.10  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:201 errors:0 dropped:0 overruns:0 frame:0
          TX packets:150 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:16269 (15.8 KiB)  TX bytes:38080 (37.1 KiB)

eth0      Link encap:Ethernet  HWaddr 00:aa:bb:cc:dd:ee  
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:202 errors:0 dropped:0 overruns:0 frame:0
          TX packets:157 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:20135 (19.6 KiB)  TX bytes:39152 (38.2 KiB)
          Interrupt:17 

tap0      Link encap:Ethernet  HWaddr 00:a0:b0:c0:d0:f0  
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:21 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tap1      Link encap:Ethernet  HWaddr 00:a1:b1:c1:d1:f1  
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:21 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Note that the mac address of the br0 is the same as eth0 (yes, I did amended them a bit here, they're not my real mac addresses but they DO match nevertheless...)

Time to start VMs! So the magic command that needs to be added to the qemu/kvm command line which will get you bridged network is...:


-net tap,ifname=tap0,script=no,downscript=no -net nic,macaddr=00:a0:b0:c0:d0:f1

Now, the important bits are highlighted - for each of your VMs you need to use separate tap interface. Moreover, you need to specify mac address for the VM and it has to be different that the one specified for given tap interface in /etc/conf.d/net file. Of course it can be entirely different, not only by last byte - I just keep it this way to keep track of my VMs...But don't take my world for that - try using the same mac address for your VM as you set for the tap interface...and then when your VM is up and running grep the /var/log/kern.log file on your host system for:


tap0: received packet with own address as source address

So for each VM you run use different tap interface and remember to set different mac address than the tap device itself...

Ok, now you should have KVM setup up with bridged networking...no additional setup is need - no need for specific iptables rules and you don't even need to have the ip forwarding (/proc/sys/net/ipv4/ip_forward) enabled for it to work! Now - how cool is that? ;)

PS. No - it won't work with wireless, only with ethernet...if you need a wireless bridge - have a look here.

New paxtest 0.9.9

2010-03-13T13:26:00.005Z

New paxtest has been recently released! ...along with the new hardened-sources-2.6.33 ebuild (testing from the hardened-development overlay). This had to be tested! ;]

Although paxtest ebuild itself has not been updated yet, you can compile it from source or update ebuild in your local repository..

Anyway - results below:


# paxtest blackhat
PaXtest - Copyright(c) 2003,2004 by Peter Busser 
Released under the GNU Public Licence version 2 or later

Writing output to paxtest.log
It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003,2004 by Peter Busser 
Released under the GNU Public Licence version 2 or later

Mode: blackhat
Linux quad 2.6.33-hardened #1 SMP Sat Mar 13 10:00:54 GMT 2010 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable stack (mprotect)              : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments                   : Killed
Anonymous mapping randomisation test     : 33 bits (guessed)
Heap randomisation test (ET_EXEC)        : 40 bits (guessed)
Heap randomisation test (PIE)            : 40 bits (guessed)
Main executable randomisation (ET_EXEC)  : 32 bits (guessed)
Main executable randomisation (PIE)      : 32 bits (guessed)
Shared library randomisation test        : 33 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 40 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 40 bits (guessed)
Return to function (strcpy)              : paxtest: return address contains a NULL byte.
Return to function (memcpy)              : Vulnerable
Return to function (strcpy, PIE)         : paxtest: return address contains a NULL byte.
Return to function (memcpy, PIE)         : Vulnerable

Return to function is the key! ;]

Gcc-4.4.3 on Gentoo Hardened

2010-02-14T10:47:00.001Z

Freshly released version of gcc-4.4.3 is now available on gentoo hardened! ;] As usually, it is available via the hardened-development overlay. Thanks guys!

 
# gcc-config -l
 [1] x86_64-pc-linux-gnu-3.4.6
 [2] x86_64-pc-linux-gnu-3.4.6-hardenednopie
 [3] x86_64-pc-linux-gnu-3.4.6-hardenednopiessp
 [4] x86_64-pc-linux-gnu-3.4.6-hardenednossp
 [5] x86_64-pc-linux-gnu-3.4.6-vanilla
 [6] x86_64-pc-linux-gnu-4.4.3 *
 [7] x86_64-pc-linux-gnu-4.4.3-hardenednopie
 [8] x86_64-pc-linux-gnu-4.4.3-hardenednossp
 [9] x86_64-pc-linux-gnu-4.4.3-vanilla

Installing Pentoo on Hard Drive with LUKS encryption

2010-02-09T21:31:00.003Z

Pentoo is a great Linux distro created with security testing in mind - be it a penetration testing or wireless testing. I know - Backtrack 4 is out there and is cool too ;P however, being a Gentoo user you simply cannot resist Pentoo... ;) It might be just me but I find it so much easier to customise as well! And how many times you had to install something from source? And then getting all the header files and tricky dependencies right can be cumbersome...with Pentoo - you have the full Gentoo portage tree plus lots of security tools available as ebuilds at hand. If something's not there - it's so god damn easy to...compile it! ;]

Anyway - here's a quick howto how to get Pentoo installed on your hard drive with LUKS encrypted root partition and encrypted swap, too... LiveCD is great, but you might want to have something more permanent and faster...so here it goes!

Installation guides that I've used for reference:
http://www.netsc.ch/IMG/pdf/pentoo.pdf
and here:
http://trac.pentoo.ch/wiki/Livecd/Installation

Boot the LiveCD and check that networking is fine and that sshd is running (you don't necessarily need networking at this stage but I prefer to do the installation remotely). Also change root password:

 
dhcpcd eth0
/etc/init.d/sshd start
passwd

Create installation partitions. You'll at least need /boot, / (root), and swap. My setup was as follows:


pentoo ~ # fdisk -l

Disk /dev/sda: 60.0 GB, 60011642880 bytes
16 heads, 63 sectors/track, 116280 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Disk identifier: 0x6ce2c029

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         195       98248+  83  Linux
/dev/sda2             196        4071     1953504   83  Linux
/dev/sda3            4072      116280    56553336   83  Linux

sda1 - boot
sda2 - swap
sda3 - root

Onto encrypted partition creation... ;) You can of course tune the encryption options (see the cryptsetup manpage)

 
pentoo ~ # cryptsetup --verbose --cipher "aes-cbc-essiv:sha256" --key-size 256 --verify-passphrase luksFormat /dev/sda3

WARNING!
========
This will overwrite data on /dev/sda3 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.

Now open the encrypted partition and create the mapping needed for installation:


pentoo ~ # cryptsetup luksOpen /dev/sda3 root
Enter passphrase for /dev/sda3:
Key slot 0 unlocked.

Create filesystems on newly created partitions. Feel free to use your favourite filesystem - just beware with /boot partition as, for instance, grub doesn't really work with ext4...


pentoo ~ # mkfs.ext3 /dev/sda1
mke2fs 1.41.9 (22-Aug-2009)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
24576 inodes, 98248 blocks
4912 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
12 block groups
8192 blocks per group, 8192 fragments per group
2048 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 33 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

And the root partition to follow:


pentoo ~ # mkfs.ext3 /dev/mapper/root
mke2fs 1.41.9 (22-Aug-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
3538944 inodes, 14138077 blocks
706903 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
432 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 37 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Mount partitions...


pentoo ~ # mount /dev/mapper/root /mnt/gentoo/
pentoo ~ # mkdir /mnt/gentoo/boot
pentoo ~ # mount /dev/sda1 /mnt/gentoo/boot/

Don't worry about swap partition - we'll encrypt it later.

Now we need to copy files form LiveCD onto the hard drive. As there will be some overwriting happening, it's useful to unalias the cp command first:


pentoo ~ # alias
alias aemerge='ACCEPT_KEYWORDS="~x86" emerge'
alias cp='cp -i'
alias grep='grep --color=auto'
alias ll='ls -l'
alias ls='ls --color'
alias mv='mv -i'
alias rm='rm -i'

Unalias then!


unalias cp

...and then start copying the files:


cp -avf /mnt/livecd/* /mnt/gentoo
cp -avf /etc /root /mnt/gentoo
cp -avf /usr/portage /mnt/gentoo/usr

From there on it's pretty much a straight forward Gentoo installation - all tweaks allowed! ;]


pentoo ~ # mount -t proc none /mnt/gentoo/proc
pentoo ~ # mount -o bind /dev /mnt/gentoo/dev
pentoo ~ # chroot /mnt/gentoo /bin/bash
pentoo / # env-update
>>> Regenerating /etc/ld.so.cache...
pentoo / # source /etc/profile
pentoo / # export PS1="(chroot) $PS1"

Just out of curiosity:


(chroot) pentoo src # gcc-config -l
 [1] i686-pc-linux-gnu-4.3.4 *
(chroot) pentoo src # eselect profile list
Available profile symlink targets:
  [1]   default/linux/x86/10.0 *
  [2]   default/linux/x86/10.0/desktop
  [3]   default/linux/x86/10.0/developer
  [4]   default/linux/x86/10.0/server
  [5]   hardened/linux/x86/10.0
  [6]   selinux/2007.0/x86
  [7]   selinux/2007.0/x86/hardened
  [8]   selinux/v2refpolicy/x86
  [9]   selinux/v2refpolicy/x86/desktop
  [10]  selinux/v2refpolicy/x86/developer
  [11]  selinux/v2refpolicy/x86/hardened
  [12]  selinux/v2refpolicy/x86/server

Not bad! You could always switch to the hardened profile, enable the graphite extension and recompile world... ;)

Anyway - kernel compilation! I'd use a hardened-sources from the hardened-development overlay (you'll need to emerge git for that) but you can as well just stay with the stock kernel...


(chroot) pentoo src # ls -la
total 20
drwxr-xr-x  5 root root 4096 Jan 22 13:55 .
drwxr-xr-x 16 root root 4096 Dec  3 23:31 ..
lrwxrwxrwx  1 root root   31 Dec  3 23:30 linux -> /usr/src/linux-2.6.31-pentoo-r3
drwxr-xr-x 24 root root 4096 Dec  3 23:30 linux-2.6.31-pentoo-r3
drwxr-xr-x 24 root root 4096 Jan 22 13:56 linux-2.6.32-hardened-r2
drwxr-xr-x 12 root root 4096 Dec  3 21:39 mosref-2.0_beta3

The easiest way to get the kernel config file:


(chroot) pentoo src # zcat /proc/config.gz > /usr/src/linux/.config

And then you can modify it or leave it alone... :)

Edit /etc/genkernel.conf. Not really required but I like to disable clean and mrproper and add LUKS line:


CLEAN="no"
LUKS="yes"
# Run 'make mrproper' before configuration/compilation?
MRPROPER="no"

For multicore you could also add there (number of cores+1):


MAKEOPTS="-j3"

Compile! Well, not yet...if you run genkernel now it will fail with:


ld: cannot find -lcrypt

rebuilding genkernel did not help but...how about rebuilding glibc?


(chroot) pentoo linux # emerge -av glibc
 * IMPORTANT: 2 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.
These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U ] sys-libs/glibc-2.10.1-r1 [2.9_p20081201-r2] USE="-debug -gd -glibc-omitfp (-hardened) (-multilib) -nls -profile (-selinux) -vanilla" 16,511 kB

Total: 1 package (1 upgrade), Size of downloads: 16,511 kB
Would you like to merge these packages? [Yes/No]

Once it's done (few cups of chai later...)


(chroot) pentoo linux # genkernel --luks all
* Gentoo Linux Genkernel; Version 3.4.10
* Running with options: --luks all

* Linux Kernel 2.6.31-pentoo-r3 for x86...
*         >> Running oldconfig...
* config: --no-clean is enabled; leaving the .config alone.
*         >> Compiling 2.6.31-pentoo-r3 bzImage...
*         >> Compiling 2.6.31-pentoo-r3 modules...
* Copying config for successful build to /etc/kernels/kernel-config-x86-2.6.31-pentoo-r3
* busybox: >> Applying patches...
* busybox: >> Configuring...
* busybox: >> Compiling...
* busybox: >> Copying to cache...
* initramfs: >> Initializing...
*         >> Appending base_layout cpio data...
*         >> Appending auxilary cpio data...
* Including LUKS support
*         >> Appending busybox cpio data...
*         >> Appending e2fsprogs cpio data...
* E2FSPROGS: Adding support (compiling binaries)...
* e2fsprogs: >> Configuring...
* e2fsprogs: >> Compiling libs...
* e2fsprogs: >> Compiling e2fsck...
* e2fsprogs: >> Compiling mke2fs...
* e2fsprogs: >> Copying to cache...
*       >> Copying to bincache...
*         >> Appending modules cpio data...
*
* Kernel compiled successfully!
*
* Required Kernel Parameters:
*     real_root=/dev/$ROOT
*
*     Where $ROOT is the device node for your root partition as the
*     one specified in /etc/fstab
*
* If you require Genkernel's hardware detection features; you MUST
* tell your bootloader to use the provided INITRAMFS file. Otherwise;
* substitute the root argument for the real_root argument if you are
* not planning to use the initrd...

* WARNING... WARNING... WARNING...
* Additional kernel cmdline arguments that *may* be required to boot properly...

* Do NOT report kernel bugs as genkernel bugs unless your bug
* is about the default genkernel configuration...
*
* Make sure you have the latest genkernel before reporting bugs.
(chroot) pentoo linux #

Yuppie!!

Edit the /etc/fstab file:


/dev/sda1               /boot           ext3            noauto,noatime  1 2
/dev/mapper/root        /               ext3            noatime         0 1
/dev/mapper/crypt-swap  none            swap            sw              0 0

Ok, time to create LUKS mappings:


vi /etc/conf.d/dmcrypt

...and add your swap partition:


swap=crypt-swap
source='/dev/sda2'

Now the bootloader:


nano /boot/grub/menu.lst

If you've installed the stock kernel that's how it should look like:


title Pentoo Linux 2.6.31-r3
root (hd0,0)
kernel /boot/kernel-genkernel-x86-2.6.31-pentoo-r3 crypt_root=/dev/sda3 real_root=/dev/mapper/root
initrd /boot/initramfs-genkernel-x86-2.6.31-pentoo-r3

Rite - unfortunately we now need to install new config file manually - run grub:



    GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename. ]

grub> root (hd0)
 Filesystem type unknown, using whole disk

grub> root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83

grub> setup (hd0)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  17 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd0) (hd0)1+17 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.lst"... s
ucceeded
Done.

grub>

Voila! Few boot script tweaks...


(chroot) pentoo linux # rc-update del autoconfig default
* service autoconfig removed from runlevel default
(chroot) pentoo linux # rc-update add keymaps default
* service keymaps added to runlevel default
(chroot) pentoo linux #rc-update add dmcrypt boot
* service dmcrypt added to runlevel default

Edit the keymap file if you wish...


nano /etc/conf.d/keymaps

Done...reboot & enjoy! ;]

Nouveau driver with KMS support on Hardened

2010-01-23T17:02:00.004Z

I got annoyed recently with the nv driver and still not being able to use the proprietary nvidia driver I decided to try nouveau driver...and it worked! :) Additional bonus was - KMS - fast switching between X and console...finally!

Ok, here we go. A recent kernel will be needed, I'm using the 2.6.32 hardened sources, but anything >= 2.6.31 should do. xorg-server-1.7 will be required though. So before you try, make sure that you have it up and running and that everything works as it should - I had some non obvious dependencies to solve...anyway!

There's a installation guide provided which helps a lot ;]

Make sure that your kernel have debugfs support compiled (in "Kernel Hacking" enable "Debug Filesystem") and I also had to enable UVESA option ( "Device drivers" -> "Graphics support" -> "Support for framebuffer devices" -> "Userspace VESA VGA support"). Recompile and reboot to your new kernel.

Disable the proprietary module if you were using it (unlikely on hardened! ;P). As per guide switch opengl to X11:


# eselect opengl set xorg-x11
Switching to xorg-x11 OpenGL interface... done

Make sure you have USE="dri" and VIDEO_CARDS="nouveau" set in make.conf. Try emerging this (You'll probably need to keyword and unmask these ebuilds):


# emerge -va nouveau-drm libdrm xorg-server xf86-video-nouveau

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    ] x11-drivers/nouveau-firmware-20091212  0 kB [1]
[ebuild  N    ] x11-libs/libdrm-9999  USE="-static-libs" 0 kB [1]
[ebuild  N    ] x11-base/nouveau-drm-99999999  0 kB [1]
[ebuild   R   ] x11-base/xorg-server-1.7.4  USE="hal ipv6 nptl sdl xorg -debug -dmx -kdrive -minimal -tslib" 0 kB [0]
[ebuild  N    ] x11-drivers/xf86-video-nouveau-9999  USE="-static-libs" 0 kB [1]

Total: 5 packages (4 new, 1 reinstall), Size of downloads: 0 kB
Portage tree and overlays:
 [0] /usr/portage
 [1] /usr/local/portage/layman/x11

Would you like to merge these packages? [Yes/No]

This should look similar to this above. Pay attention to packages that need to be pulled from the x11 overlay rather than portage tree.

Once everything is compiled, change the xorg.conf to use new driver - replace:


Driver         "nv"

with:


Driver         "nouveau"

Enable relevant modules to be loaded during boot. The /etc/conf.d/modules should something like this:


modules_2_6="dri nouveau"

Do not modprobe the nouveau driver from within X! It will kill it... ;] Stop X, modprobe and start X again...or simply reboot...end enjoy the new driver and KMS!

Wireshark on Gentoo hardened

2009-10-29T21:52:00.003Z

If compiling wireshark bails out with the following error:


checking for GTK+ - version >= 2.4.0... no
*** Could not run GTK+ test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means GTK+ is incorrectly installed.
configure: error: GTK+ 2.4 or later isn't available, so Wireshark can't be compiled

Disable the 'profile' flag as per this bug. So the magic command is:


USE="-profile" emerge wireshark

Happy sniffing! ;]

Injection support with Intel 3945 A/B/G card

2009-10-23T18:59:00.004+01:00

I've used this chipset for quite a while now and since some time it very stable, well supported and built in antenna provides decent reception. It's not N capable but it does A band! Getting it to work on a decent kernel is trivial and Gentoo hardened is no exception. ;]

First, make sure that you have it enabled in your kernel config - in Wireless LAN section enable "Intel PRO/Wireless 3945ABG/BG Network Connection" - I tend to compile it as a module so I can load it only when necessary - just in case, I prefer to have it disabled... ;] If needed, recompile and boot your new kernel, then continue.

You probably want to emerge aircrack suite if not already done so. Aircrack has a cool feature to test injection support and can do sooo much more than that! You need to make sure that you will emerge aircrack from the 'hardened-development' overlay because otherwise it won't compile on hardened. It has some inline assembly which unfortunately does not like to be compiled as PIE, at least at the time being ;( Anyway:


~ # emerge -av aircrack-ng

These are the packages that would be merged, in order:

Calculating dependencies ... done!
[ebuild  N    ] net-wireless/aircrack-ng-1.0  USE="sqlite" 1,472 kB [1]

Total: 1 package (1 new), Size of downloads: 1,472 kB
Portage tree and overlays:
 [0] /usr/portage
 [1] /usr/local/portage/layman/hardened-development

Would you like to merge these packages? [Yes/No]

Cool, once it's done it's time to load the module:


host ~ # modprobe iwl3945

Which should result in the following output via the dmesg command:


iwl3945 0000:0c:00.0: PCI INT A disabled
iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26ks
iwl3945: Copyright(c) 2003-2009 Intel Corporation
iwl3945 0000:0c:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
iwl3945 0000:0c:00.0: setting latency timer to 64
iwl3945 0000:0c:00.0: Tunable channels: 13 802.11bg, 23 802.11a channels
iwl3945 0000:0c:00.0: Detected Intel Wireless WiFi Link 3945ABG
iwl3945 0000:0c:00.0: irq 24 for MSI/MSI-X
phy2: Selected rate control algorithm 'iwl-3945-rs'

Sweet! Let's enable monitor mode then, shall we? Command airmon-ng when run without any parameters will show list of wireless cards recognised by the system along with their respective drivers - quite useful!


~ # airmon-ng
Interface       Chipset         Driver
wlan1           Atheros         ath5k - [phy1]
mon0            Atheros         ath5k - [phy1]
wlan0           Intel 3945ABG   iwl3945 - [phy2]

Right, so the card is there, now the monitor mode itself:


~ # airmon-ng start wlan0
Interface       Chipset         Driver

wlan1           Atheros         ath5k - [phy1]
mon0            Atheros         ath5k - [phy1]
wlan0           Intel 3945ABG   iwl3945 - [phy2]SIOCSIFFLAGS: No such file or directory
                                (monitor mode enabled on mon1)

Hmm...that didn't look good, let's see what has happened...that's what I got from dmesg again:


iwl3945 0000:0c:00.0: firmware: requesting iwlwifi-3945-2.ucode
iwl3945 0000:0c:00.0: iwlwifi-3945-2.ucode firmware file req failed: -2
iwl3945 0000:0c:00.0: firmware: requesting iwlwifi-3945-1.ucode
iwl3945 0000:0c:00.0: iwlwifi-3945-1.ucode firmware file req failed: -2
iwl3945 0000:0c:00.0: Could not read microcode: -2

Oppsie! Right, so required firmware file is missing but there's a trustworthy Gentoo repository! ;] So:


~ # emerge -av iwl3945-ucode

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    ] net-wireless/iwl3945-ucode-15.32.2.9  66 kB

Total: 1 package (1 new), Size of downloads: 66 kB

Would you like to merge these packages? [Yes/No]

Yesss! When it's installed we need to reload the module and then start the monitor mode again:


~ # rmmod iwl3945
~ # modprobe iwl3945
~ # airmon-ng start wlan0
Interface       Chipset         Driver

wlan1           Atheros         ath5k - [phy1]
mon0            Atheros         ath5k - [phy1]
wlan0           Intel 3945ABG   iwl3945 - [phy3]
                                (monitor mode enabled on mon1)

Which resulted in the following in the dmesg:


iwl3945 0000:0c:00.0: firmware: requesting iwlwifi-3945-2.ucode
iwl3945 0000:0c:00.0: loaded firmware version 15.32.2.9

Yuppie! Now run aircrack as a final test:


~ # aireplay-ng -9 mon1
20:38:16  Trying broadcast probe requests...
20:38:16  Injection is working!

Bakgat!

HowTo update

2009-10-19T21:47:00.002+01:00

I've just setup another box according to my earlier HowTo - just to test it accuracy ;). I've spotted few mistakes which should be now fixed. In the meantime kernel got updated to 2.6.31.4 and KDE to 4.3.2 ;] It also seems that nepomuk is now fine with grsec kernels - it compiles and runs without segfaulting! ;]
Happy Compiling!

64-bit Hardened Gentoo with LUKS on 2.6.31.1-grsec, glibc-2.10 and gcc-4.4.1. With KDE-4.3.1. From scratch.

2009-10-03T12:46:00.011+01:00

UPDATED 23/10 - Added info about repos.conf which I've missed previously!

Recenty I had to setup a new box with the specs above so I decided to share my installation notes in an attempt to spread the Gentoo virus ;] Apologies if they're not always as detailed as they could be but nevertheless should be helpful for anyone setting up a new Gentoo box. Ok, off we go!

I've mostly used as a reference the following links:

The Hardened GCC4 Toolchain Overlay Guide

LUKS on Gentoo

I used this live CD and this stage3 tarball because I wanted to give a go for the weekly hardened ones just out of curiosity :). Also, as soon as it was possible I've ssh'ed to the new box to make command pasting (and saving!) much easier.

Follow the Gentoo Installation handbook up to chapter 4. Ok, disk preparation - below I have created a 100MB boot partition (will have to stay unencrypted), 2G of SWAP space and root partition on the remaining disk space for rest of the system.


livecd ~ # fdisk /dev/sda                                                                                                           
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel                                                  
Building a new DOS disklabel with disk identifier 0x24c78168.                                                                       
Changes will remain in memory only, until you decide to write them.                                                                 
After that, of course, the previous content won't be recoverable.                                                                   


The number of cylinders for this disk is set to 10011.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:               
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs            
   (e.g., DOS FDISK, OS/2 FDISK)                               
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): n
Command action         
   e   extended        
   p   primary partition (1-4)
p                             
Partition number (1-4): 1     
First cylinder (1-10011, default 1): 
Using default value 1                
Last cylinder, +cylinders or +size{K,M,G} (1-10011, default 10011): +100M      

Command (m for help): p

Disk /dev/sda: 82.3 GB, 82348277760 bytes
255 heads, 63 sectors/track, 10011 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x24c78168

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1          14      112423+  83  Linux

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (15-10011, default 15):
Using default value 15
Last cylinder, +cylinders or +size{K,M,G} (15-10011, default 10011): +2G

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): p
Partition number (1-4): 3
First cylinder (277-10011, default 277):
Using default value 277
Last cylinder, +cylinders or +size{K,M,G} (277-10011, default 10011):
Using default value 10011

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Now the encrypted partition creation. You can use different options, just check cryptsetup man page. The option below uses AES 256 bit encryption with SHA256 key hashing in cbc-essiv mode.


livecd ~ # cryptsetup --verbose --cipher "aes-cbc-essiv:sha256" --key-size 256 --verify-passphrase luksFormat /dev/sda3

WARNING!
========
This will overwrite data on /dev/sda3 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.
livecd ~ #

Ahh - you'd better remember this passphrase! Ya've been warned... ;]
Ok, now we need to to 'map' the encrypted partition so it will be visible to the system:


livecd ~ # cryptsetup luksOpen /dev/sda3 root
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.
livecd ~ #

Onto fortmatting! For main partition choose whatever filesystem you want. For the boot partition I'd go with soomething stable like ext2 or ext3 so it will be well supported by bootloader. Speed doesn't really matter here - your kernel is loaded only once during the booting ;)


livecd ~ # mkfs.ext3 /dev/sda1
mke2fs 1.41.3 (12-Oct-2008)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
28112 inodes, 112420 blocks
5621 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
14 block groups
8192 blocks per group, 8192 fragments per group
2008 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 31 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Being a curious person, I've chosen the ext4 filesystem for root partition ;] Pay attention to the /dev/mapper/root here instead of /dev/sda3!


livecd ~ # mkfs.ext4 /dev/mapper/root
mke2fs 1.41.3 (12-Oct-2008)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
4890624 inodes, 19548839 blocks
977441 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
597 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 33 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Now the newly created partition need to be mounted as per the handbook:


livecd ~ # mount /dev/mapper/root /mnt/gentoo/
livecd ~ # mkdir /mnt/gentoo/boot
livecd ~ # mount /dev/sda1 /mnt/gentoo/boot/

Adjust date if necessary:


livecd ~ # date
Fri Sep 11 13:37:52 UTC 2009

And from there it's more or less standard Gentoo installation...get and unpack the stage3 file and latest portage tree:


livecd ~ # cd /mnt/gentoo/
livecd gentoo # wget http://mirrors.kernel.org/gentoo/releases/amd64/autobuilds/current-iso/hardened/stage3-amd64-hardened+nomultilib-20090903.tar.bz2

livecd gentoo # tar xjpf stage3-*.tar.bz2

livecd gentoo # cd /mnt/gentoo
livecd gentoo # wget http://mirror.datapipe.net/gentoo/snapshots/portage-latest.tar.bz2
livecd gentoo # tar xjpf portage* -C usr/

Before any compilation will be done on the system, adjust make.conf to suit your needs (CC and USE flags, etc.). Again - handbook and multiple online resources are available for more details.


livecd ~ # nano /mnt/gentoo/etc/make.conf

adjust as needed...

Chrooting!


livecd ~ # mount -t proc none /mnt/gentoo/proc
livecd ~ # mount -o bind /dev /mnt/gentoo/dev
livecd ~ # cp -Lv /etc/resolv.conf /mnt/gentoo/etc/resolv.conf
`/etc/resolv.conf' -> `/mnt/gentoo/etc/resolv.conf'
livecd ~ # chroot /mnt/gentoo /bin/bash
livecd / # env-update && source /etc/profile
>>> Regenerating /etc/ld.so.cache...
livecd / # export PS1="(chroot) $PS1"
(chroot) livecd / #

Nice, now update the portage tree:


(chroot) livecd / # emerge --sync --quiet

Performing Global Updates: /usr/portage/profiles/updates/3Q-2009
(Could take a couple of minutes if you have a lot of binary packages.)
  .='update pass'  *='binary update'  #='/var/db update'  @='/var/db move'
  s='/var/db SLOT move'  %='binary move'  S='binary SLOT move'
  p='update /etc/portage/package.*'
...............................................
(chroot) livecd / #

Localisation bits below...speeds up compilation of glibc as it doesn't need to generate 400+ locales! ;]


(chroot) livecd / #  nano -w /etc/locale.gen
(chroot) livecd / # locale-gen
 * Generating 2 locales (this might take a while) with 1 jobs
 *  (1/2) Generating en_US.ISO-8859-1 ...                                                                                                                                     [ ok ]
 *  (2/2) Generating en_US.UTF-8 ...                                                                                                                                          [ ok ]
 * Generation complete

We'll have to use layman tool so let's emerge it now:


(chroot) livecd / # emerge -av layman

!!! Your current profile is deprecated and not supported anymore.
!!! Please upgrade to the following profile if possible:
        hardened/linux/amd64/10.0/no-multilib
To upgrade do the following steps:
# Use eselect profile to switch into 10.0 profile.

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    ] dev-python/pyxml-0.8.4-r2  USE="-doc -examples" 718 kB
[ebuild  N    ] app-portage/layman-1.2.3  USE="-git -subversion -test" 46 kB

Total: 2 packages (2 new), Size of downloads: 764 kB

Would you like to merge these packages? [Yes/No]

Oppsie! Ok, so Gentoo profile needs to be changed first. Let's see what we've got:


(chroot) livecd / # eselect profile list
Available profile symlink targets:
  [1]   default/linux/amd64/2008.0
  [2]   default/linux/amd64/2008.0/desktop
  [3]   default/linux/amd64/2008.0/developer
  [4]   default/linux/amd64/2008.0/no-multilib
  [5]   default/linux/amd64/2008.0/server
  [6]   default/linux/amd64/10.0
  [7]   default/linux/amd64/10.0/desktop
  [8]   default/linux/amd64/10.0/developer
  [9]   default/linux/amd64/10.0/no-multilib
  [10]  default/linux/amd64/10.0/server
  [11]  hardened/amd64
  [12]  hardened/amd64/multilib
  [13]  selinux/2007.0/amd64
  [14]  selinux/2007.0/amd64/hardened
  [15]  selinux/v2refpolicy/amd64
  [16]  selinux/v2refpolicy/amd64/desktop
  [17]  selinux/v2refpolicy/amd64/developer
  [18]  selinux/v2refpolicy/amd64/hardened
  [19]  selinux/v2refpolicy/amd64/server
  [20]  hardened/linux/amd64/10.0
  [21]  hardened/linux/amd64/10.0/no-multilib

That's a no brainer really... ;] Hardened no-multilib is the way to go! ;)


(chroot) livecd / # eselect profile set 21

Now emerge layman. Note that you're most likely currently using gcc-3.4.6 which does not support the -march=native option. I was to quick to adjust my CC flags so I had to change it to -march=K8 for my AMD64x2 CPU.
Adding hardened overlay:


(chroot) livecd / # layman -a hardened-development
* Failed to add overlay "hardened-development".
* Error was: Binary /usr/bin/git seems to be missing! Overlay type "git" not supported. Did you emerge dev-util/git?

I did forgot about git indeed! ;] Because I had plenty of USE flags enabled at this stage, I did not want to emerge too much dependencies at this point, hence I disabled some of the flags:


(chroot) livecd / # USE="-gnome -perl -gtk" emerge -av dev-util/git
These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    ] virtual/libintl-0  0 kB
[ebuild  N    ] dev-libs/libgpg-error-1.7  USE="nls" 395 kB
[ebuild  N    ] dev-libs/libtasn1-2.3  USE="-doc" 1,449 kB
[ebuild  N    ] dev-libs/libgcrypt-1.4.4  1,117 kB
[ebuild  N    ] net-libs/gnutls-2.6.6  USE="cxx nls zlib -bindist -doc -guile -lzo" 4,997 kB
[ebuild  N    ] net-misc/curl-7.19.6  USE="gnutls ipv6 ssl -ares -idn -kerberos -ldap -libssh2 -nss -test" 2,293 kB
[ebuild  N    ] dev-util/git-1.6.3.3  USE="bash-completion curl iconv threads xinetd -cgi -cvs -doc -emacs -gtk -mozsha1 -perl (-ppcsha1) -subversion -tk -webdav" 2,252 kB

Total: 7 packages (7 new), Size of downloads: 12,501 kB

Would you like to merge these packages? [Yes/No]

Oh yes, I would! When layman is ready we can proceed with adding the overlay:


(chroot) livecd / # layman -a hardened-development
* Running command "/usr/bin/git clone "git://git.overlays.gentoo.org/proj/hardened-development.git" "/usr/local/portage/layman/hardened-development""...
Initialized empty Git repository in /usr/local/portage/layman/hardened-development/.git/
remote: Counting objects: 2266, done.
remote: Compressing objects: 100% (1144/1144), done.
remote: Total 2266 (delta 1026), reused 2154 (delta 961)
Receiving objects: 100% (2266/2266), 2.13 MiB | 657 KiB/s, done.
Resolving deltas: 100% (1026/1026), done.
* Successfully added overlay "hardened-development".

Now change /etc/make.conf to include layman overlays. Adding this line should do:


source /usr/portage/local/layman/make.conf

Ina true Gentoo fashion there will be some keywording/unmasking needed. I went for using folders with files beneath but you could with one file for each task if you wish.


(chroot) livecd ~ # cd /etc/
(chroot) livecd etc # mkdir portage && cd portage
(chroot) livecd etc # mkdir package.keywords
(chroot) livecd etc # mkdir package.unmask
(chroot) livecd portage # echo "=sys-devel/gcc-4.4*" >>/etc/portage/package.keywords/toolchain
(chroot) livecd portage # echo "=sys-devel/gcc-4.4*" >>/etc/portage/package.unmask/toolchain
(chroot) livecd portage # echo "=sys-libs/glibc-2.10*" >>/etc/portage/package.keywords/toolchain
(chroot) livecd portage # echo "=sys-libs/glibc-2.10*" >>/etc/portage/package.unmask/toolchain

We need repos.conf file to use eclasses from the overlay. This file goes into /etc/portage and should contain the following:


# cat /etc/portage/repos.conf
[gentoo]
eclass-overrides = hardened-dev

Also, in order to compile glibc you need to disable the profile flag for it in package.use file:


echo "sys-libs/glibc -profile" >> /etc/portage/package.use

Let's see what will happen now...


(chroot) livecd layman # emerge -av gcc-config linux-headers glibc binutils gcc portage -1

These are the packages that would be merged, in order:
Calculating dependencies... done!
!!! All ebuilds that could satisfy ">=dev-libs/ppl-0.10" have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-libs/ppl-0.10.2 (masked by: ~amd64 keyword)
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
(dependency required by "sys-devel/gcc-4.4.1-r2" [ebuild])
(dependency required by "gcc" [argument])

Obvious! I've enabled the graphite extensions and forgot about their dependencies. More keywording then.


(chroot) livecd layman # echo ">=dev-libs/ppl-0.10" >> /etc/portage/package.keywords/toolchain
(chroot) livecd package.keywords # echo ">=dev-libs/cloog-ppl-0.15" >> /etc/portage/package.keywords/toolchain
(chroot) livecd package.keywords # emerge -av gcc-config linux-headers glibc binutils gcc portage -1

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] sys-apps/portage-2.1.6.13  USE="-build -doc -epydoc (-selinux)" LINGUAS="pl*" 733 kB [0]
[ebuild  N    ] dev-libs/gmp-4.2.4  USE="-nocxx" 1,671 kB [0]
[ebuild   R   ] sys-devel/gcc-config-1.4.1  0 kB [0]
[ebuild   R   ] sys-devel/binutils-2.18-r3  USE="nls* (-gold) -multislot -multitarget -test -vanilla" 14,629 kB [0]
[ebuild  N    ] dev-libs/ppl-0.10.2  USE="-doc (-pch) -prolog -test -watchdog" 9,590 kB [0]
[ebuild   R   ] sys-kernel/linux-headers-2.6.27-r2  3,509 kB [0]
[ebuild  N    ] dev-libs/mpfr-2.4.1_p1  883 kB [0]
[ebuild  N    ] dev-libs/cloog-ppl-0.15.7  750 kB [0]
[ebuild  NS   ] sys-devel/gcc-4.4.1-r2 [3.4.6-r2] USE="graphite gtk hardened mudflap nls nptl (-altivec) -bootstrap -build -doc (-fixed-point) -fortran -gcj -ip28 -ip32r10k -libffi (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++ -objc-gc -openmp -test -vanilla" 61,426 kB [1]
[ebuild     U ] sys-libs/glibc-2.10.1 [2.9_p20081201-r2] USE="gd* hardened nls* profile* -debug -glibc-omitfp (-multilib) (-selinux) -vanilla" 15,909 kB [0=>1]

Total: 10 packages (1 upgrade, 4 new, 1 in new slot, 4 reinstalls), Size of downloads: 109,097 kB
Portage tree and overlays:
 [0] /usr/portage
 [1] /usr/local/portage/layman/hardened-development

Would you like to merge these packages? [Yes/No]

Ok, nearly there, but I wanted newer linux-headers! ;] So:


(chroot) livecd package.keywords # echo sys-kernel/linux-headers >> /etc/portage/package.keywords/system
(chroot) livecd package.keywords # emerge -av gcc-config linux-headers glibc binutils gcc portage -1

These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild   R   ] sys-apps/portage-2.1.6.13  USE="-build -doc -epydoc (-selinux)" LINGUAS="pl*" 733 kB [0]
[ebuild  N    ] dev-libs/gmp-4.2.4  USE="-nocxx" 1,671 kB [0]
[ebuild   R   ] sys-devel/gcc-config-1.4.1  0 kB [0]
[ebuild   R   ] sys-devel/binutils-2.18-r3  USE="nls* (-gold) -multislot -multitarget -test -vanilla" 14,629 kB [0]
[ebuild  N    ] dev-libs/ppl-0.10.2  USE="-doc (-pch) -prolog -test -watchdog" 9,590 kB [0]
[ebuild     U ] sys-kernel/linux-headers-2.6.30-r1 [2.6.27-r2] 3,780 kB [0]
[ebuild  N    ] dev-libs/mpfr-2.4.1_p1  883 kB [0]
[ebuild  N    ] dev-libs/cloog-ppl-0.15.7  750 kB [0]
[ebuild  NS   ] sys-devel/gcc-4.4.1-r2 [3.4.6-r2] USE="graphite gtk hardened mudflap nls nptl (-altivec) -bootstrap -build -doc (-fixed-point) -fortran -gcj -ip28 -ip32r10k -libffi (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++ -objc-gc -openmp -test -vanilla" 61,426 kB [1]
[ebuild     U ] sys-libs/glibc-2.10.1 [2.9_p20081201-r2] USE="gd* hardened nls* profile* -debug -glibc-omitfp (-multilib) (-selinux) -vanilla" 15,909 kB [0=>1]

Total: 10 packages (2 upgrades, 4 new, 1 in new slot, 3 reinstalls), Size of downloads: 109,368 kB
Portage tree and overlays:
 [0] /usr/portage
 [1] /usr/local/portage/layman/hardened-development

Would you like to merge these packages? [Yes/No]

Oh yes! So the last final check before we go to ensure that everything is set to build our new shiny hardened toolchain:


(chroot) livecd package.keywords # eselect profile list
Available profile symlink targets:
  [1]   default/linux/amd64/2008.0
  [2]   default/linux/amd64/2008.0/desktop
  [3]   default/linux/amd64/2008.0/developer
  [4]   default/linux/amd64/2008.0/no-multilib
  [5]   default/linux/amd64/2008.0/server
  [6]   default/linux/amd64/10.0
  [7]   default/linux/amd64/10.0/desktop
  [8]   default/linux/amd64/10.0/developer
  [9]   default/linux/amd64/10.0/no-multilib
  [10]  default/linux/amd64/10.0/server
  [11]  hardened/amd64
  [12]  hardened/amd64/multilib
  [13]  selinux/2007.0/amd64
  [14]  selinux/2007.0/amd64/hardened
  [15]  selinux/v2refpolicy/amd64
  [16]  selinux/v2refpolicy/amd64/desktop
  [17]  selinux/v2refpolicy/amd64/developer
  [18]  selinux/v2refpolicy/amd64/hardened
  [19]  selinux/v2refpolicy/amd64/server
  [20]  hardened/linux/amd64/10.0
  [21]  hardened/linux/amd64/10.0/no-multilib *
(chroot) livecd package.keywords # gcc-config -l
 [1] x86_64-pc-linux-gnu-3.4.6 *
 [2] x86_64-pc-linux-gnu-3.4.6-hardenednopie
 [3] x86_64-pc-linux-gnu-3.4.6-hardenednopiessp
 [4] x86_64-pc-linux-gnu-3.4.6-hardenednossp
 [5] x86_64-pc-linux-gnu-3.4.6-vanilla

All set! So let's emerge the toolchain (last emerge command above).

Hmm...that didn't work, did it?


>>> Failed to emerge dev-libs/ppl-0.10.2, Log file:

Let's temporarily disable the graphite USE flag then:


(chroot) livecd package.keywords # USE="-graphite" emerge -av linux-headers glibc gcc -1
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild     U ] sys-kernel/linux-headers-2.6.30-r1 [2.6.27-r2] 0 kB [0]
[ebuild  N    ] dev-libs/mpfr-2.4.1_p1  0 kB [0]
[ebuild  NS   ] sys-devel/gcc-4.4.1-r2 [3.4.6-r2] USE="gtk hardened mudflap nls nptl (-altivec) -bootstrap -build -doc (-fixed-point) -fortran -gcj -graphite -ip28 -ip32r10k -libffi (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++ -objc-gc -openmp -test -vanilla" 0 kB [1]
[ebuild     U ] sys-libs/glibc-2.10.1 [2.9_p20081201-r2] USE="gd* hardened nls* profile* -debug -glibc-omitfp (-multilib) (-selinux) -vanilla" 0 kB [0=>1]

Total: 4 packages (2 upgrades, 1 new, 1 in new slot), Size of downloads: 0 kB
Portage tree and overlays:
 [0] /usr/portage
 [1] /usr/local/portage/layman/hardened-development

Would you like to merge these packages? [Yes/No]

Yuppie - this worked!:


(chroot) livecd package.keywords # gcc-config -l
 [1] x86_64-pc-linux-gnu-3.4.6 *
 [2] x86_64-pc-linux-gnu-3.4.6-hardenednopie
 [3] x86_64-pc-linux-gnu-3.4.6-hardenednopiessp
 [4] x86_64-pc-linux-gnu-3.4.6-hardenednossp
 [5] x86_64-pc-linux-gnu-3.4.6-vanilla
 [6] x86_64-pc-linux-gnu-4.4.1
 [7] x86_64-pc-linux-gnu-4.4.1-hardenednopie
 [8] x86_64-pc-linux-gnu-4.4.1-hardenednossp
 [9] x86_64-pc-linux-gnu-4.4.1-vanilla

So let's switch to our new compiler and try to rebuild it with graphite extensions enabled (you'll need to enable graphite use flag in /etc/make.conf):


(chroot) livecd package.keywords # gcc-config 6
 * Switching native-compiler to x86_64-pc-linux-gnu-4.4.1 ...
>>> Regenerating /etc/ld.so.cache...                                                                                                                                          [ ok ]

 * If you intend to use the gcc from the new profile in an already
 * running shell, please remember to do:

 *   # source /etc/profile

(chroot) livecd package.keywords # source /etc/profile
(chroot) livecd package.keywords # emerge -av gcc

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    ] dev-libs/ppl-0.10.2  USE="-doc (-pch) -prolog -test -watchdog" 0 kB [0]
[ebuild  N    ] dev-libs/cloog-ppl-0.15.7  0 kB [0]
[ebuild   R   ] sys-devel/gcc-4.4.1-r2  USE="graphite* gtk hardened mudflap nls nptl (-altivec) -bootstrap -build -doc (-fixed-point) -fortran -gcj -ip28 -ip32r10k -libffi (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++ -objc-gc -openmp -test -vanilla" 0 kB [1]

Total: 3 packages (2 new, 1 reinstall), Size of downloads: 0 kB
Portage tree and overlays:
 [0] /usr/portage
 [1] /usr/local/portage/layman/hardened-development

Would you like to merge these packages? [Yes/No] y

Ppl failed again ;( I've tried rebuilding binutils and glibc with the new compiler first but that didn't work too. As it is usually the case - solution was simple and even given on the screen!


livecd package.keywords # fix_libtool_files.sh 3.4.6
 * Scanning libtool files for hardcoded gcc library paths...
 *   [1/7] Scanning /lib ...
 *   [2/7] Scanning /usr/lib ...
 *   [3/7] Scanning /lib64 ...
 *   [4/7] Scanning /usr/lib64 ...
 *     FIXING: /usr/lib64/gcc/x86_64-pc-linux-gnu/3.4.6/libsupc++.la ...[]
 *     FIXING: /usr/lib64/gcc/x86_64-pc-linux-gnu/3.4.6/libstdc++.la ...[]
 *   [5/7] Scanning /usr/local/lib ...
 *   [6/7] Scanning /usr/local/lib64 ...
 *   [7/7] Scanning /usr/x86_64-pc-linux-gnu/lib ...

Rite, we're on track...emerge gcc with graphite enabled and it should work this time. To take the full advantage of the graphite framework you'll need to change your CCFLAGS (see bottom of this page). I also wanted to enable ccache to speed up all the recompilations ;]


livecd # emerge -av ccache
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild  N    ] dev-util/ccache-2.4-r7  85 kB
Total: 1 package (1 new), Size of downloads: 85 kB
Would you like to merge these packages? [Yes/No]

This would require the following changes in make.confg (choose whatever size for your cache tou want):


livecd package.keywords # nano /etc/make.conf

FEATURES="ccache"
CCACHE_SIZE="5G"

At last! New gcc has arrived:


livecd package.keywords # gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.4.1-r2/work/gcc-4.4.1/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.1 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.1 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.1/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.1/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-espf --disable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.4.1/python --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 4.4.1-r2 p1.0, espf-0.3.3'
Thread model: posix
gcc version 4.4.1 (Gentoo Hardened 4.4.1-r2 p1.0, espf-0.3.3)

Ok, nice and sweet. Now we need to recompile world. Again due to some circular dependencies I disabled the gnome flag which I've already enabled in make.conf ;) :


time USE="-gnome" emerge -ev world --keep-going
failed to compile:
* The following 34 packages have failed to build or install:
 *                                                           
 *      ('ebuild', '/', 'sys-fs/cryptsetup-1.0.6-r2', 'merge')
 *      ('ebuild', '/', 'gnome-base/libgnomeprint-2.18.5', 'merge')
 *      ('ebuild', '/', 'dev-python/libgnomecanvas-python-2.22.3', 'merge')
 *      ('ebuild', '/', 'net-print/libgnomecups-0.2.3', 'merge')           
 *      ('ebuild', '/', 'app-misc/hal-info-20090414', 'merge')             
 *      ('ebuild', '/', 'x11-base/xorg-server-1.5.3-r6', 'merge')          
 *      ('ebuild', '/', 'sys-apps/hal-0.5.11-r9', 'merge')                 
 *      ('ebuild', '/', 'dev-python/pygtk-2.14.1-r1', 'merge')             
 *      ('ebuild', '/', 'x11-libs/gtksourceview-1.8.5-r1', 'merge')        
 *      ('ebuild', '/', 'dev-python/gnome-python-base-2.22.3', 'merge')    
 *      ('ebuild', '/', 'gnome-base/libgnomecanvas-2.20.1.1', 'merge')     
 *      ('ebuild', '/', 'dev-python/gnome-python-desktop-base-2.24.1', 'merge')
 *      ('ebuild', '/', 'net-print/cups-1.3.10-r2', 'merge')
 *      ('ebuild', '/', 'x11-drivers/xf86-video-openchrome-0.2.903', 'merge')
 *      ('ebuild', '/', 'net-fs/samba-3.0.33', 'merge')
 *      ('ebuild', '/', 'gnome-base/gail-1000', 'merge')
 *      ('ebuild', '/', 'x11-drivers/xf86-input-mouse-1.4.0', 'merge')
 *      ('ebuild', '/', 'dev-python/libgnomeprint-python-2.24.1', 'merge')
 *      ('ebuild', '/', 'app-text/ghostscript-gpl-8.64-r3', 'merge')
 *      ('ebuild', '/', 'gnome-base/libglade-2.6.4', 'merge')
 *      ('ebuild', '/', 'gnome-base/libgnomeprintui-2.18.3', 'merge')
 *      ('ebuild', '/', 'x11-drivers/xf86-input-keyboard-1.3.2', 'merge')
 *      ('ebuild', '/', 'dev-python/gtksourceview-python-2.24.1', 'merge')
 *      ('ebuild', '/', 'virtual/ghostscript-0', 'merge')
 *      ('ebuild', '/', 'dev-util/git-1.6.3.3', 'merge')
 *      ('ebuild', '/', 'x11-libs/gtk+-2.14.7-r2', 'merge')
 *      ('ebuild', '/', 'dev-python/pygobject-2.18.0', 'merge')
 *      ('ebuild', '/', 'x11-libs/libXaw-1.0.5', 'merge')
 *      ('ebuild', '/', 'x11-terms/xterm-242', 'merge')
 *      ('ebuild', '/', 'x11-apps/xinit-1.0.8-r4', 'merge')
 *      ('ebuild', '/', 'sys-apps/groff-1.20.1-r1', 'merge')
 *      ('ebuild', '/', 'x11-apps/xmessage-1.0.2-r1', 'merge')
 *      ('ebuild', '/', 'x11-apps/xsm-1.0.1-r1', 'merge')
 *      ('ebuild', '/', 'x11-apps/xclock-1.0.3-r1', 'merge')
 *

Nothing critical ;D Well...cryptsetup maybe. I don't remember why it failed but as it was already installed, it worked fine and I think that it needed to be keyworded with ~amd64 and then it compiled fine. Further system adjustments:


livecd # sed -i 's/once/once,--hash-style=gnu/' /etc/make.conf
livecd # etc-update
livecd # emerge syslog-ng ntp lilo vixie-cron sysfsutils dhcpcd eix gentoolkit portage-utils genlop
livecd # cp /usr/share/zoneinfo/GMT /etc/localtime

Kernel time - I've used 2.6.31 which since then has been upgraded to 2.6.31.1 and is running perfectly fine. I do strongly recommend to use the 2.6.31.1! Also - the patch utility is also needed!


livecd src # wget http://grsecurity.net/test/grsecurity-2.1.14-2.6.31-200909121839.patch
livecd src #emerge patch
livecd src # tar jxf linux-2.6.31.tar.bz2
livecd src # patch -p0 < grsecurity-2.1.14-2.6.31-200909121839.patch

The easiest way to go about kernel configuration is to use the one from livecd - once it's working we can start stripping it down of unnecessary stuff.
Outside chroot:


zcat /proc/config.gz > /mnt/gentoo/usr/src/linux-2.6.31/.config

Back to chroot (forgot about the genkernel! ;) ):


livecd src # ln -s linux-2.6.31 linux
livecd src # emerge genkernel
livecd src # emerge -av cryptsetup
livecd src # rc-update add dmcrypt boot

Also, /etc/genkernel.conf needs LUKS="yes" set (default is no). You could also tweak other options.


CLEAN="no"
MRPROPER="no"
LUKS="yes"

Compile! Remember to add the --luks option so a LUKS-aware initrd will be created.


livecd linux-2.6.31 # genkernel --luks all
* Gentoo Linux Genkernel; Version 3.4.10.904
* Running with options: --luks all

* Linux Kernel 2.6.31 for x86_64...
*         >> Running oldconfig...
* config: --no-clean is enabled; leaving the .config alone.
*         >> Compiling 2.6.31-grsec bzImage...
*         >> Compiling 2.6.31-grsec modules...
* Copying config for successful build to /etc/kernels/kernel-config-x86_64-2.6.31-grsec
* busybox: >> Applying patches...
* busybox: >> Configuring...
* busybox: >> Compiling...
* busybox: >> Copying to cache...
* initramfs: >> Initializing...
*         >> Appending base_layout cpio data...
*         >> Appending auxilary cpio data...
*         >> Appending busybox cpio data...
*         >> Appending luks cpio data...
* Including LUKS support
*         >> Appending modules cpio data...
*
* Kernel compiled successfully!
*
* Required Kernel Parameters:
*     real_root=/dev/$ROOT
*
*     Where $ROOT is the device node for your root partition as the
*     one specified in /etc/fstab
*
* If you require Genkernel's hardware detection features; you MUST
* tell your bootloader to use the provided INITRAMFS file. Otherwise;
* substitute the root argument for the real_root argument if you are
* not planning to use the initramfs...

* WARNING... WARNING... WARNING...
* Additional kernel cmdline arguments that *may* be required to boot properly...

* Do NOT report kernel bugs as genkernel bugs unless your bug
* is about the default genkernel configuration...
*
* Make sure you have the latest genkernel before reporting bugs.

Nearly there. /etc/fstab needs to be adjusted so our new system will boot properly. If you've used the same partitioning scheme, here's how it needs to look like:


/dev/sda1               /boot           ext3            noauto,noatime  1 2
/dev/mapper/root        /               ext4            noatime         0 1
/dev/crypt-swap         none            swap            sw              0 0
/dev/cdrom              /mnt/cdrom      auto            noauto,ro       0 0
#/dev/fd0               /mnt/floppy     auto            noauto          0 0

To get encrypted swap partition working you need to add this to /etc/conf.d/dmcrypt :


swap=crypt-swap
source='/dev/sda2'

Almost ready for reboot! Edit hostname and clock settings (/etc/hostname and /etc/conf.d/clock) and proceed to boot loader config. Due to neverending issues with grub on amd64 we're (for now at least) doomed with lilo ;]. In order to get it to work with LUKS the append line should look like this:


  
  append="init=/linuxrc ramdisk=8192 crypt_root=/dev/sda3 real_root=/dev/mapper/root"

And I still leave root=/dev/sda3 option in as well. Before you reboot also make sure that you've changed root password. Reboot!
Let's test it then, shall we? Emerge and run paxtest:


host ~ # echo "app-admin/paxtest ~amd64" >> /etc/portage/package.keywords/system
host ~ # emerge paxtest
host ~ # paxtest blackhat
PaXtest - Copyright(c) 2003,2004 by Peter Busser 
Released under the GNU Public Licence version 2 or later              
Writing output to paxtest.log
It may take a while for the tests to complete
Test results:                                
PaXtest - Copyright(c) 2003,2004 by Peter Busser 
Released under the GNU Public Licence version 2 or later              
Mode: blackhat
Linux host 2.6.31-grsec #3 SMP Tue Sep 15 10:51:44 GMT 2009 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ AuthenticAMD GNU/Linux

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable stack (mprotect)              : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments                   : Killed
Anonymous mapping randomisation test     : 33 bits (guessed)
Heap randomisation test (ET_EXEC)        : 40 bits (guessed)
Heap randomisation test (ET_DYN)         : 40 bits (guessed)
Main executable randomisation (ET_EXEC)  : 32 bits (guessed)
Main executable randomisation (ET_DYN)   : 32 bits (guessed)
Shared library randomisation test        : 33 bits (guessed)
Stack randomisation test (SEGMEXEC)      : No randomisation
Stack randomisation test (PAGEEXEC)      : 40 bits (guessed)
Return to function (strcpy)              : *** buffer overflow detected ***: rettofunc1 - terminated
rettofunc1: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (memcpy)              : *** buffer overflow detected ***: rettofunc2 - terminated
rettofunc2: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (strcpy, RANDEXEC)    : *** buffer overflow detected ***: rettofunc1x - terminated
rettofunc1x: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (memcpy, RANDEXEC)    : *** buffer overflow detected ***: rettofunc2x - terminated
rettofunc2x: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed

Sweet! You could update baselayout and switch to openrc:


host ~ # echo "sys-apps/baselayout ~amd64" >> /etc/portage/package.keywords/system
host ~ # echo "sys-apps/openrc ~amd64" >> /etc/portage/package.keywords/system
host ~ # echo "sys-apps/sysvinit ~amd64" >> /etc/portage/package.keywords/system
host ~ # emerge -av baselayout

KDE time! The Gentoo KDE Guide will be useful here, especially to get the keywording/unmasking files. To keep it nice and clean:


host ~ # cd /etc/portage/package.keywords/
host package.keywords # touch kde-4.3
host package.keywords # nano kde-4.3

Update the files as per guide. Also some packages have to be compiled with specific flags set, this is what worked for me at the time being:


host portage # echo "dev-python/PyQt4 sql webkit" >> /etc/portage/package.use
host portage # echo "sys-auth/pambase consolekit" >> /etc/portage/package.use
host portage # echo "x11-libs/qt-gui mng" >> /etc/portage/package.use
host portage # echo "sys-libs/ncurses unicode" >> /etc/portage/package.use

Now is the biggie ;] Better run it over night or even better over weekend...The --keep-going command will prevent you from checking every 10 minutes if the compilation hasn't stopped due to some errors ;) :


emerge --keep-going -av kde-meta

...few hours later I got this:


 *
 * The following 12 packages have failed to build or install:
 *
 *      ('ebuild', '/', 'kde-base/nepomuk-4.3.1', 'merge')
 *      ('ebuild', '/', 'kde-base/kdebase-meta-4.3.1', 'merge')
 *      ('ebuild', '/', 'kde-base/kde-meta-4.3.1', 'merge')
 *      ('ebuild', '/', 'kde-base/gwenview-4.3.1', 'merge')
 *      ('ebuild', '/', 'kde-base/kdegraphics-meta-4.3.1', 'merge')
 *      ('ebuild', '/', 'kde-base/kdenetwork-meta-4.3.1', 'merge')
 *      ('ebuild', '/', 'kde-base/mplayerthumbs-4.3.1', 'merge')
 *      ('ebuild', '/', 'kde-base/kdemultimedia-meta-4.3.1', 'merge')
 *      ('ebuild', '/', 'kde-base/kmail-4.3.1', 'merge')
 *      ('ebuild', '/', 'kde-base/dolphin-4.3.1', 'merge')
 *      ('ebuild', '/', 'kde-base/kdepim-meta-4.3.1', 'merge')
 *      ('ebuild', '/', 'kde-base/kget-4.3.1', 'merge')

Well, nepomuk did not like the grsec kernel, so I had to reboot into vanilla and re-emerge the kde-meta package. It (nepomuk) compiled fine but still segfaults on grsec kernels - I don't really use it so I'm not bothered but that probably is a bug that would require some patching. Nevertheless - finish of the installation as per Gentoo guide, remove unnecessary files and update config files:


host / # rm portage-latest.tar.bz2
host / # rm stage3-amd64-hardened+nomultilib-20090903.tar.bz2
host / # etc-update

...configure X (Gentoo guides will be helpful again!) and start your new shiny KDE environment! ;] Remember to add dbus to startup or KDM will not work; you'll probably need hald as well:


host ~ # rc-update add dbus default
* service dbus added to runlevel default
host ~ # /etc/init.d/dbus start
dbus            |* Starting D-BUS system messagebus...                                                  
[ ok ]          |
host ~ # /etc/init.d/hald start
hald            |* Starting Hardware Abstraction Layer daemon...                                        
[ ok ]          |
host ~ # rc-update add hald default
* service hald added to runlevel default

Enjoy!

Compiling glibc-2.10 with GCC-4.4 on gentoo hardened

2009-10-03T12:39:00.003+01:00

It does not compile with the profile flag set, at least at the time of writing. In order to get it compiled unset the flag:


# USE="-profile" emerge -av glibc

These are the packages that would be merged, in order:

Calculating dependencies ... done!
[ebuild   R   ] sys-libs/glibc-2.10.1  USE="gd hardened nls -debug -glibc-omitfp (-multilib) -profile (-selinux) -vanilla" 16,492 kB

2.6.31-grsec

2009-09-22T18:34:00.003+01:00

Latest testing grsecurity patch is available here. Although there were some issues with linking for users with older binutils (2.18), they should be now resolved. I've been using this kernel for quite a few days now without any issues at all...

So just follow this with the latest patch...compile and enjoy! ;]

KDE 4.3.1 on Gentoo...hardened!

2009-09-11T22:33:00.003+01:00

Yes! It works fine with gcc-4.4.1 and glibc-2.10.1...just follow the guide. It compiled without any issues apart from the nepomuk ebuild requiring non-grsec kernel to compile - and yes, it does crash when running with grsecurity but hey - nepomuk is not critical a part of the KDE environment, is it? ;)

Of course, getting X to work with decent drivers is always a mission (at least with nvidia based cards), so I'm currently using the opensource 'nv' drivers, as neither 'nouveau' nor binary drivers work for me...KMS works fine - hopefully the 2.6.31 brings less patching...

Nevertheless - if you're not after fancy 3D stuff (maybe owners of non-nvidia cards are more lucky?) - KDE 4.3 is out there an it looks much better than previous 4.x release - less vista-ish too - that's for sure! ;]

Emerge! ;)

Gentoo hardened overlay update - once again :)

2009-08-21T20:41:00.002+01:00

The xake-toolchain overlay has been moved to overlays.gentoo.org and renamed to hardened-overlay and is available now directly using layman! So if you were using layman to track xake-toolchain it's time to update...


# layman -d xake-toolchain
* Successfully deleted overlay "xake-toolchain".

And add:


# layman -a hardened-development
* Running command "/usr/bin/git clone "git://git.overlays.gentoo.org/proj/hardened-development.git" "/usr/local/portage/layman/hardened-development""...
Initialized empty Git repository in /usr/local/portage/layman/hardened-development/.git/
remote: Counting objects: 2180, done.
remote: Compressing objects: 100% (1090/1090), done.
remote: Total 2180 (delta 992), reused 2089 (delta 935)
Receiving objects: 100% (2180/2180), 2.11 MiB | 618 KiB/s, done.
Resolving deltas: 100% (992/992), done.
* Successfully added overlay "hardened-development".

Test case: ;)


# layman -l
* hardened-development      [Git       ] (git://git.overlays.gentoo.org/proj/hardened-development.git)

Happy compiling! ;]

Gentoo hardened overlay update

2009-08-14T15:40:00.003+01:00

Gcc-4.4.1 and gcc-4.3.4 are now in master branch of the xake-toolchain overlay. :) Therefore if you've been using the testing branch you can now switch to master:


~ # cd "/usr/local/portage/layman/xake-toolchain"
x86 xake-toolchain # git checkout master
Switched to branch 'master'
Your branch is behind 'origin/master' by 6 commits, and can be fast-forwarded.
xake-toolchain # layman -S
* Running command "cd "/usr/local/portage/layman/xake-toolchain" && /usr/bin/git pull"...
Updating 7ac8e25..659a4cc
Fast forward
 README                                             |   11 +-
 eclass/flag-o-matic.eclass                         |  137 +++-
 eclass/hardened-funcs.eclass                       |  812 -----------------
 eclass/toolchain-funcs.eclass                      |  463 ----------
 eclass/toolchain.eclass                            |  911 ++++++++++++++++++--
 sys-boot/grub/Manifest                             |    2 +-
 sys-boot/grub/grub-0.97-r10.ebuild                 |   17 +-
 sys-devel/gcc/Manifest                             |   25 +-
 sys-devel/gcc/gcc-4.3.3-r1.ebuild                  |   85 --
 .../{gcc-4.3.3-r3.ebuild => gcc-4.3.4-r1.ebuild}   |   25 +-
 .../{gcc-4.3.3-r2.ebuild => gcc-4.4.1-r2.ebuild}   |   33 +-
 sys-libs/glibc/Manifest                            |    3 +-
 .../2.10/glibc-2.10-hardened-ssp-compat.patch      |  168 ++++
 sys-libs/glibc/glibc-2.10.1.ebuild                 |    3 +
 sys-libs/libstdc++-v3/ChangeLog                    |  235 -----
 sys-libs/libstdc++-v3/Manifest                     |    6 -
 .../libstdc++-v3/files/compile_with_no-SSP.patch   |   11 -
 sys-libs/libstdc++-v3/libstdc++-v3-3.3.6-r1.ebuild |  179 ----
 sys-libs/libstdc++-v3/metadata.xml                 |    5 -
 19 files changed, 1205 insertions(+), 1926 deletions(-)
 delete mode 100644 eclass/hardened-funcs.eclass
 delete mode 100644 eclass/toolchain-funcs.eclass
 delete mode 100644 sys-devel/gcc/gcc-4.3.3-r1.ebuild
 rename sys-devel/gcc/{gcc-4.3.3-r3.ebuild => gcc-4.3.4-r1.ebuild} (75%)
 rename sys-devel/gcc/{gcc-4.3.3-r2.ebuild => gcc-4.4.1-r2.ebuild} (72%)
 create mode 100644 sys-libs/glibc/files/2.10/glibc-2.10-hardened-ssp-compat.patch
 delete mode 100644 sys-libs/libstdc++-v3/ChangeLog
 delete mode 100644 sys-libs/libstdc++-v3/Manifest
 delete mode 100644 sys-libs/libstdc++-v3/files/compile_with_no-SSP.patch
 delete mode 100644 sys-libs/libstdc++-v3/libstdc++-v3-3.3.6-r1.ebuild
 delete mode 100644 sys-libs/libstdc++-v3/metadata.xml
*
* Success:
* ------
*
* Successfully synchronized overlay "xake-toolchain".
xake-toolchain #

Thanks guys! :)))

gcc-4.4.1-r2 is out!

2009-08-11T13:05:00.002+01:00

The hardened overlay has just been updated - with ebuilds for gcc-4.3.4 and gcc-4.4.1-r2. The new ebuild for 4.4.1 includes new espf-0.3.2 patches.


# gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.4.1-r2/work/gcc-4.4.1/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.1 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.1/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.1 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.1/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.1/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.1/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-espf --disable-libgomp --enable-cld --disable-libgcj --with-arch=i686 --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 4.4.1-r2 p1.0, espf-0.3.2'
Thread model: posix
gcc version 4.4.1 (Gentoo Hardened 4.4.1-r2 p1.0, espf-0.3.2)

Thanks to everyone involved in making this happen! :)

New grsecurity test patch for 2.6.30.4

2009-08-11T11:40:00.003+01:00

Available here. It fixes a signal handling error which seemed to prevent firefox from running on x86 machine.

Get it now while it's fresh! ;]

64-bit 2.6.30.4-grsec

2009-08-07T09:31:00.002+01:00

It seems that bug that stopped latest grsecurity patch to work on 64-bit kernels has been resolved. The latest grsecurity-2.1.14-2.6.30.4-200908051916.patch is working fine for over a day of a standard desktop use - stable enough for me! ;)


# paxtest blackhat
PaXtest - Copyright(c) 2003,2004 by Peter Busser 
Released under the GNU Public Licence version 2 or later              

Mode: blackhat
Linux 2.6.30.4-grsec #4 SMP Thu Aug 6 09:57:40 BST 2009 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable stack (mprotect)              : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments                   : Killed
Anonymous mapping randomisation test     : 33 bits (guessed)
Heap randomisation test (ET_EXEC)        : 40 bits (guessed)
Heap randomisation test (ET_DYN)         : 40 bits (guessed)
Main executable randomisation (ET_EXEC)  : 32 bits (guessed)
Main executable randomisation (ET_DYN)   : 32 bits (guessed)
Shared library randomisation test        : 33 bits (guessed)
Stack randomisation test (SEGMEXEC)      : No randomisation
Stack randomisation test (PAGEEXEC)      : 40 bits (guessed)
Return to function (strcpy)              : *** buffer overflow detected ***: rettofunc1 - terminated
rettofunc1: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (memcpy)              : *** buffer overflow detected ***: rettofunc2 - terminated
rettofunc2: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (strcpy, RANDEXEC)    : *** buffer overflow detected ***: rettofunc1x - terminated
rettofunc1x: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (memcpy, RANDEXEC)    : *** buffer overflow detected ***: rettofunc2x - terminated
rettofunc2x: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed

Kernel 2.6.30.4 with Grsecurity patch

2009-08-05T16:34:00.007+01:00

The latest stable patch for the 2.6 branch on the grsecurity.net website is for 2.6.27 kernel and the latest available gentoo hardened-sources ebuild that includes grsecurity is for 2.6.29 but the latest kernel is 2.6.30.4 so... ;)

NOTE: This info applies to a testing version of the grsecurity patch and is very likely to harm your system and eat your hamster (possibly). I wouldn't use it on a production system at all...Also it does not seem to work properly on amd64 architecture at the moment. It didn't work for me on x86_64 but it seems fine on x86. Ya've been warned!

NOTE2: I mainly followed this information which includes much more details about the installation process and Grsecurity and PAX itself. Definitely a recommended reading!

Ok, here we go...first, the kernel sources:


# cd /usr/src
# wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.4.tar.bz2
# http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.4.tar.bz2.sign

As recommended on the aforementioned guide, it's always good idea to verify your sources. It doesn't really matter that much if you have downloaded the archive from the main kernel website (unless you don't trust your ISP ;)). Of course someone could plant a backdoor in the source tree before it got packaged, but...anyway! Latest information about kernel signature (and key) can be found here. Verification time! But first the actual key is needed:


# gpg --keyserver wwwkeys.pgp.net --recv-keys 0x517D0F0E
gpg: requesting key 517D0F0E from hkp server wwwkeys.pgp.net
gpg: key 517D0F0E: public key "Linux Kernel Archives Verification Key " imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1

...and verification follows...:


# gpg --verify linux-2.6.30.4.tar.bz2.sign
gpg: Signature made Fri Jul 31 00:13:44 2009 BST using DSA key ID 517D0F0E
gpg: Good signature from "Linux Kernel Archives Verification Key "
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: C75D C40A 11D7 AF88 9981  ED5B C86B A06A 517D 0F0E

Looks good...unpack the sources:


# tar jxf linux-2.6.30.4.tar.bz2

And time for patch - including key to verify it of course! ;]


# wget http://grsecurity.net/spender-gpg-key.asc
# wget http://grsecurity.net/test/grsecurity-2.1.14-2.6.30.4-200908041752.patch
# wget http://grsecurity.net/test/grsecurity-2.1.14-2.6.30.4-200908041752.patch.sig

Again - import the key and verify the patch:


# gpg --import spender-gpg-key.asc
gpg: key 4245D46A: public key "Bradley Spengler (spender) " imported
gpg: Total number processed: 1
gpg:               imported: 1

# gpg --verify grsecurity-2.1.14-2.6.30.4-200908041752.patch.sig
gpg: Signature made Tue Aug  4 22:56:17 2009 BST using DSA key ID 4245D46A
gpg: Good signature from "Bradley Spengler (spender) "
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 9F74 393D 7E7F FF3C 6500  E778 9879 B649 4245 D46A

If you already have symlink to linux you need to update it to point to new kernel tree. Or create new one if it doesn't exist:


# ln -s linux-2.6.30.4 linux

Patch the sources and get ready for kernel configuration! ;)


# patch -p0 < ./grsecurity-2.1.14-2.6.30.4-200908041752.patch
# cd linux

You can use your current kernel configuration by copying relevant file that is corresponding with your kernel version from /boot/config-X.X.X to
/usr/src/linux/.config. Alternatively:


# zcat /proc/config.gz > /usr/src/linux/.config

Now the beast itself. Run your favourite kernel configuration variant (make oldconfig ;)) and enable grsecurity along with PAX. Use one of the predefined security levels or just choose custom and read this.


# make menuconfig

I use genkernel wrapper - it creates initramfs automatically that will work with my LUKS encrypted partition:


# genkernel --luks all

Update bootloader to use the new kernel and rewrite MBR -reboot, choose your new kernel and pray! If it have worked:


# uname -srv
Linux 2.6.30.4-grsec #1 SMP Wed Aug 5 15:29:37 BST 2009

And just to be on a safe side:


# paxtest blackhat                               
PaXtest - Copyright(c) 2003,2004 by Peter Busser 
Released under the GNU Public Licence version 2 or later              

Writing output to paxtest.log
It may take a while for the tests to complete
Test results:                                
PaXtest - Copyright(c) 2003,2004 by Peter Busser 
Released under the GNU Public Licence version 2 or later              

Mode: blackhat
Linux 2.6.30.4-grsec #1 SMP Wed Aug 5 15:29:37 BST 2009 i686 GNU/Linux

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable stack (mprotect)              : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments                   : Killed
Anonymous mapping randomisation test     : 17 bits (guessed)
Heap randomisation test (ET_EXEC)        : 23 bits (guessed)
Heap randomisation test (ET_DYN)         : 23 bits (guessed)
Main executable randomisation (ET_EXEC)  : 15 bits (guessed)
Main executable randomisation (ET_DYN)   : 15 bits (guessed)
Shared library randomisation test        : 17 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 23 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 24 bits (guessed)
Return to function (strcpy)              : *** buffer overflow detected ***: rettofunc1 - terminated
rettofunc1: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (memcpy)              : *** buffer overflow detected ***: rettofunc2 - terminated
rettofunc2: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (strcpy, RANDEXEC)    : *** buffer overflow detected ***: rettofunc1x - terminated
rettofunc1x: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (memcpy, RANDEXEC)    : *** buffer overflow detected ***: rettofunc2x - terminated
rettofunc2x: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed

Yuppie! ;]

Using layman to track the hardened overlay

2009-08-04T17:18:00.007+01:00

Ok, so manually updating an overlay is boring and cumbersome ;) Well, I mean, instead of doing:


cd /usr/local/toolchain-overlay && git update

You could simply run:


layman -S

Efficiency!

So if you haven't used layman before here's quick step-by-step. First - quite obviously - we need to emerge layman itself:


# emerge -av layman

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    ] dev-python/pyxml-0.8.4-r2  USE="-doc -examples" 718 kB
[ebuild  N    ] app-portage/layman-1.2.3  USE="-git -subversion -test" 46 kB

Total: 2 packages (2 new), Size of downloads: 764 kB

Would you like to merge these packages? [Yes/No]

...after few minutes portage kindly informs us what to do next:


 * Select an overlay and add it using
 * layman -a overlay-name
 * If this is the very first overlay you add with layman,
 * you need to append the following statement to your
 * /etc/make.conf file:
 *
 * source /usr/local/portage/layman/make.conf
 *
 * If you modify the 'storage' parameter in the layman
 * configuration file (/etc/layman/layman.cfg) you will
 * need to adapt the path given above to the new storage
 * directory.
 * Please add the 'source' statement to make.conf only AFTER
 * you added your first overlay. Otherwise portage will fail.

Nice and easy. Here we go:


# layman -o http://github.com/Xake/toolchain-overlay.git/xake-toolchain.xml -fa xake-toolchain
* Running command "/usr/bin/git clone "git://github.com/Xake/toolchain-overlay.git" "/usr/local/portage/layman/xake-toolchain""...
Initialized empty Git repository in /usr/local/portage/layman/xake-toolchain/.git/
remote: Counting objects: 2083, done.
remote: Compressing objects: 100% (1306/1306), done.
remote: Total 2083 (delta 953), reused 1492 (delta 633)
Receiving objects: 100% (2083/2083), 2.08 MiB | 284 KiB/s, done.
Resolving deltas: 100% (953/953), done.
* Successfully added overlay "xake-toolchain".

Confirm that it is there and that it's up to date:


# layman -l
* xake-toolchain            [Git       ] (git://github.com/Xake/toolchain-overlay.git 
# layman -S
                                                                                                                                                            * Running command "cd "/usr/local/portage/layman/xake-toolchain" && /usr/bin/git pull"...
Already up-to-date.
*
* Success:
* ------
*
* Successfully synchronized overlay "xake-toolchain".

Time to change the repository to use testing branch which is required for gcc-4.4. If you want to stay with gcc-4.3 skip this step and proceed to editing /etc/make.conf. For gcc-4.4 run this:


# cd /usr/local/portage/layman/xake-toolchain
# git branch testing origin/testing
Branch testing set up to track remote branch testing from origin.
# git checkout testing && git pull && cd $OLDPWD
Switched to branch 'testing'
Already up-to-date.

Now portage has to know that it needs to look somewhere else for ebuilds. This requires change in /etc/make.conf. We need to comment out previous location (/usr/local/toolchain-overlay) and add the new one. Open /etc/make.conf in your favourite editor:


#PORTDIR_OVERLAY="/usr/local/toolchain-overlay"
source /usr/local/portage/layman/make.conf

That should be it. To confirm that portage works as it should try emerging gcc and glibc. For gcc-4.4 you should see:


# emerge -av glibc gcc

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] sys-devel/gcc-4.4.1-r1  USE="graphite gtk hardened mudflap nls nptl (-altivec) -bootstrap -build -doc (-fixed-point) -fortran -gcj -ip28 -ip32r10k -libffi (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++ -objc-gc -openmp -test -vanilla" 0 kB [1]
[ebuild   R   ] sys-libs/glibc-2.10.1  USE="gd hardened nls profile -debug -glibc-omitfp (-multilib) (-selinux) -vanilla" 0 kB [1]

Total: 2 packages (2 reinstalls), Size of downloads: 0 kB
Portage tree and overlays:
 [0] /usr/portage
 [1] /usr/local/portage/layman/xake-toolchain

Would you like to merge these packages? [Yes/No] n

Quitting.

All set! You can safely delete the /usr/local/toolchain-overlay folder. Now whenever you want to update the overlay, simply run:


# layman -S

John the ripper on mpi steroids or how to crack YOUR passwords faster

2009-08-01T08:26:00.009+01:00

Ok, so everybody knows john. John is the ripper. He rips passwords. But he's not always fast enough. However, thanks to this patch he can now take an advantage of your multicore system! Here's the quick & dirty howto.

All required goodies are there in Gentoo portage tree so in a true Gentooer fashion:


# emerge -av openmpi johntheripper

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    ] sys-cluster/openmpi-1.3.2  USE="cxx ipv6 threads -debug -fortran -heterogeneous -mpi-threads -pbs -romio" 0 kB
[ebuild  N    ] app-crypt/johntheripper-1.7.3.1  USE="mmx mpi sse2 (-altivec) -custom-cflags -minimal" 0 kB

Total: 2 packages (2 new), Size of downloads: 0 kB

Would you like to merge these packages? [Yes/No]

Make sure that the mpi flag is enabled. After it's done, quick test to confirm it's working:


# mpirun -np 2 uname -rsv
Linux 2.6.29-hardened #13 SMP Fri Jul 24 15:26:08 BST 2009
Linux 2.6.29-hardened #13 SMP Fri Jul 24 15:26:08 BST 2009

Where 2 is number of processors (or cores) available. Ok, ready to go - first benchmarking without multicore:


# john --test
mca: base: component_find: unable to open /usr/lib/openmpi/mca_osc_pt2pt: file not found (ignored)
mca: base: component_find: unable to open /usr/lib/openmpi/mca_osc_rdma: file not found (ignored)
Benchmarking: Traditional DES [128/128 BS SSE2]... DONE
Many salts:     1529K c/s real, 1698K c/s virtual
Only one salt:  1253K c/s real, 1392K c/s virtual
Benchmarking: BSDI DES (x725) [128/128 BS SSE2]... DONE
Many salts:     49920 c/s real, 56089 c/s virtual
Only one salt:  48512 c/s real, 53902 c/s virtual
Benchmarking: FreeBSD MD5 [32/32]... DONE
Raw:    4933 c/s real, 5542 c/s virtual
Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE
Raw:    305 c/s real, 342 c/s virtual

There is not much info about the error reported but it does not seem to be critical. Now run with through the mpi:


# mpirun -np 2 john --test                             
mca: base: component_find: unable to open /usr/lib/openmpi/mca_osc_pt2pt: file not found (ignored)
mca: base: component_find: unable to open /usr/lib/openmpi/mca_osc_rdma: file not found (ignored) 
mca: base: component_find: unable to open /usr/lib/openmpi/mca_osc_pt2pt: file not found (ignored)
mca: base: component_find: unable to open /usr/lib/openmpi/mca_osc_rdma: file not found (ignored) 
Benchmarking: Traditional DES [128/128 BS SSE2]... DONE
Many salts:     3178K c/s real, 6754K c/s virtual
Only one salt:  2622K c/s real, 5651K c/s virtual
Benchmarking: BSDI DES (x725) [128/128 BS SSE2]... DONE
Many salts:     102846 c/s real, 222092 c/s virtual
Only one salt:  99703 c/s real, 215022 c/s virtual
Benchmarking: FreeBSD MD5 [32/32]... DONE
Raw:    9869 c/s real, 21833 c/s virtual
Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE
Raw:    616 c/s real, 1353 c/s virtual

Whooaa! That's a bit faster...And here's a more comprehensive guide too. Off course using rainbow tables will be always faster, but: good (big) rainbow tables are needed and if the password is salted than you're out of luck. Anyway - happy cracking! ;]

BTW: Oh and do use loong and complex passwords...also - if you compare full benchmark output, just look how fast is cracking md5 as compared to sha-1 or blowfish...and although john does not support cracking sha512 passwords as of yet, your system probably supports this algorithm for password hashing so...but that's a totally different story!

gcc-4.4.1 with graphite framework

2009-07-30T10:02:00.008+01:00

Ok, so the recent release of the beloved (?) gcc compiler provides not only usual bug fixes and enhancements but also some exciting features such as the graphite framework which aims to provide better optimization of a compiled code (loops to be precise) thus resulting in faster binaries. There's some interesting theory behind it too! And here is a forum discussion just in case something goes wrong ;)

Is it faster? I dunno...feels like it ;) Is it bleeding edge? Oh yeah! ;] So make some backup, etc., ya've been warned!

First, enable the graphite USE flag in /etc/make.conf. Next, keyword two required libraries - for a x86_64 box this is needed:


echo 'dev-libs/ppl ~amd64' >> /etc/portage/package.keywords
echo 'dev-libs/cloog-ppl ~amd64' >> /etc/portage/package.keywords

Ready to emerge!


# emerge -av gcc

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    ] dev-libs/ppl-0.10.2  USE="-doc (-pch) -prolog -test -watchdog" 9,590 kB [0]
[ebuild  N    ] dev-libs/cloog-ppl-0.15.3  788 kB [0]
[ebuild   R   ] sys-devel/gcc-4.4.1-r1  USE="graphite* gtk hardened mudflap nls nptl (-altivec) -bootstrap -build -doc (-fixed-point) -fortran -gcj -ip28 -ip32r10k -libffi (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++ -objc-gc -openmp -test -vanilla" 0 kB [1]

Total: 3 packages (2 new, 1 reinstall), Size of downloads: 10,378 kB
Portage tree and overlays:
 [0] /usr/portage
 [1] /usr/local/toolchain-overlay

Would you like to merge these packages? [Yes/No]

few minutes later... ;)


# gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.4.1-r1/work/gcc-4.4.1/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.1 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.1 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.1/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.1/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-espf --disable-libgomp --enable-cld --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 4.4.1-r1 p1.0, espf-0.3.1'
Thread model: posix
gcc version 4.4.1 (Gentoo Hardened 4.4.1-r1 p1.0, espf-0.3.1)

Ok, now it's time to adjust CCFLAGS. They should look similar to this (the last three options are important here):


CFLAGS="-O2 -march=native -pipe -floop-interchange -floop-strip-mine -floop-block"
CXXFLAGS="${CFLAGS}"

Rite...all set! Now the classics:


emerge binutils gcc glibc linux-headers && emerge -eav world

...is it faster then? ;]

How to (too)quickly remove 32-bit packages from your 64-bit system

2009-07-29T11:15:00.006+01:00

I have recently migrated my system from multilib to non-multilib. After rebuilding kernel, world and making sure that my /lib folder pointed to /lib64, there were still some files left under /lib32. That was against the principles! ;)


# qfile /lib32
app-emulation/emul-linux-x86-baselibs (/lib32)

Ok, so here' the guilty one...let's see why it got pulled in:


# equery depends app-emulation/emul-linux-x86-baselibs
[ Searching for packages depending on app-emulation/emul-linux-x86-baselibs... ]
app-emulation/emul-linux-x86-gtklibs-20071214 (>=app-emulation/emul-linux-x86-baselibs-20071114)
app-emulation/emul-linux-x86-medialibs-20071114 (>=app-emulation/emul-linux-x86-baselibs-20071114)
app-emulation/emul-linux-x86-sdl-20080316 (>=app-emulation/emul-linux-x86-baselibs-20071114)
app-emulation/emul-linux-x86-soundlibs-20080418 (>=app-emulation/emul-linux-x86-baselibs-20071114)
app-emulation/emul-linux-x86-xlibs-20080810 (>=app-emulation/emul-linux-x86-baselibs-20071114)
net-im/skype-2.0.0.72 (amd64? >=app-emulation/emul-linux-x86-baselibs-2.1.1)
www-plugins/adobe-flash-10.0.22.87 (amd64 & multilib & 32bit? app-emulation/emul-linux-x86-baselibs)
x11-misc/googleearth-5.0.11733.9347 (amd64? app-emulation/emul-linux-x86-baselibs)

Oh well, say bye bye to skype, flash and googleearth...who'd need this anyway? ;)


# equery depends app-emulation/emul-linux-x86-baselibs | awk {'print $1'} | xargs emerge -Cpv

Final step: to ensure that system is not spoiled (ever! ;)) with 32-bit nonsense some masking is needed:


echo "app-emulation/emul-linux-x86-baselibs" >> /etc/portage/package.mask

Job done!

Update: bear in mind that there some dependencies might still exist thus run this:


emerge -uavND world

If you see the 'emul-*' packages being pulled in - check your use flag and run multiple 'equery depends [package]' to identify the offenders and remove them!

gcc-4.4.1 is out!

2009-07-28T10:09:00.011+01:00

Hot&fresh! ;] Unfortunately I haven't saved the output while updating my systems but this is very straightforward. This guide will also be helpful as well as this post that might describe different approach to updating your whole system ;].

If you are already using the testing branch of the overlay your default compiler should be gcc-4.4.0. Simply update the git repository by running 'git pull' in your overlay folder (/usr/local/toolchain-overlay). If you're not using the overlay yet - read here ;) Anyway...running 'emerge -av gcc' should show gcc-4.4.1-r1 being pulled in from overlay - go for it! ;]

Once your gcc is updated, at the end of installation process, you will probably get something like this:

* gcc-config: Active gcc profile is invalid!

You'll have to tell your system which compiler it needs to use:


# gcc-config -l
 [1] x86_64-pc-linux-gnu-4.3.3
 [2] x86_64-pc-linux-gnu-4.3.3-nofortify
 [3] x86_64-pc-linux-gnu-4.3.3-nopie
 [4] x86_64-pc-linux-gnu-4.3.3-nossp_all
 [5] x86_64-pc-linux-gnu-4.3.3-vanilla
 [6] x86_64-pc-linux-gnu-4.4.1 
 [7] x86_64-pc-linux-gnu-4.4.1-hardenednopie
 [8] x86_64-pc-linux-gnu-4.4.1-hardenednossp
 [9] x86_64-pc-linux-gnu-4.4.1-vanilla

Therefore:


# gcc-config 6
# env-update && source /etc/profile

So Ladies & Gentlemen- here it is!


# gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.4.1-r1/work/gcc-4.4.1/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.1 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.1 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.1/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.1/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-espf --disable-libgomp --enable-cld --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 4.4.1-r1 p1.0, espf-0.3.1'
Thread model: posix
gcc version 4.4.1 (Gentoo Hardened 4.4.1-r1 p1.0, espf-0.3.1)

You can run 'fix_libtool_files.sh' just in case: ;)


# fix_libtool_files.sh 4.4.0
* Scanning libtool files for hardcoded gcc library paths...
 *   [1/7] Scanning /lib ...
 *   [2/7] Scanning /usr/lib ...
 *   [3/7] Scanning /lib64 ...
 *   [4/7] Scanning /usr/lib64 ...
 *   [5/7] Scanning /usr/local/lib ...
 *   [6/7] Scanning /usr/local/lib64 ...
 *   [7/7] Scanning /usr/x86_64-pc-linux-gnu/lib ...

And then - recompile rest of your toolchain - apparently it should be enough to simply compile binutils with glibc and then re-emerge the world:


# emerge -av binutils glibc && emerge -eav world

...but I like to keep my cpu busy:


# emerge -av binutils gcc glibc

...and it's an easy one from there:


# emerge -eav system && emerge -eav world

Regardless of approach chosen - it's a tea time...! ;) Enjoy!

64-bit hardened Gentoo with gcc-4.4 and glibc-2.10

2009-07-27T12:24:00.010+01:00

UPDATED 5.10 - Update installation HowTo (+LUKS) is available here.

UPDATED 17.08 - It is no longer needed to use the testing branch from overlay, so skip this part. Also the repo name in repos.conf should then read 'secure' rather than 'secure-testing'.

One of my previous posts shown how to create a x86 hardened Gentoo system. Of course there's also a 64-bit version available! There're only few small differences during the installation process needed - so here's what you need to do to get a new shiny 64-bit hardened gentoo. Follow this with the following remarks:
- acquire a 64-bit machine - a 64-bit VM will do!;]
- download a weekly 64-bit gentoo minimal installation CD from here.
- use this 64-bit stage
- before emerging gcc, glibc and binutils change profile:

(chroot) livecd / # eselect profile list
Available profile symlink targets:
  [1]   default/linux/amd64/2008.0
  [2]   default/linux/amd64/2008.0/desktop
  [3]   default/linux/amd64/2008.0/developer
  [4]   default/linux/amd64/2008.0/no-multilib
  [5]   default/linux/amd64/2008.0/server
  [6]   hardened/amd64
  [7]   hardened/amd64/multilib
  [8]   selinux/2007.0/amd64
  [9]   selinux/2007.0/amd64/hardened
  [10]  hardened/linux/amd64
(chroot) livecd / # eselect profile show
Current make.profile symlink:
  /usr/portage/profiles/hardened/linux/amd64/2008.0

Now run:
eselect profile set 6

Note: even if you want multilib, it seems that profile no. 7 is recommended over 10 as per this information.

Continue with the installation guide. During the kernel configuration step, choose your 64-bit cpu in "Processor type and feature" menu. For non-multilib profile (oh yeah! ;)) in "Executable file formats/Emulations" disable the "IA32 Emulation". Continue...

As a final step, run paxtest - sit back admire/show off/grab a beer:

~ # paxtest blackhat
PaXtest - Copyright(c) 2003,2004 by Peter Busser 
Released under the GNU Public Licence version 2 or later

Writing output to paxtest.log
It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003,2004 by Peter Busser 
Released under the GNU Public Licence version 2 or later

Mode: blackhat
Linux 2.6.29-hardened #7 SMP Thu Jul 23 12:18:52 UTC 2009 x86_64 QEMU Virtual CPU version 0.10.50 GenuineIntel GNU/Linux

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable stack (mprotect)              : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments                   : Killed
Anonymous mapping randomisation test     : 34 bits (guessed)
Heap randomisation test (ET_EXEC)        : 40 bits (guessed)
Heap randomisation test (ET_DYN)         : 40 bits (guessed)
Main executable randomisation (ET_EXEC)  : 32 bits (guessed)
Main executable randomisation (ET_DYN)   : 32 bits (guessed)
Shared library randomisation test        : 33 bits (guessed)
Stack randomisation test (SEGMEXEC)      : No randomisation
Stack randomisation test (PAGEEXEC)      : 40 bits (guessed)
Return to function (strcpy)              : *** buffer overflow detected ***: rettofunc1 - terminated
rettofunc1: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (memcpy)              : *** buffer overflow detected ***: rettofunc2 - terminated
rettofunc2: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (strcpy, RANDEXEC)    : *** buffer overflow detected ***: rettofunc1x - terminated
rettofunc1x: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (memcpy, RANDEXEC)    : *** buffer overflow detected ***: rettofunc2x - terminated
rettofunc2x: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed

Result? Pretty much same as for x86, but: greater randomisation due to 64-bit architecture and a fully 64-bit OS of course! ;] (if non-multilib). Note that PAX on x86_64 uses PAGEEXEC and not SEGMEXEC hence no randomisation there.

NOTE: if using a KVM virtual machine rather than a dedicated system, in order to take advantage of NX-bit in guest, your host OS needs kernel that is >= 2.6.30. I've tested with gentoo-sources-2.6.30-r4 which worked fine. Unfortunately, at the time of this writing there was no hardened kernel available greater than 2.6.29... ;( Not sure, but this might also apply to other VMs like VirtualBox and VMWare too...

Lilo and root partition encrypted with LUKS on Gentoo

2009-07-24T20:50:00.003+01:00

When using full 64-bit system (non-multilib), one has to rely on lilo instead of grub as his bootloader. This seemed like a straightforward migration - which it was, after of course I've discovered that lilo needs one additional parameter to find correct root partition. :)

Therefore if grub was happy with something like this (where ENCRYPTED_ROOT was the encrypted root partition, say hda1):


kernel /kernel-image-2.0.22 ro crypt_root=/dev/ENCRYPTED_ROOT

Lilo line translated into this:


append="ramdisk=8192 crypt_root=/dev/ENCRYPTED_ROOT real_root=/dev/mapper/root"

That is of course assuming use of the awesome genkernel script.

Happy days! ;]

Hardened Gentoo running glibc-2.10 and gcc-4.4 with PAX in 15 minutes.

2009-07-23T13:21:00.013+01:00

UPDATED 5.10 - More up-to-date HowTo is available here Enjoy! :)

UPDATED 22.09 - Further changes - the overlay can be now tracked directly via layman and is called 'hardened-development'. I hope to post an updated HowTo (with LUKS encryption) soon...

UPDATED 17.08 - It is no longer needed to use the testing branch from overlay, so skip this part. Also the repo name in repos.conf should then read 'secure' rather than 'secure-testing'.

...well, not exactly so - but still faster and easier that one could expect! ;) Depending on used hardware, in few hours you could have a state-of-art, up-to-date, secure system...well, let's say - maybe bit more secure than others... ;] But why bother?

Note for impatient: open this, then search this page for 'enough of BS' and start from there... ;)

Health&Safety note: this info might contain some bugs (no influenza though!). You might ruin your system. Your box might explode (especially if adequate cooling is not provided during compilation ;)). Your wife/girlfriend might get mad ("Honey, I just need to compile one more package, I promise!"). Your friends will hate you ("So your system is secure - how is your new printer/camera/other_new_fancy_device working?" - well, it isn't, you fool!). Ya've been warned!

So what's the motivation? Being security paranoid doesn't leave you much choice anyway, does it...? ;) Well, run the paxtest tool and the checksec.sh script (elfutils package needed!) on your favourite distro, compare and decide by yourself if it's worth the effort :)

~ # ./checksec.sh --proc-all
        COMMAND    PID RELRO             STACK CANARY           NX            PIE                     ASLR
           init      1 Full RELRO        Canary found           NX enabled    PIE enabled             ASLR enabled
         dhcpcd   1437 Full RELRO        Canary found           NX enabled    PIE enabled             ASLR enabled
      syslog-ng   1557 Full RELRO        Canary found           NX enabled    PIE enabled             ASLR enabled
           sshd   1577 Full RELRO        Canary found           NX enabled    PIE enabled             ASLR enabled
           cron   1592 Full RELRO        Canary found           NX enabled    PIE enabled             ASLR enabled
         agetty   1605 Full RELRO        Canary found           NX enabled    PIE enabled             ASLR enabled
         agetty   1608 Full RELRO        Canary found           NX enabled    PIE enabled             ASLR enabled
         agetty   1609 Full RELRO        Canary found           NX enabled    PIE enabled             ASLR enabled
         agetty   1610 Full RELRO        Canary found           NX enabled    PIE enabled             ASLR enabled
         agetty   1611 Full RELRO        Canary found           NX enabled    PIE enabled             ASLR enabled
         agetty   1612 Full RELRO        Canary found           NX enabled    PIE enabled             ASLR enabled
           sshd   1641 Full RELRO        Canary found           NX enabled    PIE enabled             ASLR enabled
           bash   1646 Full RELRO        Canary found           NX enabled    PIE enabled             ASLR enabled
          udevd    519 Full RELRO        Canary found           NX enabled    PIE enabled             ASLR enabled

~ # paxtest blackhat
PaXtest - Copyright(c) 2003,2004 by Peter Busser 
Released under the GNU Public Licence version 2 or later

Mode: blackhat
Linux 2.6.29-hardened #8 SMP Fri Jul 17 13:35:18 GMT 2009 i686 QEMU Virtual CPU version 0.10.50 GenuineIntel GNU/Linux

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable stack (mprotect)              : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments                   : Killed
Anonymous mapping randomisation test     : 17 bits (guessed)
Heap randomisation test (ET_EXEC)        : 23 bits (guessed)
Heap randomisation test (ET_DYN)         : 23 bits (guessed)
Main executable randomisation (ET_EXEC)  : 15 bits (guessed)
Main executable randomisation (ET_DYN)   : 15 bits (guessed)
Shared library randomisation test        : 17 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 23 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 23 bits (guessed)
Return to function (strcpy)              : *** buffer overflow detected ***: rettofunc1 - terminated
rettofunc1: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (memcpy)              : *** buffer overflow detected ***: rettofunc2 - terminated
rettofunc2: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (strcpy, RANDEXEC)    : *** buffer overflow detected ***: rettofunc1x - terminated
rettofunc1x: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Return to function (memcpy, RANDEXEC)    : *** buffer overflow detected ***: rettofunc2x - terminated
rettofunc2x: buffer overflow attack in function  - terminated
Report to http://bugs.gentoo.org/
Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed

Ready? If you're not faint-hearted read below! Otherwise take the blue pill ;]

Requirements:
- bit of time and dedication. RTFM skills will be required too... ;]
- new VM or spare machine - nothing fancy but the faster it is the sooner it's done! Base install took approximately 3G of space but if you want to install anything else than just a base system, you'd need more than that. This HowTo assumes a x86 box.
- no prior knowledge about kernel configuration required yet you will have a PAX kernel! ;]

Two main links are here:
http://forums.gentoo.org/viewtopic-t-705939.html
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml

First link is the main one you want to follow and describes everything you need to know and do to complete the installation procedure. I have used stages from here and the official gentoo minimal installation CD that can be found here

To make life easier, I ssh to the new box from another box where I have the guid open - copy&paste made easy. To do so run on new system:

/etc/init.d/sshd start
passwd
ifconfig

Then ssh into the system using IP shown in the ifconfig command:

sshd root@your_ip_here

If for whatever reason installation process is interrupted (power outage) or needs to be stopped (shouting girlfriend ;)), and you've already created and partitioned disk, after neutralizing the threat you can continue the installation like this:
1. boot liveCD
2. ssh into the box as mentioned earlier
3. run:

livecd ~ # mount /dev/your_root_partition_here /mnt/gentoo/
livecd ~ # swapon /dev/your_swap_partition_here
mount -t proc none /mnt/gentoo/proc
mount -o bind /dev /mnt/gentoo/dev
chroot /mnt/gentoo /bin/bash
env-update && source /etc/profile
export PS1="(chroot) $PS1"

Right, enough of BS - start here:

Follow the guide until it says about keywording packages - "First we add certain packages that are known to fail from the portage tree." That's not required anymore :) Instead of this:

echo "=sys-devel/gcc-4.3*" >>/etc/portage/package.keywords
echo "=sys-devel/gcc-4.3*" >>/etc/portage/package.unmask
echo "=sys-libs/glibc-2.8*">>/etc/portage/package.keywords

run:

echo "=sys-devel/gcc-4.4*" >>/etc/portage/package.keywords
echo "=sys-devel/gcc-4.4*" >>/etc/portage/package.unmask
echo "=sys-libs/glibc-2.10*">>/etc/portage/package.keywords
echo "=sys-libs/glibc-2.10*">>/etc/portage/package.unmask

..and then go for the testing branch. When running the initial emerge of key packages:

emerge gcc-config linux-headers glibc binutils gcc portage -1

I run into a weird portage error. The issue was resolved by emerging portage manually:

emerge portage

and then emerging rest of the packages:

emerge gcc-config linux-headers glibc binutils gcc -1

Continue...Don't unmask this: sys-apps/openrc-9999 - doesn't seem to be required anymore. At the kernel configuration stage - unmask latest hardened-sources to get the latest kernel source with all security goodies (2.6.29 at the time of this writing)

echo "sys-kernel/hardened-sources ~x86">>/etc/portage/package.keywords
emerge -av hardened-sources genkernel

New kernel tree should be ready for ya:

(chroot) livecd src # ls -la
total 12
drwxr-xr-x  3 root root 4096 Jul 22 13:14 .
drwxr-xr-x 13 root root 4096 Jul 21 14:12 ..
-rw-r--r--  1 root root    0 Apr  1 00:28 .keep
lrwxrwxrwx  1 root root   21 Jul 22 13:14 linux -> linux-2.6.29-hardened
drwxr-xr-x 23 root root 4096 Jul 22 13:14 linux-2.6.29-hardened

Now config time - the lazy (not-so-secure) way is shown below. The result will be a default Gentoo kernel with PAX and Grsecurity enabled. To use current configuration of currently running kernel (that is: the one that LiveCD is using):

zcat /proc/config.gz > /usr/src/linux/.config

Alternatively copy it to default genkernel location like this:

zcat /proc/config.gz > /usr/share/genkernel/arch/x86_64/kernel-
config

and then:

genkernel --menuconfig all

Under Security options enable Grsecurity and PAX. Feel free to tune settings but defaults should be just fine. Use 'gentoo-workstation' or 'gentoo-server' pre-set options. Exit and save configuration and let the kernel compile :)

Follow the handbook until it says...reboot! (..and pray). If anything goes wrong and kernel does not boot - use 'rescue' procedure as described at the beginning of this how-to.

If you see login prompt - voilà! You've done it! emerge paxtest, run and relax - or show off in front of your friends ;). You might need to keyword it:

echo "app-admin/paxtest ~x86" >> /etc/portage/package.keywords
emerge paxtest

And finally:

~ # gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.4.0-r4/work/gcc-4.4.0/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.0 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --disable-nls --without-ppl --without-cloog --disable-ppl-version-check --disable-cloog-version-check --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --enable-espf --disable-libssp --disable-libgomp --enable-cld --disable-libgcj --with-arch=i686 --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 4.4.0-r4 p1.1, espf-0.2.9'
Thread model: posix
gcc version 4.4.0 (Gentoo Hardened 4.4.0-r4 p1.1, espf-0.2.9)

Rite...so now you have a 'secure' system...or as secure as it gets one should say :) What about classics like weak passwords/default accounts left, default configuration and services, design or configuration errors, 0days, kernel exploits (or DoSes ;))..but hey - at least it's a good start! ;]

Next good thing to do would be to tune the kernel and remove all the unnecessary functionality, especially when it comes to device drivers - they just tend to be a bit less secure than expected... ;)

Enjoy! If it worked for you - great! If it didn't - well, I'm sorry...try again ;)

Hmm...of course your system might now require few more packages but who have ever said that terminal is ugly? Depending on your mood do 'emerge gnome' or 'emerge kde-meta' and go get some beer...
Few days later....

My Gentoo boxes

2009-07-21T10:26:00.007+01:00

I'm using two hardened Gentoo systems on a daily basis - for business and pleasure ;] One of them is a x86_64 non-multilib desktop and the other one is a x86 laptop - both are build using the gcc-4.x branch. The official hardened Gentoo is currently still using gcc-3.4 unfortunately; however, thanks to awesome work by zorry, xake and many others there's an overlay available that supports glibc-2.10 and gcc-4.3 and gcc-4.4! ;]

Information about the overlay can be found here. It has all the information required to enjoy a fully hardened, modern Linux distro - patience and fast box is still recommended! ;)

There is a nice installation howto and forum discussion too.

So why not treat yourself with a new shiny Gentoo? I can hear your compiler screaming... ;]

dev-libs/nss - executable stack markings

2009-07-21T09:52:00.008+01:00

Compilation of version 3.12.3 of the nss library (dev-libs/nss) on my amd64 box resulted with executable and writable stack markings - which from security point of view is better if avoided ;) It also did not make some other programs happy that depend on this library when running under PAX system.

The initial hint was this:

 * QA Notice: The following files contain writable and executable sections
*  Files with such sections will not work properly (or at all!) on some
*  architectures/operating systems.  A bug should be filed at
*  http://bugs.gentoo.org/ to make sure the issue is fixed.
*  For more information, see http://hardened.gentoo.org/gnu-stack.xml
*  Please include the following list of files in your report:
*  Note: Bugs should be filed for the respective maintainers
*  of the package in question and not hardened@g.o.
* RWX --- --- usr/lib64/nss/libfreebl3.so.12

Which was confirmed below - just in case ;)

user@host ~ $ scanelf -qe /usr/lib64/nss/libfreebl3.so
RWX --- ---  /usr/lib64/nss/libfreebl3.so

So when I attempted to run firefox I got a segmentation fault :( Good old strace investigation shown:

user@host ~ $ strace firefox
...
open("/usr/lib64/nss/libfreebl3.so", O_RDONLY) = 46
read(46, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20:\0\0\0\0\0\0@"..., 832) = 832
fstat(46, {st_mode=S_IFREG|0755, st_size=431928, ...}) = 0
mmap(NULL, 2544672, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 46, 0) = 0x6f9ca2b61000
mprotect(0x6f9ca2bc9000, 2093056, PROT_NONE) = 0
mmap(0x6f9ca2dc8000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 46, 0x67000) = 0x6f9ca2dc8000
mmap(0x6f9ca2dcb000, 13344, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x6f9ca2dcb000
mprotect(0x6f9cba22b000, 3460, PROT_READ|PROT_WRITE) = -1 EACCES (Permission denied)

Oppsie!
There was another hint to this riddle though: http://hardened.gentoo.org/gnu-stack.xml. It's a very good read, btw! First, the ebuild had to be compiled and ready for further investigation:

ebuild /usr/portage/dev-libs/nss/nss-3.12.3.ebuild clean unpack compile
cd /var/tmp/portage/dev-libs/nss-3.12.3/work/nss-3.12.3/

Now which file has to be patched?

host nss-3.12.3 # scanelf -qeR .
RWX --- ---  ./work/nss-3.12.3/mozilla/security/dist/Linux2.6_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/lib/libfreebl3.so
RWX --- ---  ./work/nss-3.12.3/mozilla/security/dist/Linux2.6_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/lib/libfreebl3.so.12
!WX --- ---  ./work/nss-3.12.3/mozilla/security/nss/lib/freebl/Linux2.6_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/Linux_SINGLE_SHLIB/intel-aes.o
RWX --- ---  ./work/nss-3.12.3/mozilla/security/nss/lib/freebl/Linux2.6_x86_64_x86_64-pc-linux-gnu-gcc_glibc_PTH_64_OPT.OBJ/Linux_SINGLE_SHLIB/libfreebl3.so.12

Aha! The intel-aes.o does not have correct markings set. Time for a patch...The actual source file is here:

/var/tmp/portage/dev-libs/nss-3.12.3/work/nss-3.12.3/mozilla/security/nss/lib/freebl/intel-aes.s

as suggested in the guide, adding this at the very bottom of the file:

#if defined(__linux__) && defined(__ELF__)
.section .note.GNU-stack,"",%progbits
#endif

And recompilation time...so the correct order would be this:
ebuild /usr/portage/dev-libs/nss/nss-3.12.3.ebuild clean unpack
Now patch the intel-aes.s file and then:

ebuild /usr/portage/dev-libs/nss/nss-3.12.3.ebuild compile install qmerge

No QA error reported! Job done! The actual bug was reported here: http://bugs.gentoo.org/show_bug.cgi?id=266343
All in all - that was an easy fix! :) This is now fixed in nss-3.12.3-r1