Prerequisites:

1. StarCraft Broodwars and patch — this must be installed and patched to at least 1.16.1.
2. VisualStudio 2008 express — You only need to install the C++ portion.  Note, however, that VS 2010 currently _will not_ work. (not needed if none of the downloads are source that needs to be compiled).
3. Python 2.6 — pybw should compile against any 2.6.  Python 2.7 may work, but is untested (the project build will need to be modified to include 2.7 instead of 2.6 headers).
4. Chaoslauncher.zip — The Chaoslauncher can be a little harder to find since the website hosting the project went down.
5. BWAPI — If you wish you may compile this from source, but the binaries should work just as well
6. pybw — Checkout the source. Upstream currently only supports BWAPI up to version 3.2 Beta.  Or download precompiled binaries.
7. vcredist_x86.exe — This may need to be installed.

Installation

Install Starcraft with 1.16.1 patch.  Then follow steps 1 – 4 (note the section is misnamed, “Build Instructions”) for setting up BWAPI to be injected into Starcraft using the Chaoslauncher.  If compiling pybw from source, follow the instructions from the README file.  Otherwise, you may need to install vcredist_x86.exe and then you should be able to run pybwClient.exe from the binary distribution to start the example AI.  Keep in mind that an AI can not start once you’re in a game.  Starcraft should be started with the Chaoslauncher with BWAPI checked.  It will be obvious that the AI is connected at game start because there will be text on the screen indicating the revision of BWAPI being used at game start (not to mention that the workers should automatically start gathering minerals).

Well I’ve recently been spending a lot of time back in windows playing with the BWAPI (the subject of a forth coming post).  Because I’ve been doing non-trivial things in windows, I want to hibernate the machine instead of just shutting it down.  To my consternation, I noticed that, after hibernating from windows and then restarting, the bios disabled access to the bios menu and bios boot menu and booted directly to the windows device.  Since I boot my linux from a usb but the windows install is on a harddisk, this is problematic.  Effectively hibernating to windows forces me to resume back to windows.  However, when I shutdown windows and boot back up, the bios menus are re-enabled.

After doing some googling around, i found others with the same problem, but no solution.  Now, I’ve been spending a lot of time learning about my Phoenix UEFI firmware and know that the boot menu can be modified from a UEFI booted machine by modifying the UEFI variables.  So, I could see how a UEFI booted OS could at hibernation change these variables to only boot the device which was being hibernated to and disabling all other firmware access.  The funny thing was that the OEM windows install booted from the MBR and not an EFI bootloader application.  Thus windows was not running under UEFI (actually it is running under UEFI, but in a BIOS compatibility mode) and accordingly could not modify the UEFI variables.

So I started thinking “how is the firmware being modified such that the firmware knows to disabled firmware access and boot directly to the windows hibernated device?”  The first thought I had, was that somehow this information is being stored in ACPI, which I knew only a little about.  After downloading the ACPI spec and reading about the various sleep states, I realized that the hibernate state, S4, does not fully turn off power to the machine.  Yes, the computer looks completely off, no lights or sounds, and even a firmware loading screen is presented on “power on”, but it is sucking tiny bit of energy (see ACPI spec v5 16.1.4).  Somewhere, maybe in some modified ACPI tables but I’m not sure, windows hibernate tells the firmware to just boot directly to the device window hibernated to.

Armed with this knowledge, I decided to see if cutting all power to the machine would change anything.  I hibernated windows, then disconnected AC power and the battery.  When turning the laptop back on the result was the same, no boot options.  Coincidentally, I had been reading my laptop’s service manual about how to replace core components and I remembered that the manual said to ensure that there was no residual power in the system before disassembling.  The manual said to ensure this by removing battery and power and then pushing power button waiting for a second and pushing the power button again, repeating several times.  That did the trick, the firmware booted back up and allowed me to select which device I wanted to boot from and get into the firmware setup menu.  It also has no effect (as far as I can tell) on the resumed windows, which resumes without issue.

Strangely, hibernating from linux (using the tux-on-ice kernel) does not exhibit this behavior.  I can think of two possible reasons for this.  One, linux or tux-on-ice specifically do not actually go to S4 on hibernate, but actually go to S5 (logical off).  Or two, it has to do with the fact that I’m hibernating from a running OS that was booted from a removable device.  Without further testing, I suspect the former more likely.  Anyone else have any ideas?

