Virtual Filesystem

http://freshmeat.net/articles/view/1387/

by Mike Chirico, in Tutorials - Nov 27th 2004

Also available at http://linuxgazette.net/109/chirico.html

Latest Update: http://prdownloads.sourceforge.net/souptonuts/README_Virtual_FS.html?download Date: Tue Jun 14 11:45:52 EDT 2005

You can take a disk file, format it as an ext2, ext3, or reiser filesystem, and then mount it, just like a physical drive. It's then possible to read and write files to this newly-mounted device. You can also copy the complete filesystem, since it is just a file, to another computer. If security is an issue, read on. This article will show you how to encrypt the filesystem and mount it with ACL (Access Control Lists), which gives you rights beyond the traditional read (r), write (w), and execute (x) permissions for the three user groups "file", "owner", and "other".

First, create a 20MB file by executing the following command:

You created a 20 MB file because, by default, dd uses a block size of 512 bytes. That makes the size: 40960*512=20971520.

Next, to format this as an ext3 filesystem, you just execute the following command:

You are asked whether to proceed because this is a file, and not a block device. That is OK. We will mount this as a loopback device so that this file will simulate a block device.

Next, create a directory that will serve as a mount point for the loopback device.

Last step, find out what the next available loopback device number is. Normally, loopback devices start at zero (/dev/loop0) and work their way up (/dev/loop1, /dev/loop2, … /dev/loopn). An easy way for you to find out what loopback devices are being used is to look into /proc/mounts, since the mount command may not give you what you need.

I have no loopback devices mounted, so I'm OK to start with zero. You must do the next command as root, or with an account that has superuser privileges.

That's it. You just mounted the file as a device. Now take a look at /proc/mounts, you will see this is using /dev/loop0.

You can now create new files, write to them, read them, and do everything you normally would do on a disk drive.

If you need to umount the filesystem, as root, just issue the umount command. If you need to free the loopback device, execute the losetup command with the -d option. You can execute both commands as follows:

Next we start with ACL […]

http://www.linuxjournal.com/node/6481/print

By Mike Petullo Created 2003-08-01

Take advantage of loopback encrypted filesystems and pam_mount to secure your data.

When used correctly, encrypted filesystems can be an effective way to protect sensitive data stored on a computer. Standard encryption packages, such as the GNU Privacy Guard (GPG), are good for encrypting e-mail. They are not as convenient, however, for encrypting files one wishes to read or modify many times throughout the files' lifetimes.

Unlike GPG, an encrypted filesystem is transparent to users. There is no hassle of manually decrypting a file before reading it or encrypting it again after modifying it. Potential user forgetfulness also is mitigated. After introducing some encrypted filesystems available for Linux, this article explains how to create an encrypted home directory that is automatically mounted at login time and unmounted at logout. Finally, this article introduces some concepts that demonstrate the dangers of improperly implemented encryption techniques.

Why would one want to encrypt the data stored on a computer? Isn't protecting sensitive data what filesystem permissions are for? Although useful, filesystem permissions quickly lose their effectiveness when an attacker has complete control of the storage medium the permissions are used to protect. For example, if someone steals my Linux laptop, an Apple iBook, its filesystems permissions are of little use against the thief who can simply boot from a diabolical CD-ROM. The same is true if I send my laptop to Apple for repairs. A dishonest employee conceivably could read my files. Correctly encrypting the files on a computer is a safe form of protection, because the process does not depend on the integrity of the operating system after the encryption takes place.

I have chosen to encrypt only the home directories on my iBook. Encrypting the entire filesystem, starting with root, was not acceptable in my case due to performance penalties and other factors. Information on implementing this technique can be found on the Internet-it requires using Linux's initial ramdisk capability. In my experiences with an x86-based system, the encryption technique I chose is around 50% slower than a non-encrypted XFS filesystem when writing to disk using buffered I/O. Encrypting only home directories obviously leaves many files, such as system logs, as plain text, but these were not significantly sensitive in my case. Encrypting only home directories was a sensible compromise for me.

