• a good earing
• smartmontools

Indeed, so far, I haven’t found anything better than launching a process making a lot of disk activity.

This command just do it:

% sudo smartctl -t short /dev/sda

The “short” test will give you a few minutes to carefully listen and select the right disk.

Well, it sure is pretty primitive! But do you know anything better?

By the way, there is a good article for the recovery procedure.

It is vulnerable to a MiTM attack where the attacker can intercept and retrieve the credential to a trusted HTTPS website, by intercepting the session cookie sent back to the client.

A proof of concept of an attack against Twitter was made.

Fine. But so far, the answer was to just disable any renegociation.

This actually causes some issues with SSL session timeout and totally broke client authentication.

I got into problems because of the latter. I am using client authentication for some location of my web server, and I recently could not connect anymore to these with the following log in apache :

[Tue Nov 24 16:56:15 2009] [debug] ssl_engine_kernel.c(1912): OpenSSL:Exit: error in SSLv3 read client hello A
[Tue Nov 24 16:56:15 2009] [error] [client x.x.x.x] Re-negotiation handshake failed: Not accepted by client!?

I first was not aware of the openssl patch and tried almost anything possible. My focus was, of course, on the certificate and the client.
But, a nice guy on IRC #suse, Stittel, had a good hunch and suggested me to look at the CVE-2009-3555 fix.

After more tests, it was quickly confirmed to work well with older versions of OpenSSL (as shipped in Debian Lenny).
Finally, I downgraded the OpenSSL version on my openSUSE box to a version prior to the CVE-2009-3555 fix and it just worked fine.

Then, I dig into it and found a lot of interesting reports there and there. So far it is a real mess.
In short, the breakage will stay as long as browsers don’t also include a patch to avoid renegotiation.
So far, I could not find a browser that does include a patch.
If anyone reading it knows a version that does it, please let me know.

Meanwhile, you have actually the choice between :

• low security by deactivating client authentication on your server
• low security by keeping a vulnerable version of OpenSSL

As my server is not very exposed, I chose the latter, but that’s not satisfying.  It is not recommended, but if like me you need to use client authentication with mod_ssl on openSUSE 11.2, do :

% zypper install --from repo-oss openssl openssl-certs libopenssl0_9_8 libopenssl0_9_8-32bit

where repo-oss is the alias to the 11.2 release (without updates) on your system.

What a brutal way to fix an issues without much notification and consideration to the users ! Even the log message is wrong and just confusing the administrator…

PS 1 : thanks again to Stittel for the good hint (I hope you will come by here) and to the always nice and helpful #suse channel in general

PS 2 : bug reported on openSUSE bugzilla

The threat is serious as it could allow a local user to gain root privileges.

Those who compile their own 2.6.x kernel should apply this patch (from Linus, check there for more info) .

Within your kernel source folder :

$ patch -u -p0 < sock_sendpage.patch

I hope an official patch will be released soon for all kernels. I did not check if the 11.1 kernel has already been patched or not.

I can’t wait for it to become stable !

UPDATE 2009-02-05 : I hope to see this soon on a Linux distribution.

Cannot create link /etc/mtab~
Perhaps there is a stale lock file?

As a result, some of the partitions were not mounted and the system was pretty much broken.

But, no need to panic, just erase all the lock files (be careful not to erase the mtab file itself !) :

$ rm /etc/mtab~*

Now test mounting your partitions to check that you don’t get this message anymore :

$ mount -a

If it is alright, reboot and it should be fine.

The first surprising thing was the file I downloaded. It is now not anymore a tar.gz archive but a .bundle file.

After downloading, as root, just make it executable or start it with sh :

% sh VMware-Workstation-6.5.0-118166.x86_64.bundle

It now starts a graphic installer, that takes care of everything. All the compilation process is now hidden to the user.

I was expecting the compilation to fail and that I would have to look for a patch to run on my edge Linux kernel. Indeed, I just compiled 2.6.26 kernel (64 bits) a few days ago.

But nothing like that. the process went smoothly.

However, I was still prudent. Even after a compiling, previous versions almost always required some patch to get full networking to work.

So I gave a try and launch one of my virtual machines. Surprise : all worked out of the box !

