I’ve had to setup a laptop, and I thought I share the methods which I used to secure it, so that others can inspire themselves from it (to improve security of their mobile platforms) and/or tell me how I’m wrong 🙂

The general assumption of these steps is that the data on the laptop is much more valuable than the actual hardware, and if it would to get lost, the main objective is to deny access to the data stored on it from third parties. This of course must be coupled with a good backup strategy, even more so if we consider the fact that laptops are much more stressed as opposed to their desktop counterparts, which means that they have a higher probability of hardware failure.

The first step was to enable the hard-drive password in the BIOS. This prevents the laptop from booting until the correct password has been entered. The way it differs from the BIOS is that the password is stored in the hard-drive itself and you can’t access the data on it until the correct password is supplied, even if the hard-drive would to be moved to an other computer.

This is a good first measure and widely available on laptops for quite some time now. Unfortunately it is only a first step. The fact that it’s limited to 8 characters (at least with this BIOS) and that the actual data on the platters is not encrypted (meaning that somebody could disassemble the HD and use specialized tools to read the platters) means that it’s not very strong. Additionally there are commercial units out there which can remove any (eg. unknown) HD passwords in under two minutes (via the ITT podcast).

The second step was to partition the drive. It was divided up in 3 partitions: one for Windows XP, one for Linux and one Truecrypt volume (more on this later). First Windows was installed (as it f’s up any other non-MS OS if installed later) followed by Ubuntu. As I mentioned earlier, Ubuntu worked beautifully. Windows recognized at least the USB hub, meaning that I didn’t have to write a CD with the drivers, but I still had to lspci under Ubuntu to find out the actual hardware I had.

After that I disabled the wireless from the BIOS, because wireless connections are not common in this part of the world and this also makes the battery last a little longer (or at least is should). It also makes for good security.

Next I let Windows Update make it’s way trough the patch list (the install CD had already SP2 slipstreamed on it, so it wasn’t that long… In the meantime I changed the swapfile size to be fixed (this, besides providing a small performance boost, can help conserve free space as shown in the next step).

I downloaded the updates for Ubuntu (which, compared to XP, required only one reboot) and enabled NTFS RW support. Compared to older versions of Ubuntu, this was surprisingly simple. No package installation, no digging around in /etc/fstab, simply go to Application -> System Tools -> NTFS configuration tool and check Enable write support for internal devices. Voila!

Next I configured Ubuntu to use the swap file of Windows for its swap (normally, you would use a dedicated swap partition, however with smaller laptop HD’s this is a good way to save some space). You can do this by editing your /etc/rc.local and adding the following lines before the exit 0 line:

mkswap /media/sda1/pagefile.sys
swapon /media/sda1/pagefile.sys

A word of caution: this method should not be combined with hibernation in Windows. This is because during hibernation Windows relies on the fact that between shutdown and the next startup the contents of the swapfile are unchanged. However the laptop is primarily used in Ubuntu, so this is not a big problem.

Next the Truecrypt installation was completed: it got installed under both Windows and Linux, however the volume got created under Linux and formatted ext3. An additional driver was installed under Windows to make it capable of reading ext2/3 partitions.

The well known hosts file was installed under both Linux and Windows (there is an alternative, however I never tried it) along with Firefox, NoScript and Flashblock.

The windows setup also included:

• Administrative shares got disabled
• System Safety Monitor (the free version) got installed
• sudowin got installed and configured
• Software Restriction Policies got configured with default deny, and exceptions (allow rules) were added to the following paths:
  • The windows directory
  • The Program Files directory
  • The temporary folder (this is needed because many install programs first drop their components here and try to load/execute them from this location)
  • The start menu both for All users and the current users
• The privileges of the default user got dropped to normal user

In conclusion, this is quite a secure setup, as long as the user has the discipline to use the Truecrypt volume for anything sensitive. One possible source of leakage are the temporary files created during program operation which reside on the unencrypted partitions. An other possible leak could be collateral data stored on the unencrypted partition like browser cache or saved passwords. This could be prevented by installing the whole OS on an encrypted partition, which is supported in Debian, however I was lazy and used Ubuntu and Bitlocker in Vista. An other option would be to make the temporary folder private under Windows (using the EFS feature in NTFS), however this has some very nasty side effects, like installers failing inexplicably. My theory is that the problem lies in the fact that once a folder / file gets encrypted with EFS, only the given user and the Administrator can access it, and MSI installers run with the help of a background service, which is neither of these two accounts, meaning that it fails to access its own data files.