Linux supports a few options for encrypting filesystems. Systems such as the Transparent Cryptographic File System provide an encrypted extension to NFS-served ext2 volumes. Other filesystems contain integrated cryptography in their design for local use. For my application, the best solution seemed to be the concept of loopback encrypted filesystems. As you will see, loopback encryption can be used to encrypt any filesystem type supported by Linux, including the proven ext2, XFS and ReiserFS.

Linux loopback filesystem support simply allows a user to mount an ordinary file as if it were a device, such as /dev/hda1. This traditionally is useful for doing things like mounting a CD-ROM filesystem image to populate and test before burning it to CD-R media or distributing bootable floppy disk images. Herbert Valerio Riedel's GNU/Linux Cryptographic API (CryptoAPI) and util-linux patches add support for mounting encrypted filesystem images to the loopback driver.

Before delving into the details of loopback encrypted filesystems, let's take a look at how to create and mount a vanilla loopback filesystem. First, create a file to contain the filesystem. This example creates a file large enough to host a 20MB filesystem:

Second, associate the newly created file with a loopback device:

Next, create a filesystem within the file, using the newly associated loop device:

Finally, mount the filesystem and use it as if it were any other mounted volume:

Now, let us move on to the encrypted case. In order to use loopback encrypted filesystems, the kernel must support them. Most distributions do not include this functionality, so a custom-built kernel probably is necessary. A cryptographic API package similar to the one I use is being merged into the mainstream 2.5 kernel. However, for the stable 2.4 tree, the GNU/Linux CryptoAPI patches are necessary and available at www.kerneli.org [1]. Once you apply the patch-int and loop-hvr patches, Cryptographic options should be available when you configure your kernel. The following options must be enabled:

You have to enable at least one cipher as well. Remember which cipher you choose. I chose AES, originally called Rijndael, and use AES in my examples.

Build and install the newly configured kernel. All of the kernel's encryption code may be compiled as modules. If you choose to build kernel modules, don't forget to insert them before you try to use their functionality. It also is necessary to patch util-linux, compile the tools and install them. The relevant util-linux patch is available at www.kernel.org/pub/linux/kernel/people/hvr/util-linux-patch-int [2]. You should find that you end up with modified mount and losetup commands.

Now we are ready to create a loopback encrypted filesystem using a process similar to that which we used to create a vanilla loopback filesystem. First, in order to make it difficult to differentiate between encrypted blocks and unused disk space, the file that will hold the loopback filesystem is created using /dev/urandom instead of /dev/zero:

After creating the host file, it must be temporarily associated with a loopback device, as before. This time, however, we must tell losetup that the loopback device is to be encrypted, in this case with the AES cipher:

Enter the password and possibly-depending on the cipher you decided to use-the key size you wish to use for the volume when prompted by losetup.

Creating the filesystem is done in a manner identical to that for creating a vanilla loopback device. The encryption was set up in the previous step and is now handled by the loopback driver:

In addition to modifying losetup, the util-linux patch also makes the mount command crypto-aware. Mounting an encrypted loopback volume is a simple process, given the correct command parameters:

mount prompts you for a password and possibly for a key size.

Now that you understand how to mount and unmount encrypted loopback filesystems manually, an introduction to pam_mount is appropriate. pam_mount is a PAM module that simplifies the management of volumes and should be mounted when a user logs in to a system. It can handle mounting things like Samba-hosted volumes, Novell-hosted volumes and encrypted filesystems. The original author of pam_mount is Elvis Pfutzenreuter. Mukesh Agrawal wrote the patch that first added support for loopback encrypted volumes. The author of this article now maintains pam_mount, which is available at www.flyn.org [3].

Instead of having to mount encrypted volumes manually, a system administrator can configure pam_mount to mount and unmount the volumes automatically when users log on and off. This can be configured so the system password also unlocks the encrypted volume, essentially creating a completely transparent encrypted volume.

pam_mount can employ three different techniques to unlock an encrypted volume. The first technique is rather boring. When the encrypted volume's key is unrelated to the system's login password, pam_mount simply prompts users for the key to their encrypted volume. In order to use this technique on a system, pam_mount.so and pmhelper must be installed and configured. The standard ./configure, make and make install commands build and install pam_mount's binaries and configuration file.

