Thursday, 30 July 2009

gcc-4.4.1 with graphite framework

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? ;]

Wednesday, 29 July 2009

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

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!

Tuesday, 28 July 2009

gcc-4.4.1 is out!

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!

Monday, 27 July 2009

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

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

Friday, 24 July 2009

Lilo and root partition encrypted with LUKS on Gentoo

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! ;]

Thursday, 23 July 2009

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

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

Tuesday, 21 July 2009

My Gentoo boxes

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

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