Recently in hacks Category

My day job mostly involves Perl, so I've been using it more for my random tasks at home. I've now put a few of them up on CPAN:

• Unix::Uptime - Determine the current uptime, in seconds, and load averages, across different *NIX architectures.
• Remind::Client - class for working with remind's daemon mode

I also have a few other scripts I've been messing around with, for doing some reporting and such:

• git-author-stats.pl - Gives a URL to draw a pretty pie chart of the top 10 committers to the current git repository. Examples:
  • Exherbo:
    • ::x11
    • ::vim
    • ::arbor's multilib branch
  • Paludis
• git-daemon-report.pl - Given some log file, scrape it stats on who is pulling which of your git repos, and from where. Won't work unless you run git-daemon with --verbose.

I migrated my blog from Typo to Movable Type a while ago. I wrote a little script to do it, but I've only just now gotten around to cleaning it up enough so that it's suitable for general use.

It's available now from my git repo, and on CPAN

As always, "patches welcome".

So, I had a few random old scripts lying around in SVN. I've migrated them to git now. Along with my other repos, they're browseable at http://git.pioto.org/

Things of interest might be:

• rbtpb - A replacement for tpb which is hopefully more robust.
• rubeak - A tool for handling multimedia keyboard keys, and some IR remotes.

Update: fixed links.

Previously I described how to partition your drive using LVM2 and dm-crypt. This time, I'm going to go over how to boot this system.

First off, you're going to want to have your livecd handy, because it's likely something won't quite be right the first time around. Also, you'll want to make sure your kernel is built with support for initramfs. This requires the BLK_DEV_INITRD configure option, named "Initial RAM filesystem and RAM disk (initramfs/initrd) support" in the "General setup" menu. You'll then need to specify the location of a source file for the initramfs.

Probably the easiest thing to do is to grab my current initramfs package and tweak it to suit your needs. You'll at the least need to change some paths in the config.txt and init files. But, it should serve as a good starting point. When you're done, put the path to the config.txt file in the "Initramfs source file(s)" (CONFIG_INITRAMFS_SOURCE) setting in the kernel.

Now, rebuild and reinstall your kernel, reboot, and pray.

I hope this will help people improve their laptop's security. Feel free to post any questions you have in the comments. Good luck!

Last time I kinda cheated and gave pretty much a redux of an earlier post. This one will hopefully have some more substance to it.

The partitioning scheme I'm currently using is like this:

/dev/sda1 - /boot (ext2)
/dev/sda2 - LUKS encrypted lvm2 physical volume

The /boot partition is created like any normal ext2 partition.

The sda2 partition is created like so:

cryptsetup luksFormat /dev/sda2

This usually is sufficient to provide decent encryption, but it is worth checking the documentation for cryptsetup to look for further options -- in particular, the option to use a keyfile.

Once we formatted this partition, we'll need to open it, so that we can then add our lvm pv to it:

cryptsetup luksOpen /dev/sda2 sda2_crypt

We'll now have a new device available as /dev/mapper/sda2_crypt. This can be treated just like any other block device -- we could just format it as a regular ext3 partition, but then we can't really ever resize it. So, we're going to make a LVM2 partition:

pvcreate /dev/mapper/sda2_crypt

Now, we create a volume group. I choose 'Exherbo' as the name, but you can really just use whatever (often people just use 'vg').

vgcreate Exherbo /dev/mapper/sda2_crypt

Now, we just need to make our partitions:

lvcreate -L 1G -n swap Exherbo
lvcreate -n root Exherbo
vgscan
vgchange -a y

This creates a 1G swap partition, and uses the rest of the space for our root (/) partition. Again, see the documentation for lvm2 for more options.

Finally, we need to format those partitions:

mkswap /dev/mapper/Exherbo-swap
mke2fs -T ext3 /dev/mapper/Exherbo-root

Next time, I'll go over how to boot this system.

Six months ago I posted an outline for encrypting your system with LUKS. Well, I figure it's about time for me to write up how to actually go about it. In this post, I'll outline the necessary kernel configuration.

The basic kernel configuration that I mentioned a long time ago still holds. Basically, you need to have the following options built into your kernel: CONFIG_DM_CRYPT, CONFIG_CRYPTO_CBC, CONFIG_CRYPTO_SHA256, and CONFIG_CRYPTO_AES. Most of those will be turned on when you enable:

Device Drivers ->
  Multiple devices driver support (RAID and LVM) ->
    Device mapper support ->
      Crypt target support

However, the SHA256 support will not be. It can be found at:

Cryptographic API ->
  SHA224 and SHA256 digest algorithm

On the note of kernel configuation: for this process, you will need to do a fair amount of work from within another linux environment (most likely a LiveCD). For Gentoo, the most recent CD image I've found that has all the necessary configuration is the 2006.1 version... As I recall, some of the intermediate minimal CDs, at least, didn't possess cryptsetup at all. And the most recent weekly build I tried, while it did have lvm and cryptsetup installed, didn't have CONFIG_CRYPTO_SHA256 either built in, or as a module.

Probably the best bet is an Ubuntu 8.10 Alternative CD. You'll have to either boot in recovery mode, or go through a bit of the installation procedure, as it doesn't initially have cryptsetup available. But, once it's detected the CD and loaded the modules from it, you can just switch to another virtual console and do things from there.

Next time, I'll outline creating the disk partitions.

Introduction

About five months ago, I wrote about how to convert an existing Linux install from using regular partitioning to encrypted volumes (in particular, an encrypted /home with an unencrypted /). That sort of setup is relatively simple, once you have all the partitioning done. There is no need for any special early userland stuff (an initramfs image). However, that approach only provides a relatively minimal level of security for your data -- someone could still root your system.

For those who are a little more paranoid (especially in light of some recent news), the next level of security for your data is to encrypt everything except your /boot partition.

Going to this level, you're going to be repartitioning pretty much your entire hard disk, so you might be best off just backing up everything (you should do this in any case), and reinstalling your system.

Some recent Linux installers make this sort of setup relatively pain-free. For example, Ubuntu 8.04's Alternative install disk gives the option of setting up an encrypted LVM volume to install the system on during its guided partitioning wizard. This is a rather easy way have your laptop's data securely encrypted quickly. However, with this setup, I wasn't able to get suspend-to-disk support to function properly (though I'm sure it could be done with a little extra effort, I don't know if most Ubuntu users would be willing to do so).

However, this guide is focused on the crowd of people who use distros that do not make this easy. For myself, I'm installing Exherbo during this guide, but the instructions should be almost exactly the same for Gentoo, or most any other distro.

Partitioning Overview

For this first step, you will need to create two standard disk partitions. The first should be only 32M or so in size -- this will be our /boot partition, and should probably be ext2. The second will be the rest of the space you wish to devote to this Linux install (in my case, 10G).

The final layout of everything is going to be like this:

/dev/hda1 - /boot
/dev/hda2 - dm-crypt encrypted volume, containing one lvm2
  physical volume

/dev/mapper/hda2_crypt - what we get when we run cryptsetup luksOpen
  on hda2, contains one lvm physical volume, containing the volume
  group "vg"

/dev/mapper/vg-swap - our swap partition
/dev/mapper/vg-root - our root partition

With this layout, all our data that can be encrypted / lvm-ized is. And we only need to enter our disk decryption key once to get to all of it.

Next Time...

In my next few posts, I'll go into more details about how to set this partition scheme up, how to configure your kernel, and how to create the necessary initramfs image to boot from an encrypted / partition.

I was inspired by a post on the Command Line Warriors blog to encrypt my /home directory. Unfortunately, the directions given in that post don't quite work. Here is the process I followed to set everything up.

We're setting up a basic LUKS volume encrypted with AES with a 256-bit key. This means we make a special "filesystem" on the disk partition which encrypts our real filesystem on disk, and makes it available unencrypted via the device-mapper interface (/dev/mapper/).

First, you need to have a partition available for your /home directory. In my case, I decided to nuke my Windows install, but most people will probably need to use parted to resize some existing partitions. If you're resizing your root ("/") partition, you'll need to run it from a LiveCD. For the partition, I chose the "Linux" type, but I'm not sure that really matters.