The ultimate solution would be to have the disk do the encryption itself, and you only feed it a key or password to unlock it at boot.  This could be much better performance-wise since the encryption would be all done by the processor on the drive.  There are now some SSDs which come with FDE (Intel’s 320 series and a samsung one), however there are a few reasons to be cautious.  It appears as though the drive can be locked and unlocked with a password, but I have no reason to believe that the encryption key, which in Intel’s case is randomly generated, is encrypted with the password.  I suspect that the data encryption key is stored in the clear somewhere on the device.  Also, I’d like a way send an arbitrary (valid) data encryption key to the drive to be used for encryption and there should be a way to independently verify that the encryption key is being used.  Perhaps a way to request data before encryption/decryption.  The other issue is that there is in general only support for one encryption algorithm, whereas with software FDE there can be potentially limitless.  Since, I don’t have one of these drives and I’m not sure I trust them, I’m stuck with software FDE.  Now on with the show.

The big picture

What we want to end up with is Ubuntu residing on an FDE partition, booting from a USB stick.  There should be no way to boot the Ubuntu partition from the disk itself.  This will prevent determined attackers from installing a modified bootloader to grab your passwords or keys.  Also, we’d like to allow Ubuntu to hibernate to some encrypted space, so attackers can read the hibernation dump to get the master key which decrypts the partition.

Installing Ubuntu FDE

I won’t go into detail on how to do this, since there are good resources for doing this (this seems better as it goes over installing boot onto usb).  However, I want to reiterate that you should not create an unencrypted boot partition.  I recommend creating a single lvm partition for the whole system, that includes /boot.  But how can we boot if /boot is itself encrypted?  Continue reading…

The Bootloader

There are two main ways to boot your encrypted volume from a USB stick: boot from an unencrypted initrd located on the usb and unlocking the luks partition from grub and then booting from the initrd in /boot (will need to compile latest grub2).  The former is the easiest to setup, but the latter more secure (in a probabilistic sense).

Booting from initrd on usb stick

Your usb should have a filesystem readable by grub (fat32 should work) with enough space to store the initrds and kernels (100Mb should work).  To install grub, mount the usb partition and do grub-install –no-floppy –boot-directory <path/to/usb/mount> <usb device>.  Now grub is installed, but we need to add a configuration file and the initrds and kernels.  The easiest way to do this is to copy /boot/grub/grub.cfg and /boot/{initrd,vmlinuz}* to the mounted usb partition (make sure the directory structure is the same, eg. <usb mountdir>/boot/grub/grub.cfg exists).  You should now have a bootable usb, which will appear to boot as if you have booted from the disk after a normal Ubuntu install.

However this still leaves much to be desired.  When you upgrade your kernel, you’ll have to manually copy over the files again.  Also, the initrd is stored unencrypted on the usb, so an attacker with access to the usb could easily modify it to capture your key or password.  Can we do better?  I’d argue we can, see next section.

Booting from encrypted initrd

This section requires that you have compiled a luks-enabled grub2 (you’ll need device mapper development files).  Support has been merged in to trunk, and I believe is included in the 1.99 release.  We will use this new grub to open the luks container to load the initrd from our encrypted boot.  Once you’ve got the newer grub compiled and usable, you can install the newer grub on the usb the same way you installed it in the previous section.  After, boot/grub/luks.mod and boot/grub/cryptodisk.mod should exist.  Since the grub config in /boot is automatically updated it should always be in sync with installed kernels, so we’ll have grub load this config.  Here’s a grub menu entry to do all this:

menuentry 'Grub Cryptomount: Ubuntu 11.10 load grub.cfg' {
    insmod luks
    insmod lvm

    cryptomount -u 0123456789abcdef0123456789abcdef
    set root=(lvm/ubuntu-root)
    configfile /boot/grub/grub.cfg
}

The cryptomount UUID and root device will need to be changed.  You can boot the new grub on the usb and enter the commandline to figure out these parameters.  Try manually unlocking the luks partition with cryptomount.  Also, as far as know, cryptomount can only unlock luks via a password, and not a key.

Once you’ve got this working, you’ll notice that you need to enter the password for your encrypted volume twice: once when grub need to get the initrd and again when the initrd needs to decrypt the volume.  You could modify the initrd to contain a keyfile and the key to the luks volume (luks allow for 8 slots of keys or passwords to decrypt the volume).  The key would be securely stored on the encrypted boot.

A note on security, assuming the most capable attacker this method isn’t any more secure than the first method.  The grub boot sector or grub.cfg could be hacked to load key logging code.  However, the number of people capable of this attack is orders of magnitude smaller than those that can install one in an initrd.

Thanks to xercestech for this luks grub idea.

Hash verification

