Secured systems with Fedora Linux
- What we will do
- Techniques used
- Creating an encrypted container for your home directory
- Installing pam_mount
- Configuring pam_mount
- The Test
- Encrypted partitions
- Making it even more secure - USB dongles
- Securing other parts of your computer
- Cleaning up
- Encrypt everything!
Beware! I wrote this manual with best intentions, but I cannot (and I will not!) guarantee that it works. In worst case your data will become hidden from everyone, even from YOU. And there will be no way to recover it - at least not in next few years.
So - before you begin - make a backup and copy it to at least two different, independent places.
If you're in doubt - don't use it.
This document should give a short intoduction and description about creating encrypted filesystems on Fedora 3/4/5/6/7/8 Linux. Why only Fedora? Because this is the distribution I use. Many details in this description are applicable to any distribution, some depend on automation provided by Fedora. Read it, understand it, and if you've seen a better description or adapted this one for another distribution, write me an e-mail. I'll be happy to place a link to your page.
I would like to thank Steven Elliott for his suggestions and remarks according Fedora 3 (namely losetup) and its weaknesses within password processing along with his note about the disadvantages of ECB compared to CBC.
If you use encryption it is most important to understand how it works. Using encryption without understanding the underlying mechanism can easily lead to an insecure configuration which is the opposite of our goal. This document is not an introduction to encryption issues. If you look for such a document, have a look at
What my goal is? Well, in the end it should be a setup you can apply, for example, to your notebook to secure critical data stored there. It won't prevent anybody from stealing it, but it probably prevents everyone who cannot guess a randomly created 64 byte number from reading your data.
Every new ATA hard disk supports password protection. Many notbooks can use this feature to secure the hard disk, some desktop PCs can use it, too. You should use this option if it is available, because if you don't set a passwort some virus might do it for you - and you'll loose your data.
The hard disk password protection does not provide any encryption! Professional data recoverer can reset this password and your data will be readable again! Take it into consideration if your data is worth more than 500-1000 €.
There are also some hard disks in sale which provide real encryption, using AES (or another) algorithm. They have some advantages.
- Encryption/decryption is done in hard disk hardware, so it does not burden your CPU.
- Everything is encrypted, even the operating system. For a potentional thief the data stored on the hard drive is completely inaccessible. But he can still reset the password and use the disk for his purposes.
- It's very easy to set up and use.
There are also some disadvantages.
- You have to rely on a password, which can be weak.
- Those hard drives usually are slower than those without encryption.
- In a multi-user environment every user has to know the password. Any secret known by more than one person is not a secret any more.
- You have to rely on the manufacturers word that his encryption algorithm is strong (i.e. AES) and his implementation of the algorithm has no security holes.
- You have to rely on the manufacturers word that he does not store your plain text password secretly anywhere on the hard drive.
Of course you can combine both methods and set up additional encryption as described below. The hard drive does not care about it.
What we will do
All encryption described in this document will be done transparently. Your login password will become the key to your encrypted data.
We will create an encrypted container for your home directory, an encrypted partition for your data, encrypted swap-partition and encrypted /tmp-Partition. Why swap? Because any password you enter is present in your computers memory and the computers memory can be swapped to disc. And why /tmp? Well, because some programs store data there, which can contain information you'd like to protect.
Which constraints do you have to face?
- One thing is: you probably won't be able to use suspend-to-disc feature - at least not unless someone tweaks my scripts. This is not really a disadvantage, because if you do suspend-to-disc, your computer's memory will be stored unencrypted on your hard disc - and become readable to potential attackers. I wrote "probably", because nower days there might be a way to do it - suspend-to-disc with encryption support. I did not have the time to try out.
- Another point: you cannot use public key authentication for SSH logins the first time you login to your machine. The pam_mount module needs a password to decrypt your data. Besides, you private key is not available until you provided a passwort and your home-container has been mounted...
Almost all of the used technologies are part of the Fedora 3/4/5/6/7 distribution, namely
- cryptoloop (kernel module)
- cryptsetup (frontend to dm-setup)
- udev (automated device creation)
- hal (hardware abstraction layer, creates mountpoints)
- OpenSSL libs to encrypt/decrypt keys
- pam_mount (since Fedora 5)
If you use Fedora 3/4 then the only thing not included - but highly critical - is the pam_mount module. It's needed do decrypt your data the time you login.
Creating an encrypted container for your home directory
Some command lines became too long for a single line, so I had to split them in two or more lines. If you see a backslash „\“ at the end of a line, then it was splitted. You can enter the command without the trailing backslash and without any linebreaks.
The container will be mounted just on time when you login into your computer. First you need to guess, how big your home should become. For the sake of this example I'll assume it should be 1 GB in size and that we create it for the user alice.
- The following command will create a 1 GB(=1024 MB) big file.
dd if=/dev/zero of=/home/alice.img bs=1M count=1024It will fill the file with zero-bytes. Theoretically it will be possible to see how much data you've written to the encrypted container once we had set up encryption, since space, which has not been used yet will containt zero-bytes. It might allow further conclusions for cracking your encryption. We will fix it later, filling up the encrypted container. This way is much faster than using /dev/urandom, about a factor of 3 to 5.
Don't use /dev/random! It will be painfully slow and it will suck out all the precious entropy from your system.
- Now we will create the key for your encrypted system.
The key consists of random bytes we will obtain from /dev/random (Yes! In this case we will use the „real“ random device.) and we will encrypt it with Alice's login password. Why so complicated? Because once we have encrypted the container file it will be impossible to change the key. Changing the the encryption key itself always needs a complete re-creation of the encrypted filesystem. In our example Alice can re-encrypt her key with a new password as soon as she changes it. Since losetup cuts the password right after the first line feed (character #10), carriage return (character #13) or null byte (#0), we delete those characters from our random data. They are given in octal notation for tr. (10=128, 13=158) Note also that losetup which is delivered with Fedora 3 has fixed length for passwords, which is limited to 32 characters. (The last one is string terminating zero byte.)
dd if=/dev/random bs=1 count=100 | tr -d '[\000\012\015]' | dd bs=1 count=32 | \ openssl aes-256-cbc > /home/alice.keyopenssl will prompt for a password. You have to enter Alice's login password for it. You should prefer aes-256-cbc to aes-256-ecb because ECB is not immune against pattern analysis. (see Block cipher modes of operation on Wikipedia.) The size of 31 bytes and banning the occurence of two bytes from the random key results in 25431 = 354.686.954.453.278.359.061.805.698.684.302.173.197.461.176.719.
822.024.722.259.610.724.051.451.904 ≈ 354×1072 possible keys. Make sure Alice owns her key-file and that she's the only one who can access it:
chown alice /home/alice.key; chmod 600 /home/alice.keyAnd now copy this damn key to at least one another secure location, like a floppy or CD and hide it in a safe place. It might be the last chance to recover your precious data. You have been warned!
You might encrypt it with OpenGPG for example (using a much more sophisticated password that the one for login, of course) and place it anywhere.
- Now we will prepare the container file alice.img to be used as easily as any other partition in your system. From this point we need encryption provided by the kernel. Make sure the needed modules are loaded.
modprobe cryptoloop modprobe aesPut the these lines at the end of your /etc/rc.d/rc.local file. It will ensure those modules will be loaded after reboot. The next command access alice.img through the loop-back device using encryption with the previously generated key. Replace the X with 0 on the first try, increasing it if you see errors of files already being used.
openssl aes-256-cbc -d -in /home/alice.key | \ losetup -p0 -e aes-cbc-256 /dev/loopX /home/alice.img
- To store any data in Alice's container, we have to create a filesystem on it. („format it“ in the Common Tongue of Redmond's Followers). All access must happen through /dev/loopX which will encrypt any data written to it an decrypt data read from it. The option -m 0 tells mke2fs not to reserve any space for administrative purposes and -L /home/alice sets the „label“ for the filesystem.
mke2fs -m 0 -L /home/alice /dev/loopXWe do not need the loopback device any more and can free it.
losetup -d /dev/loopX
- Now everything is ready to be used. We have to rename Alice's home to something different, create new home directory for Alice - which can belong to root, because as soon as the container file will be mounted on Alice's home, its access rights will overlay those of the home directory.
mv /home/alice /home/alice-insecure mkdir /home/aliceWe have to mount the new container on Alice's home:
openssl aes-256-cbc -d -in /home/alice.key| \ mount -p0 -o loop,encryption=aes-cbc-256 /home/alice.img /home/aliceWe have to set the access rights to it correctly.
chown alice:alice /home/aliceAnd now we can copy Alice's data to her new home:
tar cp --atime-preserve -C /home/alice-insecure -f - .| \ tar xvp --atime-preserve -C /home/alice -f -We could also use the simple copy command cp, but it not that easy to let it copy the dot-files, too.
- Now for the security issue mentioned first. We heave to fill up the container entirely, to make sure there are no zero bytes left. The most simple way to do it is to create a file containing zero bytes in Alices' encrypted home and delete it afterwards.
dd if=/dev/zero of=/home/alice/some_file_that_does_not_exist bs=10M rm -f /home/alice/some_file_that_does_not_exist
- We're finished. Alice's data has been copied to the encrypted container. Now we can unmount it and proceed with the pam_mount setup.
For all following steps I will assume they are executed as user root.
It is very easy. Use
yum install pam_mount
That's all, since pam_mount is now part of the Fedora distribution.
The pam_module can be obtained from http://pam-mount.sourceforge.net/. You can get it as a tarball or a RPM package, which should be sufficient for a Fedora system.
At least with Fedora 4 you have to link mount.crypt and umount.crypt from /usr/bin to /sbin after the installation because it is the only place the mount command searches for helper scripts.
If you want to compile pam_mount on Fedora yourself, you probably will face a compile error message about old kernel headers. This is right. The kernel headers included in Fedora are really old - at least they were at the time I wrote this article. To fix it install the package kernel-devel and copy (or better: link) at least those files from /usr/src/kernels
/usr/include/asm/posix_types.h -> /usr/src/kernels/YOUR_KERNEL_VERSION/include/asm/posix_types.h /usr/include/linux/loop.h -> /usr/src/kernels/YOUR_KERNEL_VERSION/include/linux/loop.h
Installing a RPM package is pretty easy. Just type in
rpm -ihv my_package_name.rpm
and watch it being installed. If you prefer the tarball - well, there is a document describing the install procedure inside the tarball.
After pam_mount has been installed, it must be configured. The main configuration file is /etc/security/pam_mount.conf There is a sample config file included in the pam_mount-package. Copy it to the named directory. There are plenty of comments inside the configuration file, which describe all possible options.
For every volume which shall be mounted you need an entry in pam_mount.conf For Alice this line does the job:
volume alice ext2 - /home/alice.img /home/alice loop,encryption=aes-cbc-256 \ aes-256-cbc /home/alice.keyIt informs pam_mount that every time user alice logs in, it should perform a local mount using the ext2 filesystem, using no server (it's logical for a local mount...), mounting the file /home/alice.img on /home/alice using loopback-device and AES encryption; the key to the encrypted container is encrypted with the aes-256-cbc algorithm and it is stored in /home/alice.key.
Now there is only one thing left: you have to tell your PAM-system to use the pam_mount module. All configurations files for PAM can be found in /etc/pam.d, which is our next base directory.
Generally it's not a good idea to include pam_mount in every config file. The config files important for pam_mount are:
This one takes care only of the text console login! If you change neither the kde nor the gdm section, you simply won't be able to log on the graphical console.
This takes care of the KDE login manager, called kdm.
The same as above for the Gnome login manager.
For some reason the login fails, if pam_mount is not the first auth module.
pam_mount: error trying to retrieve authtok from auth code
I had to reorder the PAM entries. pam_mount.so has to be the first module in the PAM stack. In general pam_mount has to be the first auth module and you have to provide the option use_first_pass the system-auth include like this:
auth optional pam_mount.so ... auth include system-auth use_first_pass
Here are examples of my login, kdm and gdm files. (Fedora 7)
#%PAM-1.0 auth optional pam_mount.so auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so auth include system-auth use_first_pass account required pam_nologin.so account include system-auth password include system-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session include system-auth session required pam_loginuid.so session optional pam_console.so # pam_selinux.so open should only be followed by sessions to be executed in the user context session required pam_selinux.so open session optional pam_mount.so session optional pam_keyinit.so force revoke session optional pam_ck_connector.so
#%PAM-1.0 auth optional pam_mount.so auth include system-auth use_first_pass account required pam_nologin.so account include system-auth password include system-auth session optional pam_keyinit.so force revoke session optional pam_mount.so session include system-auth session required pam_loginuid.so session optional pam_selinux.so session optional pam_console.so
#%PAM-1.0 auth required pam_env.so auth optional pam_mount.so auth include system-auth use_first_pass account required pam_nologin.so account include system-auth password include system-auth session optional pam_keyinit.so force revoke session optional pam_mount.so session include system-auth session required pam_loginuid.so session optional pam_console.so
In each of the files mentioned above add this line just after the pam_nologin.so module in the auth-section:
auth optional pam_mount.so use_first_pass
It will get the password which already has been provided to a previous module and store it for further use. As next step, add a second line to every file mentioned before, just before the pam_stack.so module in the session-section.
session optional pam_mount.so
It will actually do the mount using the password it got in the auth-section.
Now is the time to test everyting. Let Alice login to the computer. A console login is enough for the first test. Console is the text-login you normally get by pressing Ctrl-Alt-F1. If everything is set-up properly the encrypted container will be mounted on /home/alice and Alice should have access to all her data.
What if it didn't work? Well, first activate the debug option in /etc/security/pam_mount.conf and try to login again. Now you see which steps pam_mount takes and in which step it fails. Read the pam_mount documentation. If you still can't get an idea why pam_mount fails, write me an e-mail - but no sooner.
|All data on the partion will be lost. There is no way you can encrypt the partition without destroying the filesystem on it.|
Caution! I noticed a very strange behaviour since Fedora 7. One of my encrypted partitions cannot be mounted, because cryptsetup produces a wrong key from my password. On another encrypted partition everything works as usual so I am really buffled by this difference. I have no explanation, at least not now.
This key issue has been fixed with a cryptsetup-luks update to version 1.0.5-4, as for now available in the updates-testing repository.
You can apply the method described above to create at most 128 encrypted container files which will be mounted using loopback devices. Although this method is also applicable to hard drive partitions, there is a better way: use the mapper device.
It is possible to setup an encrypted partition using dmsetup directly. It's possible, but it's no fun. A better solution is cryptsetup, which provides some automations making it very easy to create an encrypted filesystem. This tool is now quasi official file system encryption interface for Linux.
For the sake of this example I will assume that we want to create an encrypted partition on /dev/hdb1, that it should be mounted on /data and that Alice will have the key to this partition.
- As in case of container files we will not overwrite the partition with random bytes but fill the encrypted partition with zero bytes later.
- Create a key for your partition as described above. As a reminder, here's the command:
dd if=/dev/random bs=1 count=100 | tr -d '[\000\012\015]' | dd bs=1 count=64 | \ openssl aes-256-cbc > /home/data.keyNote, that also here we will delete all occurrences LF, CR and zero bytes from the random password. This must be done because the hashing function stops reading the remaining characters from the password after the first occurrence of one of those characters.
Make sure the keyfile belongs to Alice and only Alice can access it.
This key should also be stored in at least one more secure place. If you don't and loose your key due to an hardware error - say your data good-bye.
- Now we will initialize the encryption layer using previously generated key:
openssl aes-256-cbc -d -in /home/data.key | \ cryptsetup -c aes-cbc-essiv:sha256 create data /dev/hdb1It will create a block device /dev/mapper/data which represents the encryption layer to /dev/hdb1.
- Let's create a filesystem! You can choose any filesystem, but journaling filesystems are not recommended. So in practice, there is only one choice: ext2. To create an ext2 filesystem use:
mke2fs -L /data /dev/mapper/dataRight now, we're done and can delete the encryption layer
cryptsetup remove data
- We have to announce our partition in pam_mount. Append this line to /etc/security/pam_mount.conf:
volume alice crypt - /dev/hdb1 /data cipher=aes-cbc-essiv:sha256 aes-256-cbc /home/data.keyEverytime Alice logs in the mount.crypt command will be executed (which reads the key, invokes cryptsetup and mounts the partition), using no server (it's still a local mount...), mounting /dev/hdb1 through an encryption layer on /data; the partition will be encrypted with the AES algorithm.; the key is encrypted with aes-256-cbc algorithm and stored in /home/data.key
- Let Alice log in. pam_mount should create an encryption layer to /dev/hdb1 named /dev/mapper/_dev_hdb1 and mount it on /data. As soon as Alice logs it, the partition become accessible to everyone who has the proper rights - and of course root. Change the access rights to match your needs. For the beginning
chmod 1777 /datashould do the job. It allows everybody to write to this partition, but you must be the owner of a file to delete it. For example /tmp has the same rights.
- Copy the data you want to protect to /data.
- Now we will fill up the partition to erase any unencrypted information which might still be there and to hide which parts of your disk contain encrypted information and which do not. This kind of information can help to crack your encryption. Simply fill /data with zero bytes.
dd if=/dev/zero of=/data/some_file_that_does_not_exist bs=10M rm -f /data/some_file_that_does_not_existGet some coffee. This will need some time, depeding on the free space and your CPU power...
Making it even more secure - USB dongles
A german proverb says: „Even a blind chicken sometimes finds a grain.“ If an potential attacker can guess Alice's login password he can decrypt her keyfiles and use them to decrypt the container files or partitions. And it is much easier to guess a login password correctly than to guess a 64 bytes number. In a password one hardly uses more than 20 characters and can only use characters on the keyboard, which are only a subset of all available values.
The solution is to store the key-files separately, on a removable medium. It does not have to be a USB stick. Anything can be used: a floppy, CD-R, SD memory card, SmartCard, PDA, digi-cam or even a mobile phone. I'll describe the procedure for USB sticks because they are small, cheap and „omnipresent“.
The procedure described here can vary between different distributions - even between different versions of the same distribution. On Fedora, thanks to hal, mountpoints for USB sticks are automatically created, so the only thing we have to do is to mount the USB stick when it's plugged in.
The creations of encrypted container files or partitions does is not affected and can be performed as described above. The only difference is: the key-file should not be stored in /home/some_file.key but on directly on the USB device. You have also to adapt the paths to your keys in /etc/security/pam_mount.conf.
For the sake of this example I'll assume the USB-Stick has a labeled vfat partition on it and the partition's label is „USB“.
New Fedora versions no longer make changes to the fstab, but delegate the mounting of external media completely to HAL. You have to use additional tools to call the appriopriate HAL methods. Sophisticated graphical desktop managers, like KDE or GNOME make it very easy, but at the time when the stick is plugged in, we have no graphical support at all. We have to use the command line tools, for example gnome-mount.
We use the following file to tell HAL, which USB device to mount and how to do it. Put it in /usr/share/hal/fdi/policy/20thirdparty/90-dongle.fdi
<?xml version="1.0" encoding="UTF-8"?> <!-- -*- SGML -*- --> <deviceinfo version="0.2"> <device> <match key="volume.label" string="USB"> <append key="info.callouts.add" type="strlist">dongle-mount</append> </match> </device> </deviceinfo>
The previus rule calls the script dongle-mount every time the USB stick is plugged in. Put dongle-mount into /usr/lib/hal/scripts (or /usr/share/hal/scripts on Fedora 5). Here is what it might look like: (500 is Alice's UID)
#!/bin/sh if [ $# == 0 ]; then nohup $0 $HAL_PROP_BLOCK_DEVICE >& /dev/null & exit 0 fi tries=0 while [ $tries -lt 5 ]; do su alice -c "/usr/bin/gnome-mount --text --no-ui --device $1 --mount-options=shortname=winnt,uid=500" && break tries=$(($tries+1)) sleep 2 done
And now to an exaggerated security issue of Fedora. It will not allow an ordinary user to mount a device, unless he is logged in. That a little bit of a vicious circle because we need the device to be mounted in order to log in. We have to allow Alice (or even everybody) to mount media, even if they are not logged in. Put the following rules into /etc/dbus-1/system.d/dongle-mount.conf. Replace 500 with Alice's user ID or with an asterisk (*) to allow everybody devices' mounting.
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"> <busconfig> <policy user="500"> <allow send_interface="org.freedesktop.Hal.Device.Volume"/> </policy> </busconfig>
Fedora 7 only
Fedora 7 has introduced a new tool called ConsoleKit-Manager. It keeps track of user sessions. Unfortunately it messes up this mounting procedure. I found no other solution but to disable the ConsoleKit support in HAL. This means recompiling HAL. If you don't you will be faced with a message about beeing not in a active session:
** (gnome-mount:32736): WARNING **: Mount failed for /org/freedesktop/Hal/devices/volume_uuid_8658_2213 org.freedesktop.Hal.PermissionDenied : Permission denied: Not in active session
Either you rebuild you hal yourself disabling ConsoleKit support, or you can use my packages. I try to keep up with coming updates but I cannot not guarantee it.
Fedora 8 only
To allow mounting your dongle even if no one is logged in, you have to tell it PolicyKit. Look for a file named /etc/PolicyKit/PolicyKit.conf and insert the following lines into the <config> block.
<match action="org.freedesktop.hal.storage.mount-removable"> <return result="yes" /> </match>
No HAL patching any more...
Consider it a historical supplemental. We have to define a HAL rule, which matches our device and call a script from it, which mounts the device. The HAL rules in /usr/share/hal/fdi/policy/20thirdparty/90-dongle.fdi might look like this.
<?xml version="1.0" encoding="UTF-8"?> <!-- -*- SGML -*- --> <deviceinfo version="0.2"> <device> <match key="volume.label" string="USB"> <append key="info.callouts.add" type="strlist">/usr/local/sbin/dongle-mount</append> </match> </device> </deviceinfo>
and /usr/local/sbin/dongle-mount might look like this.
#!/bin/sh declare -i i i=0 while [ $i -lt 10 -a ! -d /media/USB ]; do sleep 2 i=$(($i+1)) done su alice -c "mount /media/USB"
hal calls a bunch of programs in /etc/hal/device.d every time a HAL event takes place, such a adding or removing a USB device. We simply add a script there, which will mount the USB stick for us.
#!/bin/sh if [ "$1" = "add" -a "$HAL_PROP_VOLUME_POLICY_DESIRED_MOUNT_POINT" = "USB" ]; then su alice -c "mount /media/USB" fi
If the script is executed with the argument add (HAL does it for new devices) and there is an environment variable HAL_PROP_VOLUME_POLICY_DESIRED_MOUNT_POINT with the value USB (HAL sets many environment variables) then the mount command is performed - as user alice. This makes it possible for Alice to unmount the USB device later. If we did not use the su command, the USB device would have been mounted by root and only root would be able to unmount it. That's a little bit annoying.
In theory this script can be much more sophisticated. It could check if Alice had already logged in and it this case decide not to mount the device. It could use other HAL information to guess the mountpoint more exactly, because it doesn't have to be the label of the device. Or it could additionally add a symlink to the directory if you would like to use more than one USB device and store your keys on every one of them. Feel free to enhance it.
Securing other parts of your computer
Securing your home directory and some partitions on your computer is only the first step. Computers are very generous if it comes to data storage. Modern machines use several levels of caching, memory swapping and temporal disk space. It is almost sure that any document you're working with will be swapped from RAM to the hard disk on some stage and many programs store temporal data in the /tmp directory, without asking your permission to do so - which is really good, because working with computers would be very frustrating if you had to decide every little detail.
There are several possibilities to solve this problem. One is called tmpfs. In general, it mounts the /tmp directory in memory (like a ramdisk) and swap-space.
Well, the distribution makes the daily life very easy. All you need is a file /etc/crypttab. There you can tell your system to create block devices cryptoswap/cryptotmp on the specified partitions. It will read the key from /dev/urandom and encrypt with the given algorithm. It will also create a swap/ext2 filesystem on the partitions
# /etc/crypttab cryptoswap /dev/sda1 /dev/urandom cipher=aes-cbc-essiv:sha256,swap cryptotmp /dev/sda9 /dev/urandom cipher=aes-cbc-essiv:sha256,tmp
Now you have to correct the paths for the swap and /tmp partitions in /etc/fstab pointing them to /dev/mapper/cryptoswap and /dev/mapper/cryptotmp repectively.
On the next reboot your swap and /tmp should be encrypted and mounted automatically. Check it with
dmsetup table cryptoswap --showkeys
It should show you the ecryption settings for cryptoswap/cryptotmp along with the used key
I want to propose a different solution. I will use the device mapper and encrypted partitions created at boot time.
Attention: There is a booby trap I've encountered on FC4 and FC5. At boot time they try to reinitialize their random number generator which leads to an apparent system freeze. You have two solutions for this problem.
- Move your mouse or hit some keys to feed your random number generator. At some point it will gain enough random data to proceed with generation of encrypted swap and /tmp partions.
- Comment out the following line in /etc/rc.d/rc.sysinit
dd if=/dev/urandom of=/var/lib/random-seed count=1 bs=512 2>/dev/null
Encrypted swap partition
Because we do not care what the previous content of our swapfile was and because we do not want to restore it, we do not have to create and save encryption keys. We will use a random key.
I've written an init-script called cryptoswap, which does the job. Copy it to /etc/rc.d/init.d and make it executable.
cp cryptoswap /etc/rc.d/init.d chmod 755 /etc/rc.d/init.d/cryptoswap
Because this script takes care of creation and activation of the swap space, you have to comment out all swap entries from /etc/fstab you want to be handled by cryptoswap. Important note: Right now, this script can only deal swap partitions. It cannot encrypt swap files. I'm working on it.
To test this script first close all your applications. Become root on the text console and go to so-called single user mode by typing
Look which swap partition are active. On a typical computer there will be only one active swap space.
Deactivate every swapspace you want to be handled by cryptoswap
Now is the time to erase your swap partition. You can skip this step - but you should not do it. Look above for explanation.
dd if=/dev/urandom of=your_swap_partition
Put the partitions you want to be used for swapping in a textfile /etc/sysconfig/swaps, one partition in each line. Now you can start cryptoswap.
service cryptoswap start
It should create an encrypted device using cryptsetup, write a swap filesystem on it and activate it. You should see familiar entries in /dev/mapper and
should show you active swap partitions on /dev/mapper-something. If everything worked just fine, you can add cryptoswap do your start scripts. This way your swap partition will be encrypted every time you boot your machine.
chkconfig --add cryptoswap
Encrypted /tmp will be set-up exactly in the same way as the encrypted swap space. The only difference is: there is only one /tmp directory in the system's tree, so the partition on which the encrypted filesystem will be created has to be configured in the cryptotmp script directly.
As before, we do all changes in the single user mode.
Now to have to unmount your active /tmp partition.
If this command exits with an error message about the directory being used, you can find out which process is blocking it with
After you've done this, comment out the line in your /etc/fstab which refers to it. Now you should copy the cryptotmp script to /etc/rc.d/init.d and make it executable. Edit it and change the value of TMPDEV to the partition of your /tmp-directory. We are almost ready for the first run. We should erase the partition first
dd if=/dev/urandom of=your_tmp_partition
Now start it with
service cryptotmp start
If there were no errors you can add it to your start scripts permanently
chkconfig --add cryptotmp
After all of your data has been transfered to an encrypted container or partition and deleted from its previous position there is one last thing to do: clean-up the unencrypted partitions!
When you delete data on your hard disk, all references to its position are removed and the physical space where the data is stored is marked as „free“. This method is also called a weak delete. But the data itself has not been removed yet and it can take some time until the same physical space will be assigned for other data again. In the meanwhile you data can be restored by someone with some technical ability.
A reasonable method for erasing this data is for example creating a big file which entirely fills up the free space and contains random bytes. This file can be deleted later on. Make sure you do it as the superuser because many filesystems - such as ext2 and ext3 - reserve some space (3% per default) for the superuser. In reference to the first example (encrypted container file for alice), here is how to „clean-up“ the /home partition.
dd if=/dev/urandom of=/home/cleanup-file rm -f /home/cleanup-file
Yes, it's possible. No, I won't do it.
Theoretically, your system is still vulnerable. If a bad guy has access to your hard drive he can install a root kit or a keyboard-logger and this way compromise your security. To prevent it one can encrypt everything, including the operating system itself. But it's tricky. And there must always be a last, unencrypted part of your system, from which your computer can boot.
To secure your operating system there is another cryptographic technique, besides encryption - digital signing. Search the net for a tool named tripwire.
- cryptsetup homepage
- How to use smart cards for encryption and authentication, by Jari Eskelinen
- dm-crypt'ed homes with pam_mount from Gentoo Forums
- http://pam-mount.sourceforge.net/, new home of pam_mount.
- Encrypted homes sometimes are not unmounted correctly after logoff when using X and produce an error on shutdown.