For the first time, I even did not need any vmware-any-any patch or any network patched vmmon and vmnet modules to get wifi networking operational.

I also quickly noticed some very nice and fancy features :

• 3D graphics support
• more devices supported : fingerprint reader device, audio driver for Vista, …
• a graphical virtual network settings editor : this utility had been for ages on the Windows version and finally will make your easier on Linux

At last, but not least, the Unity display mode.

Though I am not a Mac user, I believe this can be compared to VMWare Fusion. Anyway, it allows you to display the virtual machines programs within your X session.

Look at this screenshot :

The result is quite spectacular. On my Gnome desktop, I am now able to display some windows from Windows XP and Windows Vista.

Well, this is not yet perfectly smooth or artifact free, but this is already really usable and responsive enough to be used intensively.

Another limit is the operating system support. So far, among my virtual machines, I was able to do it with Windows systems but not Open Solaris for instance.

There must have been more improvements, more or less visible, that I am not aware of. I won’t go for a full review.

I just wanted to insist that if you are a VMWare user,  you really should consider to upgrade for the complete support of the latest kernel and the Unity feature.

It seems that VMWare has listened to the Linux users, or at least is taking it more seriously. Not that they are nice, but the competitors are close (Virtual box, KVM, Xen…) !

I have had no time so far to check all the keys on my server. I prefer to stay on the safe side, though I have some reason to believe that my keys might not be so vulnerable : I generated them a long time ago, maybe before the Debian maintainer sad mistake.

It is going to be pretty easy now, for those who are motivated, to get access to the ssh server running keys generated during the 2 last years…

I recommend this article which summarize pretty well the situation. You may also use this tool, which checks if your keys are vulnerable :

