Firefox 10.0.1 - MPROTECT strikes again!

It's been a while and Firefox has moved from version 5 to version 10.0.1, now that's a pace! ;) But the important bits are...enforcing MPROTECT has never been easier...well, almost. ;)

Thanks to this attachment in this bug, the latest version of Firefox compiles fine on hardened profiles (or simply on grsec kernels).

In order to enable MPROTECT restrictions, edit the ebuild and at the top add pax_kernel flag to IUSE so it reads like this:

IUSE="bindist +crashreporter +ipc +minimal pgo selinux system-sqlite +webm pax_kernel"

also, add the following snippet in src_configure() before the # Finalize and report settings line:

if use pax_kernel; then
   mozconfig_annotate '' --disable-methodjit
   mozconfig_annotate '' --disable-tracejit
fi

...and get rid of the following lines in src_install():

# Pax mark xpcshell for hardened support, only used for startupcache creation.
pax-mark m "${S}/${obj_dir}"/dist/bin/xpcshell

and this:

# Required in order to use plugins and even run firefox on hardened.
pax-mark m "${ED}"${MOZILLA_FIVE_HOME}/{firefox,firefox-bin,plugin-container}

NOTE:You wan't be able to run Java or Flash as they require RWX mappings which will be not allowed when MPROTECT is enforced. If you need to use them, you can use different browser for it, for instance Chromium.

Now digest your local ebuild:

# ebuild /usr/local/portage/www-client/firefox/firefox-10.0.1.ebuild digest
>>> Creating Manifest for /usr/local/portage/www-client/firefox

...and you're ready to emerge! ;] Once done, start Firefox. If you're starting it from the command line, you'll see the following (expected) error:

LLVM ERROR: Allocation failed when allocating new memory in the JIT
Can't allocate RWX Memory: Operation not permitted

which is exactly what we wanted :) ...and to verify that it works as expected:

$ for pid in $(ps -ef | grep [f]irefox | awk '{print $2}'); do cat /proc/$pid/status | grep PaX; done
PaX: PeMRs

Note the capital 'M' - you're mprotected! ;]

Firefox 5 with MPROTECT on...of course!

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

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

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 :)

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

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

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