LUKS is a hard disk encryption standard for Linux created by Clemens Fruhwirth. Althought the reference implementation is based on dm-crypt, it has several improvements over plain dm-crypt (as seen in the third post in this series), including support for multiple keys and passphrase revocation.

To use LUKS you’ll need a recent cryptsetup package (Debian sarge users can get it from backports.org). You will also need an empty partition to encrypt. You should fill it with random data before beginning:

$ shred -v /dev/hdaX

Now you have to initialize that partition with LUKS:

$ cryptsetup luksFormat /dev/hdaX

A random key will be generated and you will be asked a passphrase to encrypt it. Now you can decrypt your newly created LUKS partition and begin to use it:

$ cryptsetup luksOpen /dev/hdaX myname

Here, myname is the name of the device that will be created under /dev/mapper. Now it’s time to create a filesystem:

$ mke2fs /dev/mapper/myname

Now you can mount and use /dev/mapper/myname just like any other filesystem. When you’re done, unmount it and close the LUKS device so it won’t be accessible anymore until you open it again:

$ cryptsetup luksClose myname

So far so good, but how do you mount that partition automatically on boot? Just put this in your /etc/crypttab (and don’t forget to add /dev/mapper/myname to your /etc/fstab file!):

myname    /dev/hdaX    none    luks,check=ext2

myname is the encrypted device that will appear under /dev/mapper and /dev/hdaX is the original device.

The third field, none, means that the key to decrypt the filesystem is not stored anywhere, so cryptsetup will ask you during boot.

The fourth field lists misc options: luks means that the partition is encrypted with LUKS format (as opposed to plain dm-crypt format). check=ext2 will make cryptsetup look for an ext2/ext3 filesystem on the decrypted partition. That way, cryptsetup will notice whether you introduced the right passphrase and ask it again in case you typed it incorrectly. There are several partition checks (not just ext2), and you can write your own scripts. Just have a look at /lib/cryptsetup/checks/.

And that’s all for the basic usage, but there are some other nice things that you can do, such as adding more valid passphrases to a LUKS partition:

$ cryptsetup luksAddKey /dev/hdaX

You can see some information about the partition (including the number of valid passphrases available):

$ cryptsetup luksDump /dev/hdaX

And obviously you can remove any passphrase:

$ cryptsetup luksDelKey /dev/hdaX slot

Where slot is the number of the key slot you want to remove (you can see it with luksDump).

And that’s enough by now. As you can see, it’s not that hard to keep your data secure. Keep in mind, however, that encrypting a whole partition introduces some extra overhead, so your system will be slower. You don’t have to encrypt everything (i.e. under /usr you probably don’t have any confidential data). Choose wisely and enjoy!.

So far we have mentioned some tools to easily encrypt files. Keeping files encrypted is a good way to protect your data in case someone steals them.

However, if we’re talking about serious encryption, just encrypting files is not enough to keep your data protected. There is no use in having a secured document in your hard disk if the program you use to open it stores some of its contents in /tmp. And that’s not the only risk. Maybe your program keeps passwords always in memory and it does not store them on disk, but what happens if you run out of memory and all of your passwords go to the swap partition? If someone steals your hard disk, she could easily get them with a disk editor.

There are many ways to encrypt entire partitions in Linux, and there are many kinds of partitions that should be encrypted, but swap and /tmp are two important ones and arguably the easiest to set up. Both share a common feature: they store temporary data. Once the computer is turned off, all stored data is no longer important, so it can be discarded.

In this example we’ll use dm-crypt to set up these encrypted partitions. You need to enable CONFIG_DM_CRYPT in your kernel configuration and install the cryptsetup package (if you’re using Debian sarge, it’s highly recommended to install cryptsetup 1.0.x from backports.org).

Once installed, put this in your /etc/crypttab:

cswap    /dev/hda5      /dev/random    swap
ctmp     /dev/hda6      /dev/random    tmp

The first field is the name of the device that will be created (under /dev/mapper) to access the encrypted partition.

The second field is the real partition that will be encrypted.

The third field is the file where the key to encrypt the partition is stored. In this setup, that file is /dev/random so each time the machine boots partitions will be encrypted with a different key chosen randomly. So the data will not be recoverable if you turn off the PC. But that’s what we want, isn’t it? 😉

The fourth field list misc options for cryptsetup. Here, swap will run mkswap on the device and tmp will run mke2fs.

To mount these partitions, your /etc/fstab should contain these lines:

/dev/mapper/cswap    none    swap    sw         0   0
/dev/mapper/ctmp     /tmp    ext2    defaults   0   2

Last but not least, before using this system you should erase the contents of the partitions completely. The recommended way is to fill them with random data (but unmont them first!):

shred -v /dev/hdaX

Now each time you boot your machine you will have your partitions encrypted. That’s all folks!

Sometimes you don’t want to encrypt all of your files. You just have some important data you’d like to keep protected, but your other files are not confidential at all and you don’t care if someone steals your Firefox bookmarks or your .procmailrc.

