Testing stuff with QEMU - Part 1: SELinux support in Debian unstable [Update]

Update: "Testing stuff with QEMU"-articles published so far:

Here's a quick HOWTO to get you started with the QEMU emulator, the Debian installer (etch beta 3), and SELinux. If you execute the following steps you'll be left with an SELinux-enabled Debian unstable QEMU image, but not with a complete working and perfectly configured SELinux system. A more detailed article about SELinux will probably follow...

Basic Debian unstable install in QEMU:

  1. Install QEMU:
    apt-get install qemu
  2. Download the latest Debian etch installer ISO image (etch beta 3, currently):
  3. Create a QEMU image which will hold the Debian installation:
    qemu-img create -f qcow /path/to/debian.img 5000M
  4. Boot directly from the ISO image and install Debian into the QEMU image (I won't go into the details of the installation itself; Wolfang Lonien has nice HOWTOs for that: part 1, part 2, video):
    qemu -hda /path/to/debian.img -boot d -cdrom debian-testing-i386-binary-1.iso
  5. After the installation is done, configure the system, tweak /etc/apt/sources.list if needed, and then dist-upgrade to the latest stuff:
    apt-get update && apt-get dist-upgrade
  6. That's about it for the basic Debian install, you can now shutdown the OS and QEMU (type "halt" in the emulated Debian, wait for the shutdown to complete, press CTRL+ALT+2 to switch to the QEMU console, and type "quit").

Creating a QEMU overlay image:

QEMU has a nice feature called overlay images which allows you to "clone" an image, where the new (overlay) image will only store the "diffs" to the original one, thus saving lots of space. This also allows you to remove the overlay image at any time and restart from the original image (which is nice for testing stuff which may break).

  1. Create an overlay image based on the previously installed Debian image:
    qemu-img create -b /path/to/debian.img -f qcow /path/to/debian_selinux_overlay.img
  2. Now boot into the new overlay image:
    qemu -hda /path/to/debian_selinux_overlay.img

Basic SELinux setup:

SELinux / sestatus screenshot

  1. SELinux wants to label all the files on your system (all inodes actually), so your filesystem(s) need the so-called extended attributes (xattr) and "security labels" (both are kernel options) which most modern file systems now support. For ext3 (for example) you need these config options:
    Luckily the Debian kernels are xattr-enabled by default so we don't have to do anything at all here.

  2. Install the basic SELinux packages and the source package of the SELinux reference policy:
    apt-get install checkpolicy policycoreutils selinux-policy-refpolicy-src
  3. I noticed a bug in the current Debian packages (the setfiles utility is in the wrong place, see #384850), but there's a simple workaround:
    ln -s /sbin/setfiles /usr/sbin/setfiles
  4. Now we can (re-)label the file system:
    cd /etc/selinux/refpolicy/src/policy
    make relabel
    This will build the reference policy from source and relabel your file system (this will take a while).
    There might be some warnings (and maybe you'll notice further bugs), but they seem not to be critical.
  5. We can now (almost) enable SELinux, but before we can reboot we need to work around another bug (#384852), otherwise SELinux will not be enabled when we reboot:
    ln -s /etc/selinux/refpolicy/src /etc/selinux/targeted
  6. Now reboot the emulated Debian system, and at the GRUB console add the kernel option selinux=1 to enable SELinux in the kernel (press "e" to edit the boot options).
  7. You'll get tons of SELinux log messages while the system boots, that's normal at this point, don't worry.
    Then you can type "sestatus", which should print some information on the running SELinux system. If it says "SELinux status: disabled" something went wrong.

Congratulations! You now have a QEMU image with minimal SELinux support and you can start playing with it, tweaking the policy, finding and reporting bugs, reading tons of documentation on how SELinux actually works etc. etc.

As SELinux is (half?) a release-goal for Debian etch, it would be nice if many people could test it before the release, and this is one method to do so without breaking your production systems.

Update 2006-08-28: You don't really need user_xattr support for SELinux, only xattr support (for security.selinux xattrs) for the filesystem you use, which is available per default in Debian kernels (thanks Russell Coker).

ScatterChat - secure, anonymous, free, cross-platform Instant Messaging client

ScatterChat is a new cross-platform IM client announced by the Cult of the Dead Cow / Hacktivismo (during the HOPE conference, it seems).

From the website:

ScatterChat is a HACKTIVIST WEAPON designed to allow non-technical human rights activists and political dissidents to communicate securely and anonymously while operating in hostile territory. It is also useful in corporate settings, or in other situations where privacy is desired.

It is a secure instant messaging client (based upon the Gaim software) that provides end-to-end encryption, integrated onion-routing with Tor, secure file transfers, and easy-to-read documentation.

Its security features include resiliency against partial compromise through perfect forward secrecy, immunity from replay attacks, and limited resistance to traffic analysis... all reinforced through a pro-actively secure design.

So the client is a "friendly-fork" of Gaim, it uses Tor to achieve anonymity, and for the crypto parts (secure messaging, secure file transfer) ScatterChat uses libgcrypt.

It's a cross-platform application available for Linux, Windows; support for other OSes is planned (Mac OS X, others).

You can always download the source code, of course, as it's free software. Actually, not quite. While ScatterChat itself is based on the GPL'd Gaim, it has to be GPL'd, too. However, the scatterchat-module package, which seems to contain the crypto-parts, is licensed under a custom "Hacktivismo Enhanced-Source Software License Agreement" (HESSLA) right now, which is so horribly long I didn't even bother reading it.

However, the README says:

I am open to the possibility of re-licensing parts of this library to GPL, BSD, public domain, or some other license. I cannot make any promises, but I will try to accomodate reasonable requests.

I'm going to do just that, email the author and ask him nicely to change the license to some sane, well-known free software license. If you feel similar, please let the author know (hint, hint). Depending on what the HESSLA really says, it might prevent ScatterChat from entering Debian, for example.

I haven't yet tried to use the application, but it sure looks like it has a lot of potential. It also seems do most security-related things right:

  • it doesn't try to reinvent/reimplement its own crypto primitives (which would be doomed to fail), but rather uses libgcrypt
  • it has a documented crypto protocol
  • it's free software, which is a major requirement (see Kerckhoffs' principle)
  • it doesn't reinvent the wheel, but rather uses Tor for anonymity (for example)
  • etc. etc.

Of course that's no guarantee that it's secure; I hope some crypto-gurus look over it soon. But at least they didn't make obvious stupid mistakes we've all seen in many other pieces of software.

Anyways, I feel this is a real important project which will help lots of people (activists, political dissidents, normal people like me and you who value their privacy). Go check it out!

(via Boing Boing)

Anonymous Google Earth over Tor

I'm probably not the first one to notice this, but you can actually use Google Earth anonymously (upon first glance at least) over Tor. It seems all the traffic (downloads of maps and textures etc.) goes over port 80 (http) and 443 (https), which can easily be anonymized with Tor (read an older post of mine for details on Tor).

Just type

export http_proxy=
export HTTP_PROXY=

and set up Privoxy and Tor correctly, then start Google Earth in the same xterm and you're done. I haven't looked closely at the protocol Google Earth uses (any articles available on that?) but upon a quick glance in Ethereal / Wireshark all traffic is torified, not even DNS requests are leaked. Technical explanation: the Google Earth binary uses libcurl internally, which honors the http_proxy environment variable.

However, that's not a guarantee that you're 100% anonymous, as Goole Earth could send some unique identifier (e.g. MAC address, hard drive ID etc.) to their servers which would spoil your anonymity.

Btw, I actually discovered this accidentally because I have the above HTTP_PROXY lines in my .bashrc, so most of my HTTP traffic is anonymized by default...

Google Earth for Linux - Beta

OK, so Goole has finally released a first version of Google Earth for Linux (beta, of course).

Well, maybe this time they really mean it when they say "beta"...
Google Earth Linux 1 Google Earth Linux 2 Google Earth Linux 3
Here's some quick observations:

  • Of course, it's not open source, you basically get a bunch of *.so files and an executable.
  • It uses a bunch of open source software packages, though, e.g. libcurl, OpenSSL, libjpeg, libPNG, libtiff, libmng, zlib, Expat XML Parser, FreeImage, and a bunch of other things. All the licenses of those projects are contained in a README, though.
  • The installer seems to be (based on) the Loki installer, at least a ~/.loki directory is created with some stuff in it.
  • The maps cache, and some other files are stored in ~/.googleearth.
  • The ~/.googleearth/crashlogs directory contains log files which are generated when the application crashes, and sent to Google upon the next restart of the application automatically. The README says that you should basically chmod 000 ~/.googleearth/crashlogs if you don't want that. They say these files don't contain personal information. I haven't seen one yet (didn't crash, yet), so I cannot tell if that's true.
  • The EULA says that Google Earth will phone home (they call it "check for available updates to the Software"), and that you automatically agree to that when you use it: "By installing the Software, you agree to automatically request and receive Updates".
  • When I start Google Earth, I get a popup window which tells me to install Bitstream Vera Sans fonts or things might look strange. No idea which fonts extactly they mean, I've got the Debian packages ttf-bitstream-vera, and ttf-dejavu, but the warning still appears.
  • After Google Earth connects to the server(s) I get to see something resembling a globe, but not really what I (or Google possibly) expected. There's simply no textures for anything, I just see (broken) wireframes (see screenshot), but that's about it.

I'll have to play around with it a bit more, maybe it's an issue with the NVIDIA drivers or something. But as I don't have the source I can basically just make stupid guesses...

(via Golem, and a bunch of other sites)


The RedTeam, a penetration testing group, has released two security advisories which explain security holes in two podcast clients (podcatchers).

Both exploits are possible because the input of the programs is not properly (or at all) sanitized. Basically, they call system($wget_cmd) where $wget_cmd is shell (/bin/sh) code which shall download a file via wget. As the $wget_cmd string contains contents from an untrusted source (HTML/XML on some random server), this results in an "arbitrary code execution" vulnerability, the worst-case scenario you could imagine.

If someone is naive enough to even run such a podcatcher as root, this means a remote root exploit!

Anyways, the RedTeam is definately correct in saying that more and more people start listening to podcasts, and more and more podcatchers are written. But few of them are written with security in mind, which leaves many listeners at risk... I wonder how popular closed-source podcatchers such as iTunes are affected here. Are there any published audits/audit-results (black-box auditing, obviously, as you don't have the source code) for iTunes?

As for Free Software implementations... consider this a call for reviews and audits! If you know/use one of the many podcatchers (or an RSS feed aggregator, which are affected by similar issues), and have some knowledge on secure programming, get the source and review the application. Make the software you use, and the world at large, a little safer.

I'll definately have a look at the programs I'm using soonish...

Syndicate content