You may wish to perform a hash check on critical data to detect if someone has been tampering with your device.  Of course, a successful hash check does not mean that this data has not been modified, since the hash checker could have been modified to always return true.  However, it can present an extra hurdle for a would be attack.  Also, there could be a real benefit to checking the hash of the luks header, to prevent an old comprimised header from being reinstalled.  Grub has a “sha256sum” command which has a “-c” option for doing a hash check of data against a list of signatures from a given file.  So you could store a hash signature file on the usb and have grub do the hash verification from that file.  One thing to note is that file names may contain grub block syntax.  So you could verify the hash of the first 4k of (hd0,1) with a hash file containing the line “<<HASH>> (hd0,1)+8″.

Tux-on-ice encrypted hibernate

I have found the tux-on-ice hibernation kernel patches to be superior to the mainline swsusp, so naturally I wanted to get hibernation with this kernel working on my encrypted system.  Now, I should say that I’m not sure its strictly necessary to add the resume parameter to the kernel when resuming from hibernation (this parameter tells the kernel where to look for the hibernation image).  Tux-on-ice might be able to automatically find it based on fstab, unless you’ve configured the hibernation image as a file.  Either way, I didn’t want to take any chances.  The easy way to have the resume parameter added to each kernel menu entry in the grub.cfg is to add the parameter to the GRUB_CMDLINE_LINUX variable in /etc/default/grub and then run update-grub.  If you’re using the unencrypted initrd’s, then you’ll need to change the grub.cfg on the usb manually.

Can we do better?

Mandos is an interesting idea for getting servers with encrypted root file systems to reboot unattended and/or remotely.  Though, it would give us less security if configured with an unencrypted boot.  It could be installed in an initrd booted from a usb stick inserted by a person “trusted enough to put the usb in and boot, but not trusted enough to have a password for the encrypted volume.”

