Canonical Voices

Posts tagged with 'ecryptfs'

Colin Ian King

Testing eCryptfs

Over the past several months I've been occasionally back-porting a bunch of eCryptfs patches onto older Ubuntu releases.  Each back-ported fix needs to be properly sanity checked and so I've been writing test cases for each one and adding them to the eCryptfs test suite.

To get hold of the test suite, check it out using bzr:

 bzr checkout lp:ecryptfs  
and install the dependencies so one can build the test suite:
 sudo apt-get install debhelper autotools-dev autoconf automake \
intltool libtool libgcrypt11-dev libglib2.0-dev libkeyutils-dev \
libnss3-dev libpam0g-dev pkg-config python-dev swig acl \
ecryptfs-utils
If you want to test eCrytpfs with xfs and btrfs as the lower file system onto which eCryptfs is mounted, then one needs to also install the tools for these:
 sudo apt-get install xfsprogs btrfs-tools  
And then build the test programs:
 cd ecryptfs  
autoreconf -ivf
intltoolize -c -f
./configure --enable-tests --disable-pywrap
make
To run the tests, one needs to create lower and upper mount points. The tests allow one to create ext2, ext3, ext4, xfs or btrfs loop-back mounted file systems on the lower mount point, and then eCryptfs is mounted on the upper mount point on top.   To create these, use something like:
 sudo mkdir /lower /upper  
The loop-back file system image needs to be placed somewhere too, I generally place mine in a directory /tmp/image, so this needs creating too:
 mkdir /tmp/image  
There are two categories of tests, "safe" and "destructive".  Safe tests should run in such a ways as to not lock up the machine.  Destructive tests try hard to force bugs that can cause kernel oopses or panics. One specifies the test category with the -c option.  Now to run the tests, use:
 sudo ./tests/run_tests.sh -K -c safe -b 1000000 -D /tmp/image -l /lower -u /upper  
The -K option tells the test suite to run the kernel specific tests. These are the ones I am generally interested in since I'm testing kernel patches.

The -b option specifies the size in 1K blocks of the loop-back mounted /lower file system size.  I generally use 1000000 blocks as a minimum.

The -D option specifies the path where the temporary loop-back mounted image is kept and the -l and -u options specified the paths of the lower and upper mount points.

By default the tests will use an ext4 lower filesystem. One can also run specify which file systems to run the tests on using the -f option, this can be a comma separated list of one or more file systems, for example:
 sudo ./tests/run_tests.sh -K -c safe -b 1000000 -D /tmp/image -l /lower -u /upper \
-f ext2,ext3,ext4,xfs
And also, instead of running a bunch of tests, one can just a particular test using the -t option:
 sudo ./tests/run_tests.sh -K -c safe -b 1000000 -D /tmp/image -l /lower -u /upper \
-f ext2,ext3,ext4,xfs -t lp-926292.sh
..which tests the fix for LaunchPad bug 926292
 
We also run these tests regularly on new kernel images to ensure we don't introduce and regressions.   As it stands, I'm currently adding in tests for each bug fix that we back-port and for most new bugs that require a thorough test. I hope to expand the breadth of the tests to ensure we get better general test coverage.

And finally, thanks to Tyler Hicks for writing the test framework and for his valuable help in describing how to construct a bunch of these tests.

Read more
Chad Miller

I’ve spoken before (Barcamp Orlando, 2007) about how we, as a culture, do not protect data as well as we should.  We value physical things more than we value data, even though some of us spend far more of our lives creating and using data.

One way we can lose data is through theft of the hardware it’s on.  We can think about the value of encryption, not only in how much positive value some information has to you (how much is a random string worth, really?), but also in how much negative value it would have if someone else had control of it (like when your bank password is in the hands of someone else).

Ubuntu can’t help you value your data more, but it can help remove some of the negative impact of someone stealing your hardware.  Though a single directory was available only to advanced users back in Ubuntu 9.04, now all users can take advantage of having all personal data encrypted! That’s right — you entire home directory can be encrypted.  There’s a great article written by Dustin Kirkland that elucidates how to begin to use encrypted home, even for established users and systems.

I thought I understood the migration process more than I really did, so my first attempt failed.  I worked on it until I understood it, and so maybe someone will find a high-level summary of what I learned to be useful:

  1. Start ~/Private dir encryption.  Copy all of your home into it (excluding the “Private” therein).  Unmount the encryption.
  2. Make a new directory outside to hold config files.  Move your ~/.ecryptfs  into it, so there’s no chicken-egg problem in loading the config files.  Move your ~/.Private ciphertext into it also.
  3. Make a new directory that will be renamed to your home directory later, which will hold almost nothing except a symlink to the config files and symlink to ciphertext dir.
  4. Move your home out of the way, to back up.  Move the new tmp into place.
  5. Then, at log in, it reads the configs, finds the ciphertext, mounts this on top of your home, and all works as it should.

That is of course, just an overview of what one does, and should only help one grapple with the concepts, not help one actually do anything.  For more helpful advice see that article above.

Encrypted home directories are new in Ubuntu 9.10 and are very easy to use if starting a new user from scratch.

Read more