Once you've allocated the partition, you'll need to create the LUKS partition. You do this with the cryptsetup command. But, before you can use this, you'll need to make sure you've compiled these settings into your kernel: CONFIG_DM_CRYPT, CONFIG_CRYPTO_CBC, CONFIG_CRYPTO_SHA256, and CONFIG_CRYPTO_AES.

After configuring your kernel and you've rebooting, if need be, you'll need to install sys-fs/cryptsetup. Don't install sys-fs/cryptsetup-luks... it's old. The newest (>1.0) versions of cryptsetup are based on the -luks version, and are what you should be using.

Now, use cryptsetup to format the luks partition:

  cryptsetup luksFormat -c aes-cbc-essiv:sha256 /dev/hda4

Substitute /dev/hda4 with whatever partition you created earlier. It will ask you to enter a password. Use a strong one, and don't just write it on a piece of paper by your computer, or you've defeated the whole point of this.

Now, we need to open the partition so we can create our encrypted data partition. We do this with the following:

  cryptsetup luksOpen /dev/hda4 crypt-home

This will make /dev/mapper/crypt-home, which is the device you use to mount your /home. Currently that partition is unformatted, so use your mkfs of choice to format it.

  mke2fs -j /dev/mapper/crypt-home

Next, make a temporary place to mount this so you can copy over your data, and mount it.

  mkdir /mnt/crypt-home
  mount /dev/mapper/crypt-home /mnt/crypt-home

And then, copy all your data from your current /home to the new one:

  rsync -tarv /home/* /mnt/crypt-home

Now would also be a good time to back up your important data to some other location.

Before we continue, we should configure the system to mount our new /home at boot. This requires editing /etc/fstab:

  # /etc/fstab
  # ... your other stuff ...
  /dev/mapper/crypt-home /home ext3 noatime 0 2

and /etc/conf.d/dmcrypt:

  # /etc/conf.d/dmcrypt
  # This file has all sorts of comments in it already
  # just uncomment the following:

  ## /home with passphrase
  target=crypt-home
  source='/dev/hda4'

Now all that is left is to remove the unencrypted copy of /home. First, you should go through and rm -rf anything that doesn't contain sensitive information, like open source project code, your mp3s, etc.

The last step is to use the shred command to securely delete all the remaining files. Shred works by overwriting a file many times with different patterns to make recovering them extremely difficult. Use the following commands to securely delete all the files in home, and then remove all the empty directories:

  find -H /home/*/ -type f -exec shred -u -v {} \;
  rm -rf /home/*/

Now, reboot and if everything went well, you should be prompted for your password, and then everything should just work as it did before.

Update: fixed links.

So, been a while, but here's something I just threw together. It's still a little rough around the edges, but it seems to be more robust than tpb for my system, at least, and it doesn't require me to make /dev/nvram available.

It uses /sys/class/backlight/thinkpad_screen/actual_brightness (from the thinkpad_acpi module in the 2.6.22 kernel) to figure out the screen brightness, and /proc/acpi/ibm/volume to figure out the volume and mute states, also provided by the thinkpad_acpi module (I'll switch to using sysfs for this when it becomes available).

It also requires the ruby-xosd package, which you can get from my overlay: git://git.pioto.org/pioto-overlay.git

For lazy paludis users, just add this to /etc/paludis/repositories/pioto-overlay.conf:

format = ebuild
location = /var/paludis/repositories/pioto-overlay
sync = git://git.pioto.org/pioto-overlay.git
master_repository = gentoo
names_cache = /var/cache/paludis/names
write_cache = /var/cache/paludis/metadata

Or, you can just do: playman -a pioto-overlay

You can get the current version of this script from git at: https://github.com/pioto/rbtpb

Update: Fix links.
Update 2: Fix links, again.

Finally found a few decent ways to get around that obnoxious behavior of popping up the same dialog every 10 minutes, even after I said "No" over on the Coding Horror blog.

The quick `n easy way is to run net stop wuauserv. This will stop the reminders, as well as auto updates, until you reboot.

To make it less obnoxious in a few ways in the future, I found the "No auto-restart for scheduled Automatic Updates installations" options to fit the bill pretty well. It prevents automated reboots only if someone is logged in. So, my unattended workstation at work will reboot after auto updates, but my desktop at home will wait until I tell it to.

I found another nice little read on the subject on the Tim Rains' MSDN blog.