You should find the stock pam_mount.conf in /etc/security. Inspect and tailor it to your own system. The stock pam_mount.conf file is well documented. The most important change necessary is to add definitions for the volumes that should be mounted to the end of the file. The following is the definition format for encrypted loopback filesystems, as documented in the stock file:

Here is an example that mounts an AES-encrypted loopback filesystem hosted by /home/mike.img at /home/mike when Mike logs on:

Next, add the lines auth required pam_mount.so try_first_pass and session required pam_mount.so try_first_pass to the configuration files of the PAM-supporting services you want to support loopback encrypted filesystems. As an example, here is the /etc/pam.d/login file from my laptop:

Finally, create the user's loopback encrypted filesystem using the steps listed in the introduction to encrypted loopback filesystems.

The second technique for pam_mount to unlock a volume is more convenient for users. If, when creating the encrypted volume using the same method as the first technique, a user specifies his or her login password as the volume key, then pam_mount unlocks the volume using the same password the user enters to login.

The third technique is the most flexible and requires a more sophisticated description. Here are a few terms to help you understand how this technique works:

pam_mount reads efsk from the local filesystem, performs fsk = D_sk (efsk) and uses fsk to mount the filesystem. This technique has the advantage of allowing users to change their login passwords without having to re-encrypt their home directories using this new key. If the login password is changed, simply regenerate efsk (that is, /home/user.key) using efsk = E_newsk (D_oldsk (efsk)). A script named passwdehd is included in pam_mount to do this for you.

To implement this third technique, begin by creating the file to host the encrypted filesystem (as before):

Then, create a file (efsk) containing the volume's password (fsk) using /dev/urandom, encrypted using the user's login password as the key:

Next, create an encrypted loopback filesystem. The filesystem's key should be fsk (generated using /dev/urandom, encrypted and stored as /home/user.key in step 2).

Finally, in pam_mount.conf, set the fs key cipher variable to the cipher used to encrypt fsk, in this case bf-ecb, and set the fs key path variable to efsk's path, in this case, /home/user.key.

In his definitive text, Applied Cryptography, Bruce Schneier states, "Software encryption is scary." What he means is, it is difficult to design truly secure encryption software for computers running general-purpose operating systems such as Linux. For example, modern operating systems can swap memory to disk at any time, and this memory could contain plain text or encryption keys. An encrypted volume is useless if its key has been written to disk by the operating system. One way to reduce the effects of this is to encrypt one's swap volume. CryptoAPI still cannot do this safely, but it is in development. A similar project, LoopAES, already can encrypt a system's swap space.

Consider again the example where I sent my iBook to Apple for repairs. Though my home directory is encrypted, my data still may not be completely safe. A dishonest employee could boot his or her diabolical CD-ROM and replace, for example, the login binary on my system with the employee's own design. When my computer is returned and I log in, my encryption key could be shipped off to a remote computer by the newly installed login program. An intrusion detection system would make this scenario much less likely.

Another possible weak point in a system employing encrypted home directories using pam_mount is the system's login password. Because the login password is used, directly or indirectly, to unlock an encrypted filesystem, it must be strong. Countless studies have shown that most passwords chosen by users are quite weak. Rather than blindly increasing the required length of passwords, spend some time reading Bruce Schneier's Secrets and Lies. A strong passphrase, written down and stored in your wallet may be more secure than a memorized password. The addition of a physical authentication token might be even better. Remember, if your system login password is not secure, your encrypted filesystem is as good as read.

Finally, encrypted filesystems can be a double-edged sword. What if you forget your encryption key? What if you use the third technique described above and accidentally delete all records of your encrypted filesystem key? What if my or someone else's encryption-related software is buggy? All of these problems can result in you having to try 2128 or so different encryption keys to get your filesystem back. Your data may be as good as gone. As with any system administration endeavor, make filesystem backups. Ideally, these backups are not encrypted and are physically locked up somewhere secure.

The bottom line is many subtle considerations and procedures are required to administer a reasonably secure system beyond the use of a modern encryption algorithm like AES. To quote Matt Blaze's contribution to Applied Cryptography:

After reading this article, you should be familiar with the concept of an encrypted loopback filesystem. In addition, you should be able to deploy encrypted filesystems on the systems you administer and manage them with the pam_mount PAM module. In the future, I would like to see the CryptoAPI patches and pam_mount supported by the major Linux distributors. I also would like to see the CryptoAPI patch rolled into the mainstream util-linux package. Properly administered encrypted home directories are a powerful security tool.

Mike Petullo is a platoon leader in the US Army, stationed in Germany. He jumps out of airplanes by day, fights C code bugs by night and has been tinkering with Linux since early 1997. He welcomes your comments sent to lj @ flyn.org

if someone steals my Linux laptop, an Apple iBook, its filesystems permissions are little use against the thief who can simply boot from a diabolical CD-ROM.

a system administrator can configure pam_mount to mount and unmount the volumes automatically when users log on and off.

Another possible weak point in a system employing encrypted home directories using pam_mount is the system's login password.

http://www.knoppix.net/forum/viewtopic.php?t=3403

This allows you to create encrypted containers that you can mount and unmount, and move between machines as needed. This functionality is similar to pgpdisk or bestcrypt. This has been tested on the live cd and a hardrive install using Knoppix 3.2 June 6 2003.

As root:

Make a mount point for the encrypted filesystem as follows: mkdir /mnt/crypt

Edit '/etc/fstab', adding an entry for your mount point as follows:

Create your encrypted file as follows:

This creates a 10M encryption "container" in /etc called cryptfile. You can adjust size, location, and name to your preferences.

Next, run losetup as follows:

You only have one chance to enter the 20 character password, be careful.

Make your ext2 filesystem as follows:

Now you can mount the encrypted filesystem with:

When you're done, you can unmount and protect your filesystem as follows:

Slick, no?

documented on: Jul 02, 2003, pau1knopp

The above works fine for the root user, but I wanted something where "joe user" could mount, unmount, and read / write to the encrypted container. After a little trial and effort, here is what I have come up with…

This example shows how to create an ext2 file system on encrypted file. This example creates a 5 MB file (/mnt/msdos/scratch/cryptfile) for storage and a directory (/mnt/crypt) as a mount point.

Note: This example is intentionally simple to help you understand basic loop encryption, but is also vulnerable to optimized dictionary attacks. Also, the "losetup -e" command asks for a 20 character encryption password, make up one and don't forget it.

Execute the following commands (as root), modifying paths and filenames for your purposes:

Next, add this to your /etc/fstab file (all one line):

Exit the root account, to your joe user account (knoppix in this example).

Now regular users should be able to mount the file system as follows (after answering the password prompt correctly).

The can then unmount it like this:

The only thing that needs done now is to create a desktop icon that will let users mount and unmount the container. Creating an icon that shows the "disk" as mounted and lets you unmount is no problem, but when you go to mount it, you will get an error because the password is needed. Currently, I am mounting (as joe user) from a terminal, then using the icon (or command line) to dismount. If anyone comes up with anything a little more user friendly that is tested and working, please post.

documented on: Jul 08, 2003, pau1knopp

The answer to my own question is, use the -p option.

You can search google for "losetup -p" for more information, or just use my example below.

documented on: Oct 03, 2003, rneff

Since my work PC is Windows 2000, I have been wanting to use my same AES containers created on Linux in my Windows environment, and vice versa. Found a most excellent tool called CrossCrypt for this very purpose.

http://www.scherrer.cc/crypt/

It is command line driven, so you may want to use the GUI overlay designed for it.

http://www.sdean12.org/CrossCryptGUI.htm

Finally, there is also a utility that let's you manage your containers from a system tray icon.

http://www.sdean12.org/zipped2/SecureTrayUtil391.zip

The system tray also supports other Win32 FOSS and commercial encrypted containers you might be using (freeOETF, bestcrypt, E4M, pgpdisk, scramdisk, and truecrypt) as well as adds shredder functionality, and integrates into the Windows shell pretty well.

documented on: Jul 01, 2005, pau1knopp