In those cases encrypting a whole disk or even a single partition might be too complicated (you don’t want to mess with partitions), or it could make your system too slow. There are other alternatives. A classical approach is to encrypt your important files using a tool like GnuPG. While this method works perfectly, it’s not the most convenient approach when you have, say, dozens of different files to encrypt.

EncFS is a cryptographic filesystem that transparently encrypts a whole directory tree. Data is always kept encrypted in a regular directory within an existing filesystem, and you have to mount that directory using EncFS in order to see its contents. Thus, once mounted, encrypted files can be accessed through this virtual filesystem just like any other file: you can edit, copy, rename and erase them just like you would do with any other file.

One of the main problems of EncFS is that each file stored maps to an encrypted file, so even though the file names and contents remain protected, anyone with access to your hard disk can see how many files you have, the directory structure, the metadata and even the approximate size of each file. If that’s not a problem for your needs, EncFS is a good piece of software and it’s very easy to install, set up and use.

This post is the first in a series dedicated to disk encryption in Linux-based operating systems, namely Debian GNU/Linux 3.1 (sarge), but all these tips should be useful for other systems too.

As portable mass storage devices (such as USB flash drives, external hard disks or even laptops) are becoming more and more popular there’s a growing need to keep all this data secure in case a device is stolen (of course to keep your files secure you should also back up them, but that’s a different subject I will not cover here).

Disk encryption is a complex issue: there are plenty of encryption algorithms and disk format standards. New systems appear each year and old ones become deprecated. All these systems vary in speed, complexity, security and even stability. To put things worse, most disk encryption systems are not compatible to each other and are usually limited to one specific operating system.

There’s a wikipedia article about disk encryption software that can serve as a quick overview of some of the most popular systems available.

In this series of posts I’ll write about some of the most basic forms of encryption to cover the usual needs. I’d like to note that I’m not writing about user programs that encrypt files manually, such as GnuPG or some ZIP compressors. I’ll just cover methods that encrypt filesystems on the fly, that is, once set up you don’t need to care when you change your data: it will be encrypted automatically as you write it to disk.

I hope you’ll find these articles useful. Comments and criticism are welcome.

When printing a PDF file, Acrobat Reader creates a Postscript and sends it to the printer spooler (or, optionally to a file). Nothing new here, as it’s a common way for Unix programs to print files.

However, I found that under certain circumstances the Postscript file was corrupt: it could not be printed or opened with Ghostscript, because it showed instead an “undefined command” error.

Looking deeper into the problem I found that the corrupt file had its decimal numbers separated by a comma instead of a dot. The comma is the decimal separator in many locales, but decimal numbers in Postscript files must be separated by a dot.

Investigating a bit more I found that this problem shows when the Postscript file uses vector primitives, and that’s why the problem appears to occur randomly.

So the problem is that Acrobat Reader relies incorrectly on the locale settings to create a Postscript file. This should be a trivial bug to fix, but as Acrobat Reader is closed software you have to live with it if you want to use this software (fortunately free PDF readers are constantly improving).

There’s a quick workaround, however. As /usr/bin/acroread is really a shell script that lauches the real binary, you can add a export LC_NUMERIC=C at the beginning of the file and solve the problem. This bug is already fixed in some unofficial Debian packages.

Hope it helps.

User-mode Linux (UML) is a port of Linux to its own system call interface. In short, it’s a system that allows to run Linux inside Linux.

UML is integrated in the standard Linux tree, so it’s possible to compile an UML kernel from any recent kernel sources (using ‘make ARCH=um‘).

Traditionally, UML had a working mode which was both slow and insecure, as each process inside the UML had write access to the kernel data. This mode is known as Tracing Thread (tt mode).

A new mode was added in order to solve those issues. It was called skas (for Separate Kernel Address Space). Now the UML kernel was totally inaccessible to UML processes, resulting in a far more secure environment. In skas mode the system ran noticeably faster too.

To enable skas mode the host kernel had to be patched. As of September 2006, the latest version of the patch is called skas3. The patch is small but hasn’t been merged in the standard Linux tree. The official UML site has a page about skas mode that explains all these issues more thoroughly.

However, by July 2005 a new mode was added to UML in Linux 2.6.13 called skas0 (which, for some reason, isn’t explained in the above page). This new mode is very close to skas3: it provides the same security model and most of its speed gains. The main difference is that you don’t need to patch the host kernel, so you can use a skas-enabled UML in your Linux system without having to mess with the host kernel. The patch is explained in the 2.6.13 changelog or in this article.

A skas0-enabled kernel boots like this:

Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
Checking for tmpfs mount on /dev/shm...OK
Checking PROT_EXEC mmap in /dev/shm/...OK
Checking for the skas3 patch in the host:
  - /proc/mm...not found  
  - PTRACE_FAULTINFO...not found
  - PTRACE_LDT...not found
UML running in SKAS0 mode 
...