Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


eCryptfs: Single-File Encryption in Linux : Page 4

Encrypt your files transparently in Linux with eCryptfs, an enterprise-class stacked cryptographic file system.




Application Security Testing: An Integral Part of DevOps

The Client-Side Setup
A portion of the eCryptfs FAQ page reads:
Changes in the 2.6.24 kernel make eCryptfs more functional on NFS and CIFS, although there is still a little more work to do in order to make eCryptfs function as well on networked file systems as it currently works on local file systems.

To try this out and allow a remote machine to mount a directory with NFS, export the /data directory containing the confidential data on the server. Edit the file /etc/exports by adding a row for each authorized machine:

/data client1_name(rw,sync,no_root_squash,no_subtree_check) /data client2_name(rw,sync,no_root_squash,no_subtree_check) ...

Restart NFS server:

/etc/init.d/nfs-kernel-server restart

On the client side, you have to customize and build the kernel and then insert the modules as you did for the server. You need to mount the server /data directory under the local /remote_data directory via NFS:

mount server_name:/data /remote_data

In a very similar way as before, you can locally mount /remote_data /confidential over itself as an eCryptfs file system:

mount –t ecryptfs /remote_data/confidential /remote_data/confidential

This is valid for any key type chosen, and the command can be enriched with command-line options to avoid interaction. The system works even if you didn't make an exhaustive test. ECryptfs' usability will improve greatly as soon as NFS support becomes fully reliable.

Automating with UDEV
For further automation, you use the UDEV kernel implementation. UDEV is the new Linux system that dynamically allocates device files representing hardware peripherals under /dev. It is beyond the scope of this article to drill down into technical details about UDEV. Instead, this section describes all the steps to mount an eCryptfs file system automatically when you insert a USB pen drive (sdb) containing a passphrase in a file called foo.txt.

First, install the udev package that contains the user space utilities to manage the udev system and the lsscsi utility:

apt-get install udev lsscsi

The udevd daemon reads all the files under /etc/udev/rules.d in alphabetical order. These files dictate the rules for configuring devices after certain events occur. In this case, the event is the insertion of a specific USB pen drive. You have to retrieve its hardware peculiarities. With lsscsi, you can find the information about the device automatically assigned to your pen drive, in the following example sdb:

[4:0:00] disk SanDisk Corporation U3 Cruzer Micro 3.10 /dev/sdb

Then with the command:

udevadm info –attribute-walk –name sdb

You would retrieve the following information about the pen drive:

ATTRS{manufacturer}=="SanDisk Corporation" ATTRS{product}=="U3 Cruzer Micro" ATTRS{serial}=="0000186F6A623B0D"

Under /etc/udev/rules.d, you would write the file z21_passpen.rules (the z21 prefix forces the udevd daemon to execute the rule in the right order):

SUBSYSTEMS=="usb", \ ATTRS{manufacturer}=="SanDisk Corporation", \ ATTRS{product}=="U3 Cruzer Micro", \ ATTRS{serial}=="0000186F6A623B0D", \ NAME+="passpen%n", \ OPTIONS+="all_partitions" ACTION=="add", \ NAME=="passpen1", \ RUN="/usr/local/bin/eup.sh

In the first row, you see a set of conditions defined by a double equal sign. If the event related to the insertion of the USB pen drive and reported to the udevd daemon satisfy these conditions, then udev executes what is prescribed further (i.e., naming the devices file connected to the pen drive with /dev/passpenX).

The second row says that when a new /dev/passpen1 is added, the script /usr/local/bin/eup.sh has to be run:

#!/bin/sh PEN_MOUNT_POINT=/usb FILE=foo.txt CONFIDENTIAL_DIR=/remote_data/confidential /bin/mount -t auto /dev/passpen1 ${PEN_MOUNT_POINT} modprobe aes modprobe md5 modprobe ecryptfs /bin/mount -t ecryptfs \ ${CONFIDENTIAL_DIR} ${CONFIDENTIAL_DIR} \ -o key=passphrase:passfile=${PEN_MOUNT_POINT}/${FILE},\ ecryptfs_cipher=aes,\ ecryptfs_key_bytes=32,\ ecryptfs_passthrough=no,\ no_sig_cache

It is a best practice to restart the udevd daemon, which forces it to read the new rule:

/etc/init.d/udev restart

Some seconds after the insertion of the precious USB pen drive, the eCryptfs will be automatically mounted.

What you have learned so far is just a starting point for exploiting all the features offered by eCryptfs. For example, you can also:

Never Feel Secure
When an eCryptfs file system is mounted, access to the data it contains is available to all users and it is regulated by file and directory permissions only. Moreover, during and after editing eCryptfs files, decrypted copies of the file contents remain on the swap space (if it exists). To avoid this, you have to encrypt the swap space and a better technique for this kind of operation is dm-crypt, a kernel implementation that encrypts data at the block-device level.

Roberto Giorgetti is an IT manager and technical writer based in Italy. He is mainly interested in open source exploitation in business and industrial areas. Roberto holds a degree in Nuclear Engineering.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.
Thanks for your registration, follow us on our social networks to keep up-to-date