Lukstool might be an good tool to integrate with the initrd, to try to thwart memory dumping attacks (it can open multiple “fake” crypt devices, so that there are multiple keys in memory.

Scubed is steganography for your hard drive.  This tool would allow you to plausibly deny the existence of your encrypted system.  Unfortunately, it appears to be unmaintained (no changes in at least 4 years).  So it might take some effort to get it to work with the current device mapper.

For headless servers, an ssh daemon can be run from within the initrd so that a password or keyfile can be provided remotely.  There is documentation at /usr/share/doc/cryptsetup/README.remote.gz and many posts about this.  This would again necessitate an unencrypted initrd.

Now I’m trying to take the least hackish, but also least work approach. Apparently, the 32-bit deb can be modified to lie about its architecture to fool the package manager into installing it according to this post. I’ve taken a similar approach in a previous post, but its not really a long term solution.

In theory there’s 32-bit binaries should have no problem’s running on a 64-bit machine in compatibility code. So I figured there must be a way to install the 32-bit packages via the 32-bit repositories. Basically you setup a chrooted environment for installing a base 32-bit debian system and then install the package from inside there. I copied my source.list directly to the chroot so I didn’t need to recreate it.

After installing zsnes from the chroot, I decided to give it a test run. I tried to run it from within the chroot, but zsnes kept dying saying that it could not setup the video mode. Using strace I saw a lot of failed ioctl’s to the frame buffer using the FBIOPUT_VSCREENINFO ioctl. So then I tried running from outside the chroot, but I’d get a segfault. I used ldd to verify that the binary was linking with the correct libraries (32-bit, not 64-bit), and it was. So I googled and came across a zsnes forum thread giving a solution to the problem. I slightly modified the instructions for my version of libao, which was using the plugins-4 directory. I had noticed this when perusing the strace output.

This got zsnes up an running. I’m a little curious as to why it was failing to run with in the chroot environment (the fb device was opened fine), and what could be done to get it to work. And tangentially why I wasn’t able to run x11 programs from within the chroot either.

PS: Using strace with an x11 program from in the chroot, I see that it is connecting successfully to the unix domain socket successfully, but the X server sends “No protocol specified”. Then it tried to connect to port 6000 on localhost, which fails because the X server is not configured to listen there. So far google has found some answers, but none of them work in this case. Maybe I’ll revisit this when/if I need it.

Background

Recently I wanted to test out the new firefox-3.5 on my Ubuntu 8.10 (Intrepid) and I didn’t want to upgrade (I don’t think its in jaunty anyway) due to a previous upgrade disaster to jaunty. Googling around I found Ubuntu Mozilla Daily Build Team, which has an ubuntu repository of the latest firefox builds, among other mozilla related stuff.

So I did the whole “add foreign repository” process, adding the repository and verification key. Then I did did an update and tried to install the firefox-3.5 package through the synaptics gui. It complained about not being able to satisfy dependencies and wouldn’t let me mark it for installation.

Upon further investigation, I concluded that the issue was that firefox-3.5 had a dependency for xulrunner-1.9.1 (>= 1.9.1~rc2). But the only version of xulrunner that the repository had was version 1.9.1~hg20090620r26001+nobinonly-0ubuntu1~umd1~intrepid. Since the firefox-3.5 package was version 3.5~hg20090620r26001+nobinonly-0ubuntu1~umd1~intrepid, I assumed that was the correct version of the xulrunner-1.9.1. I haven’t looked into it, but it must be that debian/ubuntu’s version comparison routine thinks that 1.9.1~rc2 > 1.9.1~hg20090620r26001+nobinonly-0ubuntu1~umd1~intrepid, but the package maintainers actually thought that should be false. Thus, I concluded that it should be safe to force the installation of the packages, even if I had to fool the package manager.

Fooling the package manager

Here’s what I did and I know there are other ways of achieving the same thing. Since synaptics wouldn’t even let me mark the package for upgrade, I didn’t have the firefox-3.5 deb package in the package cache. So to get synaptics to retrieve the deb, I first had to fool it into thinking the dependency could be met. I did this by modifying the cached repository list for the packages, which in my cases was /var/lib/apt/lists/ppa.launchpad.net_ubuntu-mozilla-daily_ppa_ubuntu_dists_intrepid_main_binary-i386_Packages. I searched for the line “Package: firefox-3.5″, which will get you to the section on that package. In that section, there is dependency information about the package and I modified “xulrunner-1.9.1 (>= 1.9.1~rc2)” to “xulrunner-1.9.1 (>= 1.9.0)”, which I figured was sure to pass the version test.

I restarted synaptics and was able to mark the packages fro upgrade. However, when I tried to then install the packages, they were downloaded but failed on installation. This was the debian package management system, which ubuntu is built on, has dependency information in the packages as well. That makes sense, because one might want to install a package that didn’t come from a repository, but causes more work for me.

So I needed to now modify the dependency information inside the deb package file. I went to the package cache directory, /var/cache/apt/archives, where the downloaded deb packages are stored. The firefox-3.5 package was extracted with dpkg-deb -x <deb file> <extracted archive dir> and dpkg-deb -e <deb file> <extracted archive dir>/DEBIAN, the latter being needed to extract the dependency file. The contents of <extracted archive dir>/DEBIAN/control look very similar to the firefox-3.5 section of the cached package listing file we modified earlier. I changed the dependency to match the change in the cached package listing file and rebuilt the deb package with dpkg-deb -b.

Now, at this point I thought I would be good to go. It turns out that now your package won’t match file verification values in the package listing (noticed the MD5sum and SHA1 lines?). So I modified the size, md5, and sha1 values in the package listing. Upon reinstalling firefox-3.5 from synaptics, everything installed with out a hitch and I now have a functioning firefox 3.5 to play with.

NOTE: Make sure that in the last step of reinstalling firefox-3.5 from synaptics that you aren’t downloading any files. If you are, then your size, md5, and/or sha1 values are probably not correct. It definitely won’t work if you are downloading data because your modified package in the package cache will get overwritten with the original.

Conceptual Overview

Suppose you have email address gmail@mydomain.com, which you want to have email sent to it end up on google’s gmail servers, and local@mydomain.com, which will go to your own servers. All mail will be configured to route through your postfix server, which will be configured to send the mail to the appropriate places depending on the address.

Implementation

Configuring google apps account

First of all, hosting your email on gmail, such that you are using your domain, wouldn’t be possible without google’s relatively new google apps hosting feature. You need to first get an apps account, if yo don’t already have one. I’ll assume you can figure out how to setup the google account. Its pretty straight forward and nothing tricky about it, just follow the instructions. Make sure you verify your domain, but don’t follow the instructions for activating email for the account. Also make sure you create a user for each email account you want hosted on gmail.

Configuring DNS

Modify the instructions given by google in the process of activating email for your apps account such that instead of using your domain as instructed for configuring your MX records, use a subdomain of your domain. For the purposes of this article, I will be using g.mydomain.org. So for instance, your dns should be setup such that MX record for g.mydomain.org with priority 10 points to aspmx.l.google.com. Have the MX records for the domain (mysite.com) point to your postfix server. Also, gmail servers will not allow relaying, that is your smtp server sending email to it, unless the reverse DNS mapping for the IP of the smtp server corresponds to the domain given by postfix client to gmail smtp servers, which is controlled by the myhostname configuration parameter in main.cf. So as far as I can tell, if you don’t control the reverse DNS record for your smtp server’s IP, this probably won’t work.

Configuring Postfix

I will not go into configuring your postfix server for delivering mail, since this is really specific to your setup and not the point of this article. Assume that by default you already have postfix setup to deliver email to mydomain.com to some other default destination. To tell postfix to route gmail@mydomain.com to gmail’s servers, use the following config snippets:

/etc/postfix/main.cf:

virtual_alias_maps = hash:/etc/postfix/virtual
smtp_generic_maps = hash:/etc/postfix/generic

/etc/postfix/virtual:

gmail@mydomain.com gmail@g.mydomain.com

/etc/postfix/generic:

gmail@g.mydomain.com gmail@mydomain.com

Of course, depending on your setup, the absolute paths here and how you store your virtual table may change. When gmail@mydomain.com receives mail, she will not have a To header as g.mydomain.com. Also when sending email, one should not send email to gmail@g.mydomain.org, as this mail will be rejected by gmail’s servers.

Notes

Using this setup you need to add a virtual alias for every user you want to have forwarded to gmail. You can setup postfix to forward all accounts by default to gmail and selective route others to other destinations by modifying these instructions to by default send mail to gmail and change the subdomain MX records to point to the other destination (or if the destination is the local box only postfix need be modified). This is left as an exercise to the reader.

If you are using sasl authentication, you should make sure, if you desire, that the authentication coincides with the gmail account. Usually, when authing with gmail’s smtp servers to send outgoing mail, the username and password are the same for logging into the account via the web interface or imap. If you already have an auth mechanism setup for the default delivery point, it won’t know about the gmail user credentials and so won’t be able to auth them. You probably don’t want to just set your email clients outgoing smtp server to google’s because, then when you send an email to local@mydomain.com google thinks it should be the owner of that domain and see that that user does not exist and bounce your mail. So to effectively send mail across the two delivery points, the mail must go through the postfix server. Just make sure your auth mechanism knows about your gmail users and auths the correctly.

References

• This appears to be an alternate solution to my problem, which is simpler. However, I believe that the To field of received emails will have a domain of, in my case, g.mydomain.com. While this technically isn’t a problem since rarely do you do anything with the To field of received email, my goal is to achieve as much transparency as possible.
• Email routing through google, requires non-free account.
• Setup email gateway which routes to google using qmail.
• Setup postfix to relay a domain to google using transport
• Configure postfix to use gmail for outbound smtp
• Simlar to above link, but looks like there’s more detail.

This means that all the normal problems of untrusted proxy servers accompany the use of Tor. For instance, a malicious exit node can manipulate unencrypted traffic or steal sensitive data (read passwords). Compound this with the fact that many secure sites send secure data unsecurely, even google. The effect is that users may be better off not using Tor.

Of course, Tor is an anonymizing tool not a privacy tool, so this is to be expected. As Schneier points out, “the price you pay for anonymity is exposing your traffic to shady people”.

However, all is not lost! If there is end-to-end encryption to the website, no eavesdropping can occur. Many sites don’t have https versions of their site, so this isn’t always possible. Some sites that require a login perform that login over https, but then, after authentication, revert to http, allowing session cookies to be stolen and the account compromised. Using the ForceHTTPS firefox extension, one can enforce that a secure connection is always used after login.

Tangentially, an interesting idea I ran across was that since Tor exit nodes can manipulate unencrypted data however they wish, spammers could setup Tor exit nodes to crack captchas. What about manipulating the output of certain websites? All google search results now point to a link which exploits the browsers.

Tor introduces a man-in-the-middle injection point. What makes this worse than just using a direct connection, is that its easy to setup a Tor exit node. With a direct connection one of the routers along the way has to be accessible by an attacker. This is harder to obtain unless you obtain the assistance of the owner (ie not that hard for the government or telcoms themselves). Tor does allow a whitelist of exit nodes to be used, which should alleviate much of this concern (but do you really trust them?). You might setup your own Tor exit node and only use that one to be sure. But as a Tor operator you could be more highly scrutinized, possibly leading to a “cure worse than the illness” situation.

So if you’re going to use Tor for webbrowsing be very careful. Don’t sign in to sites without ForceHTTPS installed and protecting that site. Never, EVER accept improperly signed ssl certificates. Make sure you’re using the torbutton extension. And be generally conscious about what you’re doing over an insecure connection.