$  perl dowkd.pl file ~/.ssh/*.pub

It find it funny to think that I chose to use certificates for security (avoiding brute force attacks).
What’s less funny is the pure disaster for the reputation of Debian.

I already noticed in the past that some companies switched their servers from Debian to Red Hat because of such security problems. They claimed about some security holes being patch much too slowly and about the lack of official support to rely on in such a crisis.
This kind of news is not going to enforce trust from companies.

I myself will think twice in the future about what system to use when I design my networks.

An external hard drive that I just bought (320 Gb) that allowed me to back up my entire /home partition and consider encrypting it.

I mainly used this tutorial, but I derived a little from it about the unlocking system : I did not want to input a password while the machine boots, I wanted it to be transparent while I log in. This how to provides more complete information, if needed.

So I will summarize here the actions to get an encrypted volume.

The tools

dmcrypt is a device mapper supported by the 2.6 Linux kernel. Roughly, this is an abstraction layer between the kernel and the real file system, doing all encrypting / decrypt operations. It is a replacement of cryptoloop, which created a loop device in a file within the file system. It can’t encrypt a whole partition and can be considered now as less reliable and secured.

The encryption is based on LUKS is a userland tool aiming to simplify the set-up of dm-crypt. It also stores some set-up information related to the encryption in the partition header, to make easy the transportation of the data from a machine to another, changing the passphrase without having to re-encode the entire partition, and even support having multi passphrases for the same device.

What to encrypt and why ?

The first thing is to decide what you will encrypt and how. Of course, I consider that your drive is rightly partitioned with, at least, the /, /home and swap having each a separated partition.

It is the case on my laptop. I chose to encrypt both the /home and the swap partitions.

In my case, there were little interest in encrypting the / partition. It contains only configuration files (without any password hardcoded), the /temp and applications – nothing to keep secret. But of course it might be different for you, depending on the security level you are looking for.

To the contrary, the /home partitions contains a lot of private data that I wouldn’t like anyone access in any case.

Then, it is rather important to encrypt the swap, because it is roughly a partial of you RAM and therefore contains all kind of information from your opened session. The annoying thing is that hibernation (suspend to disk) will not work anymore. It is anyway worth to be done, as it is well explained by this blogger.

Preparing the software

Using Debian Etch or Ubundu Festy/Gutsy, it is easy though the provided kernel (2.6) already supports device mapper, crypt target and AES cipher algorithm as modules :

$ apt-get install dmsetup cryptsetup libpam-mount

Encrypting swap

UPDATE 2008/04/13 : it is now possible to encrypt the swap in a way that preserve suspend-to-disk.

It is a good test to start with the swap, as there is no risk that you loose some valuable data.

First, let’s deactivate the current swap before any operation :

$ swapoff /dev/hda2

We suppose that hda2 is your swap partition :

$ cryptsetup luksFormat -c aes-cbc-essiv:sha256 /dev/hda2

add this line to the /etc/crypttab file :

swap    /dev/hda2       /dev/urandom     swap

It means that we are going to create a mapper named swap for the /dev/hda2 device. It will use a random key as a passphrase for the encryption.

There is a choice to do between /dev/random and /dev/urandom. The latter is in theory a little bit less secure (the randomizing is inferior to the /dev/random, as it reuses the internal pool data for the generation), but it is preferable if you don’t want to be blocked at boot time, while the kernel is trying to get more entropy (you can shorten this by pressing some keys, though).

Now starts this script :

$ /etc/init.d/cryptdisks start

It will create a mapper named swap to the /dev/hda2 partition, as set in the crypttab file.
This is equivalent to this command :

$ cryptsetup -y create swap /dev/hda2

Now, we need to create the file system :

$ mkswap /dev/mapper/swap

Now we need to update the /etc/fstab file, commenting the old entry for hda2 and adding a new one for the mapped device :

/dev/hda2       none            swap    sw              0       0
/dev/mapper/swap        none    swap    sw      0       0

Now you are ready to test ! Just reboot, and without any user interaction, you should get an encrypted swap with a randomized key.

Encrypting /home

Now let’s encrypt the /home. Before doing anything, be SURE that you made a BACK UP of ALL your data. The entire /home will be ERASED !

We consider that hda3 is the /home partition :

$ cryptsetup luksFormat -c aes-cbc-essiv:sha256 /dev/hda3

$ cryptsetup -y create home /dev/hda

$ mkfs.ext3 /dev/mapper/home

We won’t use neither the crypttab file or the fstab one, because we don’t want to be prompted at boot time for a password. And of course we can’t afford to crypt our data with a randomized key, changing at every boot !

What we want is the encryption to be done at log-in time, without prompting the user for another passphrase. Don’t we have enough passwords to memorize to add one more !?

We are going to use PAM, the Linux authentication mechanism, with its libpam-mount module. It is designed to mount some devices while the user log in, exactly what we need ! The user Linux password will be used as the encryption passphrase.

Of course, the security level will depend on your user password – take a good care on its length and complexity (though it must be already the case, encryption or not). A good compromise is probably an 8 digits password. Of course, if you are looking for the top level security, prefer the boot time passphrase prompting method…

To activate it, create or edit the /etc/security/pam-mount.conf.xml file and add this line :

<volume fstype="crypt" path="/dev/hda3" mountpoint="/home" />

Also add this at the end of the /etc/pam.d/common-auth file :

# cryptsetup
auth    optional        pam_mount.so use_first_pass

That’s done ! Testing is easy : log off, log in and check that your /home partition is well monted. It should not been mounted or readable for other users, including root.

Encrypting a removable device

We assume that you have a usb key (once again BACK UP your data) inserted, corresponding to the /dev/sda device :

$ cryptsetup luksFormat -c aes-cbc-essiv:sha256 /dev/sda1

We open manually the luks partition :

$ cryptsetup luksOpen /dev/sda1 usbkey

We format it with the filesystem of your choice (here ext3) :

$ mkfs.ext3 /dev/mapper/usbkey

We close the partition :

$ cryptsetup luksClose usbkey

Now every time you insert the key, you will be prompted for the password (at least by Gnome through the keyring manager box, though I haven’t tested yet with a different window manager).

Conclusion

This was a much easier experience than I previously thought. Much work has been made to hide the complex layers behind that, and it now takes only a few steps to get a pretty well secured hard drive.

However I think it really must become more user-friendly for the masses. Most of people will still be scared to open a terminal and type the commands above, so I am looking forward to seeing some graphical front-end to manage all that. Sure there are coming, and if you already know some project, please let me know.

About performance, if encryption must have a resource cost, I could not notice any slow down on a pretty modest hardware (celeron M 1,5 Ghz).