All of pioto.org is moving to a new server. To start things off, I’m locking my blog read-only. If you want to keep track of all this, Paludis ticket #582 has the details.
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'm starting to learn perl, and I've found the perldoc intro/tutorial stuff to be pretty useful, but I'd like to get a good printed book or two to read through and use as a reference.
Similarly, while I'd say I'm pretty *NIX savvy, I'm not too familiar with some BSD-isms, particularly where they differ from Linux. Are there any good books out there to help with the transition from Linux to FreeBSD? (No, I'm not abandoning Linux... it's just that my current employer used FreeBSD for many things.)
Any suggestions?
So, some people seem to have gotten all in a tizzy about Exherbo. While I don't personally think the wording on the front page is necessarily the best, here's the deal:
- We don't hate you. We just know we don't quite have something ready for general use. Rather than deal with many users wanting to try out something that most likely will not work for them, we have attempted to dissuade people from trying Exherbo until we think it's ready for them to.
- "Then why announce it?" Because Bryan is going to discuss it at an upcoming conference, so we decided we should have some sort of web page up. We didn't put it up on Slashdot, though.
- This isn't Ciaran's brainchild. It's Bryan Østergaard's (aka kloeri). Yes, Ciaran is involved in the project, along with a number of other former Gentoo developers, but he isn't the "lead" (though I don't think we really formal roles at this point).
- "Why don't you use...?" We've already looked at many existing projects to fill some of the spots we've decided to fill ourselves instead. For example, we took a look at upstart, Gentoo's baselayout 1.x, openrc, etc. However, none of them seemed to do quite what we wanted. That's why we're working on projects like genesis, why we're writing our package tree from scratch, and using our own package format.
So, I hope this helps to clarify things for some people who still seem to be confused as to what Exherbo is all about.
After an hour of fussing, I've upgraded typo to the latest version. Would have been much easier if their installation documentation were up to date... Enjoy the shiny new look.
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.
I just set up a commits list for Paludis' subversion repository. You can subscribe to it at http://lists.pioto.org/mailman/listinfo/paludis-commits
So, I finally dropped lighttpd/fcgi and switched back to Apache 2.2. Trac is running with mod_python now. I think I've tracked down the main cause of our load/memory issues - googlebot. It was indexing all 4000 some revisions of our svn repository via the trac browser... bad stuff, but it should be blocked from that by our robots.txt now.
Also, I've added WebDav for Subversion now. Paludis is at http://svn.pioto.org/paludis, and the same is true for most of the other repos I host as well. Now those who have evil company/school firewalls and proxies can get through.
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: svn://svn.pioto.org/pioto-overlay
For lazy paludis users, just add this to /etc/paludis/repositories/pioto-overlay.conf:
format = ebuild
location = /var/paludis/repositories/pioto-overlay
sync = svn://svn.pioto.org/pioto-overlay
master_repository = gentoo
names_cache = /var/cache/paludis/names
write_cache = /var/cache/paludis/metadata
You can get the current version of this script from subversion at: http://svn.pioto.org/rbtpb/trunk/
So, I've been digging into why Windows XP can't deal with a system clock set in UTC. Apparently, it even keeps its internal time as UTC, but it still won't deal with a system clock set to non-local time.
I found this article from an MSDN blog, which gives a decent summary of the reasons why. Basically, it would break support for some pre Windows NT/XP things. Well, XP and Vista already break enough other things compatability-wise that this shouldn't be such an issue now.
I also found this nice article on all the reasons it should be changed.
Apparently, a registry key does exist that once allowed people to use a system clock set to UTC, but it isn't documented, and most of the newer Windows code hasn't been updated to support it. No word on if Vista does a better job at this. Has anyone else had luck getting windows to cope with a UTC system clock?
Recent Comments