Data Security and Key Management in the Cloud

Key management in cloud computing presents a brand new, unique, and distinct set of challenges which are in many cases disparate from the traditional set of key management problems system administrators have been dealing with for decades in physical data centers.  In fact, this very topic, in conjunction with data security and privacy, is the subject of two presentations I’m giving in the next 30 days at:

• Texas Linux Fest -- San Antonio, TX -- August 4, 2012
• Linux Foundation’s CloudOpen -- San Diego, CA -- Wednesday August 29, 2012

How are you managing your most sensitive information stored in the Cloud? Are you encrypting that data? Where are you storing your cryptographic keys and certificates? And who has access to them? If you have a stake in your organization's security, these questions may be keeping you up at night.

Cloud storage and Big Data present significant opportunities for enterprises, but those opportunities bring several huge challenges. In this session, we’ll explore:

• What's not secure, not acceptable, not working --- but totally pervasive!
• Where encryption makes the most sense around Cloud and Big Data applications
• Key sprawl in the cloud
• The strengths and weaknesses of various key management options
• Easing the pain - Recent innovations for managing keys and company secrets
• Real-world use cases – from web servers to encrypted file systems to big data to SSH to SSL

I hope you’ll join me for one or both of these talks!

:-Dustin

ecryptfs-utils-99 released

ecryptfs-utils (99-0ubuntu1) quantal; urgency=low

  [ Dustin Kirkland ]
  * debian/ecryptfs-utils.postinst: LP: #936093
    - ensure desktop file is executable
  * precise

  [ Wesley Wiedenmeier ]
  * src/utils/mount.ecryptfs.c: LP: #329264
    - remove old hack, that worked around a temporary kernel regression;
      ensure that all mount memory is mlocked

  [ Sebastian Krahmer ]
  * src/pam_ecryptfs/pam_ecryptfs.c: LP: #732614
    - drop group privileges in the same places that user privileges are
      dropped
    - check return status of setresuid() calls and return if they fail
    - drop privileges before checking for the existence of
      ~/.ecryptfs/auto-mount to prevent possible file existence leakage
      by a symlink to a path that typically would not be searchable by
      the user
    - drop privileges before reading salt from the rc file to prevent the
      leakage of root's salt and, more importantly, using the incorrect salt
    - discovered, independently, by Vasiliy Kulikov and Sebastian Krahmer
  * src/pam_ecryptfs/pam_ecryptfs.c: LP: #1020904
    - after dropping privileges, clear the environment before executing the
      private eCryptfs mount helper
    - discovered by Sebastian Krahmer
  * src/utils/mount.ecryptfs_private.c: LP: #1020904
    - do not allow private eCryptfs mount aliases to contain ".." characters
      as a preventative measure against a crafted file path being used as an
      alias
    - force the MS_NOSUID mount flag to protect against user controlled lower
      filesystems, such as an auto mounted USB drive, that may contain a
      setuid-root binary
      + CVE-2012-3409
    - force the MS_NODEV mount flag
    - after dropping privileges, clear the environment before executing umount
    - discovered by Sebastian Krahmer

  [ Tyler Hicks ]
  * src/libecryptfs/key_management.c: LP: #732614
    - zero statically declared buffers to prevent the leakage of stack
      contents in the case of a short file read
    - discovered by Vasiliy Kulikov
  * src/libecryptfs/module_mgr.c, src/pam_ecryptfs/pam_ecryptfs.c:
    - fix compiler warnings

Date: Fri, 13 Jul 2012 09:52:36 -0500
Changed-By: Dustin Kirkland

Let's celebrate the 100th release of eCryptfs utils!

Howdy all!

It's hard to believe that it's been almost 7 years since many of you helped conceive, design, implement, develop extend, test, document eCryptfs back in the IBM Linux Technology Center's Security team, with many more contributions following from Canonical, Red Hat, Intel, etc.

Over those 7 years, we have helped many of the rest of you reading this secure your private data.  Today, there are actually millions of eCryptfs users -- through Ubuntu (and other Linux distros) encrypted home directories, Google's ChromeOS, Synology and Seagate encrypted NAS devices, some Android phones, Gazzang's cloud and big data encryption products, among others.

With the 100th release of the user space eCryptfs utilities (ecryptfs-utils), we'd like to take the opportunity to invite any contributors or users of eCryptfs for a celebration!

Gazzang is providing drinks and snacks on its rooftop (and air-conditioned lobby) in downtown Austin, at 8th and Congress, with great views of the Texas state capitol and all of downtown.  Please join us at 804 Congress Avenue, Suite 400, from 5pm-8pm on Thursday, August 2, 2012.  This is the day before the Texas Linux Fest in San Antonio, so perhaps we might see a few out of town guests join us...  I happen to know at least one guest of honor who will be in from out of town for this event ;-)

Hopefully you'll join some of your colleagues around the Linux, open source, security, encryption, key management and data privacy space for an informal get together here in central Texas!

Cheers,
Dustin Kirkland
eCryptfs co-maintainer

Opaque Object Storage

Gazzang has built an interesting business around Transparent Data Encryption, building on top of eCryptfs, adding some mandatory access controls and policy management in a product we call zNcrypt.

With the addition of zTrustee to the Gazzang product portfolio, we have entered an even more interesting, ambitious, new space in modern Cloud computing -- Opaque Object Storage.

eCryptfs and zNcrypt provide "transparent" data encryption, in that when the encrypted filesystem is mounted, allowed users, applications and processes (possessing the appropriate keys) are allowed to seamlessly read and write data as regular files and directories to the mounted storage filesystem.  No user, application, or process needs to know anything about encryption -- they simply read and write data "transparently" from and to files and directories.  Input/output operations are trapped in the Linux filesystem layer, and eCryptfs handles encrypting and decrypting files as necessary.  Assuming you have safeguarded your keys appropriately, an offline attacker with physical or remote access to the disk would not have access to mounted filesystem and instead only see the cryptographically protected data.

zTrustee was designed from the ground up to store and serve the keys necessary to make eCryptfs and zNcrypt work properly.  But we implemented it in a manner in which we can store and serve keys, certificates, files, directories, and data of any type -- similar to some object storage systems.  However, we added our considerable security expertise to our implementation, and use encryption yet again to our customer's advantage.  Each of these objects stored in zTrustee are actually encrypted and signed with the public GPG keys of the client storing and/or retrieving the data.  This means that even an administrative user with full root access on the zTrustee server will not have introspection into the contents of the data blobs stored as deposits on the zTrustee server.  For this reason, we're calling these deposits "Opaque Objects", and noting that our zTrustee server provides "Opaque Object Storage".

Moreover, the fine-grained security policies that govern the release of these deposits further differentiate zTrustee from various other object storage products.  Beyond the individual encryption of each zTrustee deposit (object), the policy by which an object is released can:

• limit the TTL (time to live)
• limit the number of times it can be retrieved (e.g. Mission Impossible message)
• be disabled (and later enabled)
• be purged entirely
• required 0 - N trustees authenticate and "vote" or "sign off" on the release
• be retrieved by an authenticated, signed/encrypted client, or
• be retrieved anonymously using a nonce URL

With this level of policy control, encryption, and cryptographic signature enforcement, we believe we've built something really quite interesting and useful for modern Cloud computing applications.

Stay tuned for some examples!

:-Dustin

Introducing Gazzang zTrustee!

I'm out at the GigaOM Structure conference in sunny San Francisco this week, where Gazzang has launched its newest product -- Gazzang zTrustee!  My colleagues and I have dedicated the last 6 months to the design, architecture, development and testing of this new product, and I'm thrilled to finally be able to speak freely about it.

Gazzang's original product, zNcrypt is a transparent data encryption solution -- a GPLv2 encrypted filesystem built on top of eCryptfs, adding mandatory access controls and a dynamic policy structure.  zNcrypt enables enterprise users to secure data in the cloud, meet compliance regulations, and sleep well at night, ensuring that all information is encrypted before written to the underlying storage.

As of today, Gazzang's newest product, zTrustee is an opaque object storage system, ultimately providing a flexible, secure key management solution for data encryption.  Any encryption system, at some point, requires access to keys, and those keys should never be stored on the same system as the encrypted data.  While zTrustee was initially designed to store keys, it can actually be used to put and get opaque data objects of any type or size.

Planet Ubuntu readers might recognize a few small-scale ancestors of zTrustee in other projects that I've authored and talked about here in the past...  The encrypted pbputs and pbget commands now found in the pastebinit package are similar, in principle, to zTrustee's secure put and get commands.  But rather than backing uploads with a pastebin server, we have implemented a powerful, robust, enterprise-ready web service with extensive, flexible policies, redundancy, and fault-tolerance.  The zEscrow utility and service are also similar in some other ways to zTrustee, except that zEscrow is intended to share keys with a backup service, while zTrustee blindly and securely stores opaque objects, releasing only to authenticated, allowed clients per policy.

Planet Ubuntu readers may be pleased to hear that our zTrustee servers are currently running Ubuntu 12.04 LTS server, replicated across multiple cloud providers.  The RESTful web service is built on top of a suite of high quality open source projects, including: apache2, python wsgi, postgresql, sqlalchemy, postfix, sks, squid, gnupg, and openssl (among others).

The zTrustee client is a lightweight python utility, leveraging libcurl, openssl, and gnupg to send and receive encrypted, signed JSON blobs, to and from one or more zTrustee servers.  The client utilizes the zTrustee Python library, which does the hard work, encrypting, decrypting, and processing the messages to and from the zTrustee server.  You'll soon be able to interface with zTrustee using either the command line interface, or the Python library directly in your Python scripts.

We've turned our current focus onto Android, while developing a Java interface to zTrustee, so that Java programs and Android applications will soon be able to interface with zTrustee, putting and getting certificates and key material and thereby enabling mobile encryption solutions.  Looking a little further out down our road map, we'll also use these Java extensions to support zTrustee clients on iOS, Mac, and Windows.

While I'm big fan and proponent of eCryptfs and zNcrypt, I plainly recognize that there are lots of other ways to encrypt data -- dmcrypt, TrueCrypt, FileVault, BitLocker, HekaFS, among many others.  From one perspective, encrypting and decrypting data is now the easy part.  Where to store keys, especially in public/private/hybrid cloud environments, is the really hard part.  Many people and organizations have punted on that problem.  Well as it happens, I like hard problems, and Gazzang likes market opportunities and for that, we're both proud to promote zTrustee as a new solution in this space.

This post is intended as a very basic or brief introduction to the concept, and I'll follow this with a series of examples and tutorials as to how you might use the zTrustee client, library, and mobile interfaces.

Cheers,
:-Dustin

ecryptfs-utils-97 released

It's been a little while, apologies for that, but we've just released ecryptfs-utils-97!

I'm really excited about this eCryptfs release, as it includes contributions from 9 different individuals employed by 4 different open source companies.  A big thanks to all contributors!

1. Kees Cook (Google)
2. Andreas Raster
3. George Wilson (IBM)
4. Sergio Pena (Gazzang)
5. Colin King (Canonical)
6. Colin Watson (Canonical)
7. Serge Hallyn (Canonical)
8. Dustin Kirkland (Gazzang)
9. Tyler Hicks (Canonical)

The full changelog is below.  As usual, please file any new issues in Launchpad.

:-Dustin

ecryptfs-utils (97) quantal; urgency=low

  [ Kees Cook ]
  * src/pam_ecryptfs/pam_ecryptfs.c: LP: #938326
    - exit, rather than return to prevent duplicate processes

  [ Andreas Raster ]
  * src/desktop/ecryptfs-find:
    - $mounts was quoted once too often

  [ George Wilson ]
  * src/key_mod/ecryptfs_key_mod_openssl.c,
    src/key_mod/ecryptfs_key_mod_pkcs11_helper.c,
    src/key_mod/ecryptfs_key_mod_tspi.c: LP: #937331
    - IBM would like to grant a license exception for key modules that
      require linking to OpenSSL. The change should make the modules
      shippable by Linux distributions

  [ Dustin Kirkland ]
  * debian/copyright:
    - note the GPLv2 SSL exception granted by IBM for the key modules
  * debian/control, debian/copyright, doc/manpage/ecryptfs.7,
    doc/manpage/ecryptfs-add-passphrase.1, doc/manpage/ecryptfsd.8,
    doc/manpage/ecryptfs-generate-tpm-key.1, doc/manpage/ecryptfs-
    insert-wrapped-passphrase-into-keyring.1, doc/manpage/ecryptfs-
    manager.8, doc/manpage/ecryptfs-mount-private.1,
    doc/manpage/ecryptfs-recover-private.1, doc/manpage/ecryptfs-rewrap-
    passphrase.1, doc/manpage/ecryptfs-rewrite-file.1,
    doc/manpage/ecryptfs-setup-private.1, doc/manpage/ecryptfs-setup-
    swap.1, doc/manpage/ecryptfs-stat.1, doc/manpage/ecryptfs-umount-
    private.1, doc/manpage/ecryptfs-unwrap-passphrase.1,
    doc/manpage/ecryptfs-wrap-passphrase.1,
    doc/manpage/mount.ecryptfs.8, doc/manpage/mount.ecryptfs_private.1,
    doc/manpage/pam_ecryptfs.8, doc/manpage/umount.ecryptfs.8,
    doc/manpage/umount.ecryptfs_private.1, README,
    src/utils/mount.ecryptfs.c:
    - use the new ecryptfs.org website where appropriate
  * debian/control:
    - update to suggest zescrow-client

  [ Sergio Peña ]
  * src/libecryptfs/cipher_list.c: LP: #922821
    - add the new name of the blowfish cipher (linux >= 3.2)
  * src/include/ecryptfs.h, src/libecryptfs/main.c,
    src/utils/mount.ecryptfs.c: LP: #917509
    - use execl() to mount ecryptfs
    - this allows us to support any arbitrary mount options in
      /etc/fstab

  [ Tyler Hicks ]
  * doc/manpage/ecryptfs.7:
    - Remove the note saying that the passphrase and openssl key modules are
      available by default. That's true upstream but not always true in distro
      builds.
  * tests/run_tests.sh:
    - Make upper and lower mount point arguments optional by automatically
      creating directories in /tmp by default.
    - Make it possible to run only userspace tests without having to specify
      unused mount information
    - Accept a comma-separated list of lower filesystems to test on and loop
      through all kernel tests for each lower filesystem
    - Accept a comma-separated list of tests to run
  * tests/lib/etl_funcs.sh:
    - Unset $ETL_DISK just before etl_remove_disk() successfully returns
  * tests/userspace/Makefile.am:
    - Also build 'make check' tests when building with --enable-tests
  * include/ecryptfs.h, libecryptfs/Makefile.am,
    libecryptfs/cipher_list.c, libecryptfs/module_mgr.c,
    utils/io.h: LP: #994813
    - remove overly complicated implementation to detect what ciphers
      are supported by the currently running kernel's crypto api
    - prompt for the entire supported cipher list, if the user selects a
      cipher that their kernel doesn't support, the mount will fail
      and the kernel will write an error message to the syslog
  * src/libecryptfs/module_mgr.c:
    - Use correct blowfish block size when displaying supported ciphers to
      the user
  * tests/kernel/lp-1009207.sh, tests/kernel/Makefile.am,
    tests/kernel/tests.rc:
    - Add simple test case for incorrect handling of umask and default POSIX
      ACL masks
  * tests/kernel/lp-994247.sh, tests/kernel/lp-994247/test.c,
    tests/kernel/Makefile.am, tests/kernel/tests.rc:
    - Add test case for incorrect handling of open /dev/ecryptfs file
      descriptors that are passed or inherited by other processes

  [ Colin King ]
  * tests/lib/etl_funcs.sh:
    - etl_lumount() should use DST rather than SRC dir so it can run on Lucid
    - use file system appropriate mkfs force flag
    - cater for correct ext2 default mount flags
  * tests/kernel/lp-509180.sh, tests/kernel/lp-509180/test.c:
    - test for trailing garbage at end of files
  * tests/kernel/lp-524919.sh, tests/kernel/lp-524919/test.c:
    - test case for checking lstat/readlink size
  * tests/kernel/lp-870326.sh, tests/kernel/lp-870326/test.c:
    - test case for open(), mmap(), close(), modify mmap'd region
  * tests/kernel/lp-469664.sh:
    - test case for lsattr
  * tests/kernel/lp-613873.sh:
    - test case for stat modify time
  * tests/kernel/lp-745836.sh:
    - test case for clearing ECRYPTFS_NEW_FILE flag during truncate
  * tests/lib/etl_funcs.sh, tests/kernel/extend-file-random.sh,
    tests/kernel/trunc-file.sh (LP: #1007159):
    - Add test library function for estimating available space in lower fs
    - Use new library function in tests that need to create large files

  [ Colin Watson ]
  * src/utils/ecryptfs-setup-swap: Skip /dev/zram* swap devices
    LP: #979350

  [ Serge Hallyn ]
  * src/utils/mount.ecryptfs_private.c:
    - EoL fixes

 -- Dustin Kirkland Fri, 15 Jun 2012 09:32:48 -0500

zEscrow Lightning Talk Live Demo

The Friday lightning talks from the Ubuntu Developer Summit (Quantal in Oakland) are now up! You can now watch my 5 minute introduction and live demo of zEscrow here.

:-Dustin

Introducing zEscrow -- or, How to save your encrypted life!

I had the honor of introducing zEscrow about a week ago, at the Ubuntu Developer Summit during Friday's plenary of lightning talks.  You can also view my slides now!


zEscrow is a free service offered by my employer, Gazzang, to users of Ubuntu's Encrypted Home Directory, to aid them in safely backing up and retrieving the bit of configuration and key material necessary to recover that data later.  I can't state this emphatically enough...

This very well may
save your encrypted life at some point!

The Quick Start Guide

If you're running a version of prior to Ubuntu 12.04 LTS, first add the PPA:

  
  sudo apt-add-repository ppa:zescrow/ppa

  sudo apt-get install zescrow

And if you're on Ubuntu 12.04 LTS, just install.

  sudo apt-get install zescrow-client

Now, just run zescrow, and follow the three simple prompts:

1. Choose your server
2. Enter your login password
3. Visit the one-time URL

How it Works

Some inquiring minds might want to know the nitty gritty details.  You're welcome to read the code, as Gazzang has released both the client and server as free and open source code in Launchpad under the AGPL.  Here's a narrative pseudocode of the algorithm though:

1. Choose your zEscrow server.  I recommend that you use the default, zescrow.gazzang.com.
2. The zescrow utility will download the public GPG key associated with your zEscrow server and load it into a temporary keyring stored entirely in memory.
3. Enter your LOGIN password.  This will be used to decrypt your ~/.ecryptfs/wrapped-passphrase file.  Under NO circumstances will your LOGIN password will sent to the remote server!!!
4. The utility will create a tar archive of your entire ~/.ecryptfs directory, but replacing your wrapped-passphrase file, with unwrapped-passphrase.  This protects your LOGIN passphrase from ever leaving your system, but ensures that your randomly generated MOUNT passphrase will be securely transferred to the remote server
5. This ecryptfs.tar archive is securely transmitted to the zEscrow server over SSL.
6. Upon a successful transmission to the zEscrow server, a cryptographically nonced URL link is sent back to the client utility, which embeds a checksum of the transmitted archive, verifying the integrity of the transmission.
7. You MUST complete the transaction by opening the link IMMEDIATELY, to "claim" this upload as yours.  Upon doing so, you'll be required to login using Google OpenID.  
• (Yes, you must have a Google OpenID to use this service.  Sorry.  Send a patch, if you want support for another OpenID provider).
8. That's it!  You can now download your backups from zescrow.gazzang.com at any time, and use ecryptfs-recover-private to get your data back, following these instructions!

The Motivation

This might help explain why I have personally received hundreds (probably climbing north of a thousand) emails, IRC messages, forum posts, StackExchange questions, Launchpad bugs, SMS messages and even phone calls to my cell phone (!?!) from users who have forgotten their login password, or did not record their randomly generated eCryptfs mount password at installation, and are now cryptographically locked out of their own data :-(

Unhappy Users Don't Back Up their eCryptfs Passphrase

A few random quotes from the last 2 months alone:

• "Through idiocracy I have screwed up my encrypted home directory and if possible I need help getting it back."
• "I was trying to mount my encrypted home directory from a livecd in order to back up my data (according to the instructions), when I accidentally deleted one of the .ecryptfs folders in my encrypted home."
• "Mr Kirkland, my name is MB. I used an Ubuntu system with ecryptfs. Something happened and it all went up in smoke. I saved a backup and moved on. Chalked it up to bad backup practices and moved on. I found the encrypted backup a few days ago, and I've been trying to unscrew it. I *think* I found the old wrapped-passphrase file, and I tried to fix it. So far, I've been unable".
• "Please help as I am stuck in Korea and will be totally shagged without my e-mail and data. I have 6 months un-backedup work on the disk, of course. And I saved the password for the disk on my home partition...great move eh?"

I can't even respond to most of these emails, if it's clear that the user hasn't backed up their random, mount passphrase.  These are usually 16 or 32 characters of hexadecimal [0-9a-f], representing 128-bits or 256-bits of entropy.  You're doing battle with a mathematical Highlander at this point...  There can be only one, and the chances are absolutely astronomical that it won't be you :-(

But Happy Users Do Back Up their eCryptfs Passphrase!

On the other hand, I have helped hundreds upon hundreds of users recover their data, when its clear that they HAVE backed up their randomly generated MOUNT passphrase.  These two blog post of mine, about the ecryptfs-recover-private utility and how to mount your encrypted home from a live CD, are my two all-time most viewed posts.  A few quotes from happy users:

• "you saved my life, thank you!"
• "Where do I send hugs? It's great, thanks so much! I just want to add my note"
• "Worked like a charm - thanks."
• "YOU SAY IT! *YOU* *THE* *MAN* JUST SAVED MY LIFE! THANK YOU"
• "Thanks $deity and Dustin, this method works for recover my encrypted private directory and backup it to external drive. Thanks again for this tutorial."
• "Thanks Man!! it worked for me!!"
• "Today, making a liveCD and following your instructions above put a massive smile on my face. I can't believe I've now got access to everything again and nothing is lost. Thank you so much for sharing your knowledge - I shall sleep well tonight!"
• "Thank you for this addition to Natty! I was having a hard time mounting my files on a system I wrecked ;)"
• "thank's a lot, u'r save my life"
• "My god. Thank you so much! I tried to upgrade to 11.04, and it wrecked my OS. This is a lifesaver."
• "This is cake my friend nice job! I remember when this was stuff was hard. I've been trying to recover a drive for some time now."
• "I just wanted to say thanks for building this. I used it to recover a ~/.Private directory on an external drive, and it worked flawlessly. It's folks like yourself building tools like this that makes open source projects such a pleasure to use. So kudos, and thanks."

If you use the free zEscrow service from Gazzang, in conjunction with Ubuntu's Encrypted Home Directory, and the ecryptfs-recover-private utility, you'll almost certainly be counted in the "Happy Users".  And if not...well, you're a bit on your own!  Please, please, please write down your passphrase and store it in a very safe, very private place!!!

:-Dustin

Introducing eCryptfs.org!

I'm very proud to announce today the launch of eCryptfs.org!  For the first time in the 7 year history of the project, eCryptfs has it's very own, dedicated home on the web at eCryptfs.org.

eCryptfs.org now serves as the project's official portal to numerous resources, including: information about the project, StackExchange questions and answers, mailing list archives, the Google Plus page, package download links for all major Linux OSes, pointers to the kernel and userspace source code repositories, support resources, documentation, and news.

The kernel sources continue to be hosted on git.kernel.org, and the user space sources and bugs hosted on Launchpad.net.  We are now using StackExchange.com for questions and answers rather than Launchpad.

A special thanks goes out to the original authors and developers of eCryptfs in the IBM Linux Technology Center Security Team, the Canonical Kernel and Security Team, Red Hat and beyond, as well as all of the contributors to eCryptfs over the last 7 years.  Gazzang commissioned the artwork and web design, and is sponsoring the web hosting of eCryptfs.org as a bit of a "thank you" to the eCryptfs community growing far and wide.  Let us know what you think!

Cheers,
:-Dustin

Gazzang the Thang: Big Data

I'm thrilled to see Gazzang's next big thang is now out of the gate...

We announced today our comprehensive, turnkey encryption platform for Big Data, Hadoop, NoSQL, and several other cloud workloads.  Our encryption technology is built on top of eCryptfs and transparently encrypts data, protecting sensitive data at rest without requiring modifications to your applications, partitioning, or filesystems.

We've tested our Gazzang Encryption Platform for Big Data against Apache Hadoop, Apache Cassandra, and MongoDB, on Ubuntu 10.04 LTS and Ubuntu 11.10, with both OpenJDK and Sun Java.

The news hit a good handful of tech news outlets today.  Enjoy!

• Gazzang Launches Big Data Encryption and Key Management Platform
• Hadoop Users Could Get Their First Taste of Real Encryption
• And a growing list of subtle clones...
  
  

:-Dustin

Video Podcast with Amber Graner

I spent a good half hour on Monday morning with Amber Graner of Linaro.  This was my first experience with G+ On Air, a mechanism for conducting video interviews over G+ Hangouts and record them for rebroadcast over YouTube later.

I've known Amber for nearly 4 years now, and she's such a warm, fun, and energetic person.  I'm always humbled by her interest and willingness to branch out and learn about new technologies.  She's truly an inspiration for us all :-)

In this interview, we talked about Linaro, ARM, Android, Ubuntu, Cloud, Gazzang, Encryption, eCryptfs, and (of course) Byobu :-)  Enjoy!




:-Dustin

ecryptfs-utils-96 released

-utils-96

ecryptfs-utils-96 has been released, with upstream tarballs (and signatures) available on Launchpad at:

• https://launchpad.net/ecryptfs/trunk/96

And now in the Ubuntu precise development release.

Special thanks to first time contributors Colin King and Eddie Garcia!


[ Dustin Kirkland ]
  * CONTRIBUTING:
    - added a new file to describe how to contribute to ecryptfs
  * === added directory img/old, img/old/ecryptfs_14.png,
    img/old/ecryptfs_192.png, img/old/ecryptfs_64.png:
    - saving the old logos/branding for posterity
  * debian/copyright, img/COPYING:
    - added CC-by-SA 3.0 license
    - use the text version
  * img/ecryptfs_14.png, img/ecryptfs_192.png, img/ecryptfs_64.png:
    - added scaled copies of images used for Launchpad.net branding
  * src/utils/ecryptfs-recover-private: LP: #847505
    - add an option to allow user to enter the mount passphrase,
      in case they've recorded that, but forgotten their login
      passphrase
  * src/libecryptfs/sysfs.c: LP: #802197
    - default sysfs to /sys, if not found in /etc/mtab
    - it seems that reading /etc/mtab for this is outdated
    - ensure that ecryptfs works even if there is no sysfs entry
      in /etc/mtab
  * src/key_mod/ecryptfs_key_mod_tspi.c: LP: #462225
    - fix TPM and string_to_uuid 64bits issue
    - thanks to Janos for the patch

  [ Tyler Hicks ]
  * CONTRIBUTING:
    - clarified how to contribute to the ecryptfs kernel module
  * tests/lib/etl_funcs.sh:
    - created eCryptfs test library of bash functions for use in test
      cases and test harnesses
  * test/etl_add_passphrase_key_to_keyring.c:
    - created a C helper program to allow bash scripts to interface to
      the libecryptfs function that adds passphrase-based keys to the
      kernel keyring
  * tests/kernel/tests.rc, tests/userspace/tests.rc:
    - created a test case category files for test harnesses to source
      when running testcases of a certain category (destructive, safe,
      etc.)
  * tests/run_tests.sh:
    - created a test harness to run eCryptfs test cases
  * tests/kernel/miscdev-bad-count.sh,
    tests/kernel/miscdev-bad-count/test.c:
    - created test case for miscdev issue reported to mailing list
  * tests/kernel/lp-885744.sh:
    - created test case for pathconf bug
  * tests/kernel/lp-926292.sh:
    - created test case for checking stale inode attrs after setxattr
  * tests/new.sh:
    - created new test case template to copy from
  * tests/userspace/verify-passphrase-sig.sh,
    tests/userspace/verify-passphrase-sig/test.c:
    - created test case, for make check, to test the creation of
      passphrase-based fekeks and signatures
  * configure.ac, Makefile.am, tests/Makefile.am, tests/lib/Makefile.am,
    tests/kernel/Makefile.am, tests/userspace/Makefile.am:
    - updated and created autoconf/automake files to build the new tests
      directory
    - added make check target

  [ Eddie Garcia ]
  * img/*: LP: #907131
    - contributing a new set of logos and branding under the CC-by-SA3.0
      license

  [ Colin King ]
  * tests/kernel/extend-file-random.sh,
    tests/kernel/extend-file-random/test.c:
    - Test to randomly extend file size, read/write + unlink
  * tests/kernel/trunc-file.sh, tests/kernel/trunc-file/test.c:
    - Test to exercise file truncation
  * tests/kernel/directory-concurrent.sh,
    tests/kernel/directory-concurrent/test.c:
    - test for directory creation/deletion races with multiple processes
  * tests/kernel/file-concurrent.sh,
    tests/kernel/file-concurrent/test.c:
    - test for file creation/truncation/unlink races with multiple
      processes
  * tests/kernel/inotify.sh, tests/kernel/inotify/test.c:
    - test for proper inotify support
  * tests/kernel/mmap-dir.sh, tests/kernel/mmap-dir/test.c:
    - test that directory files cannot be mmap'ed
  * tests/kernel/read-dir.sh, tests/kernel/read-dir/test.c:
    - test that read() on directory files returns the right error
  * tests/kernel/setattr-flush-dirty.sh:
    - test that the modified timestamp isn't clobbered in writeback
  * tests/kernel/inode-race-stat.sh, tests/kernel/inode-race-stat/test.c:
    - test for inode initialization race condition


 -- Dustin Kirkland  Thu, 16 Feb 2012 14:23:18 -0600                                                                                                                                                                                                        


:-Dustin

Gazzang Bang and the SXSW Startup Pub Crawl

The Gazzang office at 502 Baylor Street in Austin, Texas is one of the destinations of the 2012 SXSW Startup Pub Crawl, on Thursday, March 8th.

Join us between 4 and 10 pm for an open house, drum circle, and some awesome live music from the Lost Pines bluegrass band!  Please RSVP here.  Come talk to us over free beer and food about Cloud security, data privacy, encryption, eCryptfs, key management, Linux, and Ubuntu.  Meet the entire cast of the Sh*t IT Security Guys Say short film.  And tap into the vibrant tech start-up culture that's rocking downtown Austin by day, juxtaposed against the awesome live music culture that rocks downtown Austin by night.



View Larger Map

Come get your bang on!

:-Dustin

"Harvey" the Honey Badger

The feedback on eCryptfs' new mascot and logo has been just awesome :-)  At the bottom of the last post, we opened a call for name suggestions.

As it turns out, my mom reads my blog from time to time, and with that post, she saw an exercise and opportunity for one of her high school classes.  She tasked them with researching eCryptfs and the reasoning behind the new logo.  As an extra credit assignment, they were invited to propose names for our tenacious new mascot.  These are so much fun, we'll share all of them with you now!

Leading by example, Mrs. Kirkland (aka, my Mom) writes:

I think you should call him...Honey, but play on the "e" ... and the quotes actually look like claws.   Hon"e"y.  The "e" fits perfectly in the hand.  Plus, when he is standing, he really forms an H.  I am no artist but I am sure you can see the H in its body.   I know you are just looking for a name... but I wanted to show you why I thought the name fit. 

Thanks, Mom!  The quotes around the "e" do look like claws, and it does refer back to the "e" in eCryptfs.


One of her students, Christopher Bordelon suggests:

I think the name Henry would be the perfect name for the honey badger. The name Henry refers to the noble politician Henry Clay. Henry led a defensive army when it came to the war of 1812. By naming the honey badger Henry it will set the tone of the project to have a well strengthened background. By being a member of the war hawks, Henry was always ready for a battle. He knew he would not be able to be defeated. I feel this is a great name for the honey badger because Henry Clay is a well known political leader in United States history. When people hear this name they will be drawn to it because of the historical accomplishments of Henry Clay. Henry was also known for living a very long time. By Henry living a long time this means that the project will be around for a long time too. He outlived the majority of his fellow leaders. By using his historical context the project will have a face that will never be forgotten. The project will have a mascot with a defensive output that will make customers want to bring their services there.

Thanks, Christopher.  We just loved the historical references!

Another of her students, Kristin Seneca, had a different idea:

I really appreciate the new logo; it is a major upgrade to the last. It has more vibrant colors and an all around better design. It isn’t as plain or boring as the key overlapping the pie chart. With a great logo, the project should want a great name to go along with it. This is why Boris the Badger would be a perfect name for your project's new honey badger logo. Boris the Badger would be a great name for eCryptfs' new honey badger logo. This name has significance to the honey badger. A honey badger is fierce and strong, much like what the name means. According to 2000names.com, the name Boris means a battle or fighter. It was derived from the name Bogoris, meaning small. Since the honey badger is one of the smallest and fiercest warrior animals around, I believe that this name definitely suits the eCryptfs honey badger logo. He certainly looks fierce! eCryptfs is a great project and should have a really awesome name to go along with their new logo. Boris the Badger would be the best name for the honey badger because it represents the idea of a warrior or fierce battle. The honey badger is a ferocious warrior animal and will go to great lengths to defend itself, much like the project will go to great lengths to protect files and software.

But our unanimous favorite here at the Gazzang offices was from Mrs. Kirkland's student Blane Palazzo, who wrote:

Reviewing possible names for the new honey badger design, I've decided that "Harvey, the Honey Badger" sounds the best. Not only is this name appropriate because of its beginning with an "H," but the name "Harvey" also means, "battle worthy." When determining which names would be possible for the new logo's design, I kept in mind that defense was a major part of choosing the "fitting" name. Having a defensive name, while at the same time establishing trust, was very important. Not only does the name "Harvey" build trust, it also has a background that allows for an understanding that he "means business." Like a true honey badger, he "takes what's his!"  Paul Harvey is famously known for his “Rest of the Story” segment, which was watched by millions until his death at the age of 90. The name Harvey can be related to many things, including the stamina held by Paul Harvey Himself, and the impact of his life felt by millions of Americans. This “Harvey” could be looked to for the “rest of the story” when it comes to protecting software and programs being used. The finality of such a name could be applied to the logo of a project that protects and defends.  eCryptfs is software that thrives on protection, and as mentioned in the blog, is a “vibrant and open-sourced” project. Having a fitting name is appropriate when it comes to any new idea or project. In order to be remembered as a project that strives for excellence, the logo has to be focused on and perfected. The name “Harvey” is a name that is not easily forgotten, and provides a significant enough meaning to the new logo.

Well done, Blane.  We, here at the Gazzang offices, absolutely love it!  And so, I'm pleased to introduce Harvey, the Honey Badger!

:-Dustin

Introducing New Branding and Logos for eCryptfs

The time I have spent around Ubuntu has given me a deep appreciation for the finer points of design, branding, themes, and artwork around software development and user interfaces.  From Ubuntu's elegant color schemes and meticulously kerned fonts, to the careful placement and balance of Ubuntu's logos and Canonical's brandmarks, Ubuntu exudes an exquisite level of polish and professionalism, particularly among free software projects.

With this as a backdrop, I have long wanted to refresh and modernize the logos and branding associated with eCryptfs, as an upstream open source project.  For over six years, the eCryptfs logo has been an ever-so-trite yellow key overlayed on top of a pie chart.

Yawn :-o  I'm pretty sure that "logo" was pulled off of a slide deck for IBM management, when Michael Halcrow and Emily Ratliff originally presented the idea of eCryptfs back in 2004.

So I pitched this idea to my new employer, Gazzang, who, as it turns out, has considerable interest in a healthy eCryptfs community, as it forms the basis for several of our cloud encryption products.  Our CEO, Larry, was thrilled by the idea, and gave Heidi (our director of marketing) financial approval to commission the new art from a professional graphic designer.

We felt that eCryptfs, as an active and vibrant open source project, deserved a logo and a mascot that reflects just that.  Everyone uses a lock or a key to represent encryption, so we thought we'd do something different.  We decided we wanted a stylized animal, in the spirit of Linux's Tux, BSD's Daemon, OpenBSD's Puffy, and of course Ubuntu's every growing zoo!

We settled on the honey badger (Mellivora capensis), inspired by its thick skin and ferocious defensive traits, much as eCryptfs adamantly defends your data against even the most determined attackers (honey badger don't care!)  We are, of course, also saluting the running honey badger Internet meme  :-)

 And the font is modern, crisp, clean, and perhaps a little "techy" even.  The "fs" is highlighted, to note the relationship to the filesystem, as well as help demonstrate the pronunciation of the word -- "ecrypt" and then "fs".

Gazzang has contributed all of this artwork to the eCryptfs project under the Creative Commons CC BY-SA 3.0 license.  We hope you enjoy it as much as we do :-)  Let us know what you think!

Now there is one piece we're still missing.  We don't yet have a name for our snarling cryptographic honey badger.  So we're putting it out to you...  Suggestions?  Drop us a comment below!

:-Dustin

Using eCryptfs and Ubuntu Encrypted Home in EC2

Admittedly, using eCryptfs and Ubuntu's Encrypted Home feature in EC2 is a bit circumlocutious.  At Gazzang, we're working on making that a bit more seamless, and a lot more secure.  But in the meantime, here are some handy instructions on how you can set it up manually for yourself.

But first, why would you want to do this?  Good question!  Bear in mind that by using EC2 and storing any data there, you're putting a considerable amount of trust in Amazon already.  They own the hardware and the hypervisor.  They are running a modified Linux/Xen kernel that you cannot even audit, if you wanted to.  They haven't released the sourced to that modified Linux kernel, so don't deceive yourself -- their instrumented kernels could be logging your every keystroke.  Hopefully not.  But you don't know that.

So what can you do?  What good is eCryptfs here?  Well, if you transparently read and write your data through an eCryptfs encryption/decryption layer, you can add a measurable amount of confidence and security that your data will at least be encrypted when it's at rest, once it lands on a spinning hard disk somewhere in an Amazon data center.  In this world of cloud trust, you're explicitly trusting Amazon to "do the right thing" and take reasonable precautions.  Amazon is huge, and has a tremendous amount to lose by acting deceptively.  But you can't say the same for every single individual between you and your data.  In other words, you don't necessarily trust every individual that might brush past your data.  Hard disks get stolen and sold on eBay, they're returned to the manufacturer for repair, donated to Goodwill or schools, recycled, repurposed, and reused.  So if you could trivially ensure that your bytes are encrypted before being written to disk, would you?  Well, as you see below, it's not quite trivial yet, but it is very much possible.  Stay tuned here and watch this area of technology evolve.  In the meantime, give this a shot...

First, start an Ubuntu VM in EC2.  I use the cloud-sandbox command from lp:bikeshed.  I'm sure you have your own methods.

Next, SSH into your new VM and install ecryptfs-utils.

sudo apt-get install ecryptfs-utils

Next, you must set a login password for the Ubuntu user.  Note that you do not have to enable PasswordAuthentication in /etc/ssh/sshd_config (though you might choose to).  As always, make sure you choose a strong passphrase.  I recommend at the very least 12 characters, with upper case, lower case, and numbers.  You know how to choose a good password.  The more important it is that your data stay private, the better the password should be ;-)

sudo passwd ubuntu

Exit byobu, or any other programs you might be running as your ubuntu user, and change out of your $HOME directory, and migrate your home directory.  However, if you've encrypted all of your $HOME, you MUST move your .ssh directory out, so that your authorized keys file is not encrypted!!!  Make sure you run all of the following commands sequentially, and without terminating your SSH connection, or else you might find yourself locked out of your instance :-)

cd / ; sudo ecryptfs-migrate-home -u ubuntu

sudo ln -s /home/.ecryptfs/ubuntu/.ssh $HOME/
su - ubuntu
ecryptfs-mount-private
cd $HOME
mv $HOME/.ssh /home/.ecryptfs/ubuntu/
ln -s /home/.ecryptfs/ubuntu/.ssh $HOME/

If that completes successfully, we can clean up our backup of our unencrypted home directory.

sudo rm -rf /home/ubuntu.*

Alternatively, might might choose just to encrypt one private directory, instead of migrating all of your home.  To do so, use:

ecryptfs-setup-private

Finally, we will want to be prompted for our login password at every login to automatically mount our home directory, so let's also create a ".profile" in our unencrypted home directory.

ecryptfs-umount-private
echo "ecryptfs-mount-private; . $HOME/.profile; cd" | sudo tee $HOME/.profile
ecryptfs-mount-private

Alright!  At this point, we should be able to exit all of our shells and SSH back into our EC2 instance.  The SSH public key authentication will get us onto the machine, and then our .profile script should prompt us for our login passphrase and automatically mount our encrypted home directory.

The data that actually gets written to your root ext4 filesystem on /dev/xvda1 are the files that you can find in /home/.ecryptfs/ubuntu/.Private/, which should look something like this:

ubuntu@ip-10-194-246-143:~$ ll /home/.ecryptfs/ubuntu/.Private/
total 68
drwx------ 3 ubuntu ubuntu  4096 Dec 22 18:54 ./
drwxr-xr-x 5 ubuntu ubuntu  4096 Dec 22 18:46 ../
lrwxrwxrwx 1 ubuntu ubuntu   124 Dec 22 18:42 ECRYPTFS_FNEK_ENCRYPTED.FWbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHi1R07VV4a9quAsP3ATb2JK--- -> ECRYPTFS_FNEK_ENCRYPTED.FYbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHiSRA-6SgbLQ.LtWP2pwGZY57PtU2wAgzLn-ECMilfrp9dp0YUYlTDNwY6P764.gPo
-rw-r--r-- 1 ubuntu ubuntu 12288 Dec  1 12:50 ECRYPTFS_FNEK_ENCRYPTED.FWbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHi9KCXyAtK1PsV4KirBxb8fk--
drwx------ 2 ubuntu ubuntu  4096 Dec 22 17:32 ECRYPTFS_FNEK_ENCRYPTED.FWbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHicFvfubbvnebsd2N8jh9vRU--/
-rw-r--r-- 1 ubuntu ubuntu 12288 Dec  1 12:50 ECRYPTFS_FNEK_ENCRYPTED.FWbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHifCuJCnlfaXjU4QlrUWfhIU--
-rw-r--r-- 1 ubuntu ubuntu 12288 Dec  1 12:50 ECRYPTFS_FNEK_ENCRYPTED.FWbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHiNgxmEEQUk9nI3uOlsQkCHk--
lrwxrwxrwx 1 ubuntu ubuntu   104 Dec 22 18:42 ECRYPTFS_FNEK_ENCRYPTED.FWbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHipvXKHoAMUybcfPOQYgm1WE-- -> ECRYPTFS_FNEK_ENCRYPTED.FXbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHif.b7-V31EJPzRLnx.vfW9dIwfbnZuIcdSIqqNTvonyo-
lrwxrwxrwx 1 root   root     104 Dec 22 18:54 ECRYPTFS_FNEK_ENCRYPTED.FWbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHisXvcg5obbXbibbufq7QjyE-- -> ECRYPTFS_FNEK_ENCRYPTED.FXbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHiGNrAq2Ud8N9P5xVz2YssSWo-.u4wRtBbZLQLIeG-0I2-
-rw-r--r-- 1 ubuntu ubuntu  8192 Dec 22 17:32 ECRYPTFS_FNEK_ENCRYPTED.FXbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHivZ3-rM86jHHkrHcJAXqMkfoOaMkowIPainVLMFWajCg-

This is what you're hoping your attacker, the unsavory individual who comes into contact with one of those magic cloud hard drives containing your data, sees.  These are the encrypted file names, and the file contents are just as unreadable without the necessary keys!

Enjoy,
:-Dustin

Released ecryptfs-utils 94 and 95

Howdy!

I've done quite a bit of work in the last few days to get on top of the eCryptfs bug backlog.  I've managed to at least triage all of the upstream New/Undecided bugs, and managed to digest all of the High/Medium/Low ones. I haven't gotten to the Wishlist ones yet, but I'll do so soon.  Next week, I'll try to tackle the Ubuntu ecryptfs-utils bug backlog and do the same (triage New/Undecided, and process High/Medium/Low).

In doing so, I've fixed a handful of bugs, tested, and released ecryptfs-utils-94 and ecryptfs-utils-95.  These have been uploaded to Ubuntu precise already, and other distros can find the release tarballs here.

The release notes are below.  Thanks to Tyler for help with the testing, and to all of the contributors noted below.  Happy Crypting!

ecryptfs-utils (95-0ubuntu1) precise; urgency=low

  [ Serge Hallyn ]
  * fix infinite loop on arm: fgetc returns an int, and -1 at end of
    options.  Arm makes char unsigned. (LP: #884407)

  [ Dustin Kirkland ]
  * debian/compat, debian/control, debian/ecryptfs-utils.install,
    debian/ecryptfs-utils.lintian-overrides,
    debian/libecryptfs0.install, debian/libecryptfs-dev.install,
    debian/lintian/ecryptfs-utils, debian/python-ecryptfs.install,
    debian/rules, debian/source/options, doc/ecryptfs-pam-doc.txt,
    doc/manpage/ecryptfs-setup-private.1, lintian/ecryptfs-utils, ===
    removed directory debian/lintian:
    - merge a bunch of packaging changes from Debian's Daniel Baumann
  * scripts/release.sh:
    - minor release fixes

 -- Dustin Kirkland   Wed, 14 Dec 2011 14:21:34 -0600

ecryptfs-utils (94-0ubuntu1) precise; urgency=low

  [ Dustin Kirkland ]
  * scripts/release.sh:
    - fix release script
    - bump ubuntu release
  * doc/manpage/ecryptfs-recover-private.1, src/utils/ecryptfs-migrate-
    home (properties changed: -x to +x), src/utils/ecryptfs-recover-
    private:
    - add a --rw option for ecryptfs-recover-private
  * src/utils/ecryptfs-migrate-home: LP: #820416
    - show progress on rsync
  * debian/ecryptfs-utils.ecryptfs-utils-restore.upstart,
    debian/ecryptfs-utils.ecryptfs-utils-save.upstart,
    src/utils/ecryptfs-migrate-home,
    src/utils/ecryptfs-setup-private: LP: #883238
    - remove 2 upstart scripts, which attempted to "save" users who didn't
      login after migrating their home; instead, we now require the root
      user to enter user passwords at migration time
  * debian/copyright, debian/ecryptfs-utils.ecryptfs-utils-
    restore.upstart, debian/ecryptfs-utils.ecryptfs-utils-save.upstart,
    doc/manpage/ecryptfs.7, doc/manpage/ecryptfs-add-passphrase.1,
    doc/manpage/ecryptfs-generate-tpm-key.1, doc/manpage/ecryptfs-
    insert-wrapped-passphrase-into-keyring.1, doc/manpage/ecryptfs-
    mount-private.1, doc/manpage/ecryptfs-recover-private.1,
    doc/manpage/ecryptfs-rewrap-passphrase.1, doc/manpage/ecryptfs-
    rewrite-file.1, doc/manpage/ecryptfs-setup-private.1,
    doc/manpage/ecryptfs-setup-swap.1, doc/manpage/ecryptfs-stat.1,
    doc/manpage/ecryptfs-umount-private.1, doc/manpage/ecryptfs-unwrap-
    passphrase.1, doc/manpage/ecryptfs-wrap-passphrase.1,
    doc/manpage/fr/ecryptfs-add-passphrase.1, doc/manpage/fr/ecryptfs-
    generate-tpm-key.1, doc/manpage/fr/ecryptfs-insert-wrapped-
    passphrase-into-keyring.1, doc/manpage/fr/ecryptfs-mount-private.1,
    doc/manpage/fr/ecryptfs-rewrap-passphrase.1,
    doc/manpage/fr/ecryptfs-setup-private.1, doc/manpage/fr/ecryptfs-
    umount-private.1, doc/manpage/fr/ecryptfs-unwrap-passphrase.1,
    doc/manpage/fr/ecryptfs-wrap-passphrase.1, doc/manpage/fr/ecryptfs-
    zombie-kill.1, doc/manpage/fr/ecryptfs-zombie-list.1,
    doc/manpage/mount.ecryptfs_private.1, doc/manpage/pam_ecryptfs.8,
    doc/manpage/umount.ecryptfs.8,
    doc/manpage/umount.ecryptfs_private.1,
    src/pam_ecryptfs/pam_ecryptfs.c,
    src/utils/ecryptfs_add_passphrase.c,
    src/utils/ecryptfs_insert_wrapped_passphrase_into_keyring.c,
    src/utils/ecryptfs-migrate-home, src/utils/ecryptfs-mount-private,
    src/utils/ecryptfs-recover-private,
    src/utils/ecryptfs_rewrap_passphrase.c, src/utils/ecryptfs-rewrite-
    file, src/utils/ecryptfs-setup-private, src/utils/ecryptfs-setup-
    swap, src/utils/ecryptfs-umount-private,
    src/utils/ecryptfs_unwrap_passphrase.c,
    src/utils/ecryptfs_wrap_passphrase.c:
    - update some email addresses, moving kirkland@canonical.com ->
      kirkland@ubuntu.com (which I can still read)
  * src/libecryptfs/key_management.c: LP: #715066
    - fix 2 places where we were handling
      ecryptfs_add_passphrase_key_to_keyring() inconsistently
    - if we're trying to add a key to the keyring, and it's already there,
      treat that as "success"
  * debian/control:
    - ecryptfs-setup-swap is strongly recommended, which depends on
      cryptsetup; so promote cryptsetup from suggests -> recommends

  [ Stephan Ritscher and Tyler Hicks ]
  * src/libecryptfs/cmd_ln_parser.c: LP: #683535
    - fix passphrase_passwd_fd for pipes
    - handle memory allocation failures
    - free memory in error paths

  [ Arfrever Frehtes Taifersar Arahesis ]
  * configure.ac: LP: #893327
    - no need to check for python, if --disable-pywrap is passed

 -- Dustin Kirkland   Thu, 27 Oct 2011 10:58:47 -0500

:-Dustin

I've Joined the Gazzang Team!

A few weeks ago, I joined a fun, new start-up company here in Austin called Gazzang.  I was a little surprised that this was published in the form of a rather flattering press release :-)  Let's just say that my Mom was very proud!

I know that some of you in the Ubuntu community are wondering how that career change will affect my responsibilities and contributions to Ubuntu.  I'm delighted to say that I'll most certainly continue to contribute to Ubuntu and many of my upstream projects.  Gazzang is quite supportive of my work in both Ubuntu and open source.

Most directly, you should see me being far more active in my regular maintenance, development, bug triage, and support of eCryptfs.  Gazzang's core business is in building information privacy and data security solutions for the Cloud.  eCryptfs is at the heart of their current products, and in my new role as Gazzang's Chief Architect, we're working on some interesting innovations in and around eCryptfs.  A healthy, high-quality, feature-filled, high-performance eCryptfs is essential to Gazzang's objectives, and I'm looking forward to working on one of my real passions in eCryptfs!

More specifically, looking at the projects I maintain, I expect to continue to be very active in:

• eCryptfs (essential to my new job)
• byobu (mostly around tmux, and because hacking on byobu is fun and awesome :-)
• manpages.ubuntu.com and manpg.es (because that's how I read manpages)
• musica (because that's how I've streamed music since 1998)
• pictor (because that's how I've managed and shared pictures since 1998)

You'll probably see opportunistic development (nothing active, but when an opportunity or bugs spring up), including the usual bzr/launchpad dance, developing, testing, upstream releasing, packaging, and uploading to Ubuntu, of:

• bikeshed (apply-patch, bch, bzrp, col*, dman, pbget, pbput, pbputs, release, release-build, what-provides, what-repo, what-source, wifi-status)
• bogosec
• bootmail, rootsign
• cloud-utils (along with smoser)
• dotdee
• errno
• kvm-ok
• run-one, run-this-one, keep-one-running
• service
• ssh-import-id
• ... (plus some new stuff I haven't released yet!)

And finally, as prescribed by the Ubuntu Code of Conduct, I'm gracefully stepping away from a few other projects I've founded or maintained in the past.  I'll help out if and when I can, but for now I've transferred all of the necessary rights, responsibilities and ownership of:

• awstrial (to Canonical ISD)
• cloud-live (to Ante Karamatic)
• cloudfoundry (to the Canonical SI Team)
• orchestra (to the Ubuntu Platform Server Team)
• powernap (to Andres Rodriguez)
• testdrive (to Andres Rodriguez)

Finally, I must say that the last 4 years have been the most amazing 4 years of my entire 12 year professional career.  It's been quite rewarding to witness the fledgling Ubuntu Server of February 2008 (when I joined Canonical), and the tiny team of 5 grow and evolve to the 20+ amazing people now working directly on the Ubuntu Server.  And that list doesn't even remotely cover the dozens (if not hundreds!) of others around Canonical and the Ubuntu Community who contribute and depend on the amazing Server and Cloud distribution that is Ubuntu.

I'm really looking forward to my new opportunities around Gazzang and eCryptfs, but you'll still most certainly see me around Ubuntu too :-)  As crooned by The Beatles...

You say "Yes", I say "No". \\ You say "Stop" and I say "Go, go, go". \\ Oh no. \\ You say "Goodbye" and I say "Hello, hello, hello". \\ I don't know why you say "Goodbye", I say "Hello, hello, hello". \\ I don't know why you say goodbye, I say hello!

 Cheers,
:-Dustinhttp://www.gazzang.com

eCryptfs in the Wild

Perhaps you're aware of my involvement in the eCryptfs project, as the maintainer of the ecryptfs-utils userspace tools...

This post is just a collection of some recent news and headlines about the project...

1. I'm thrilled that eCryptfs' kernel maintainer, Tyler Hicks, joined Canonical's Ubuntu Security Team last month!  He'll be working on the usual Security Updates for stable Ubuntu releases, but he'll also be helping develop, triage and fix eCryptfs kernel bugs, both in the Upstream Linux Kernel, and in Ubuntu's downstream Linux kernel packages.  Welcome Tyler!
2. More and more and more products seem to be landing in the market, using eCryptfs encryption!  This is, all at the same time, impressive/intimidating/frightening to me :-)
• Google's ChromeOS uses eCryptfs to securely store browser cache locally (this feature was in fact modeled after Ubuntu Encrypted Private Directory feature, and the guys over at Google even sent me a Cr48 to play with!)
• We've spotted several NAS solutions on the market running eCryptfs, such as this Synology DS1010+ and the BlackArmor NAS 220 from Seagate
• Do you know of any others?
3. I've had several conversations with Android developers recently, who are also quite interested in using eCryptfs to efficiently secure local storage on their devices.  As an avid Android user, I'd love to see this!
4. There's a company here in Austin, called Gazzang, that's developing Cloud Storage solutions (mostly database backends) backed by eCryptfs.
5. And there's a start-up in the Bay Area investingating eCryptfs + LXC + MongoDB for added security to their personal storage solution.

Exciting times in eCryptfs-land, for sure!

Which brings me to the point of this post...  We could really use some more community interaction and developer involvement around eCryptfs!

• Do you know anything about encryption?
• What about Linux filesystems?
• Perhaps you're a user who's interested in helping with some bug triage, or willing to help support some other users?
• We have both kernel, and user space bug-fixing and new development to be done!
• There's code in both C and Shell that need some love.
• Heck, even our documentation has plenty of room for improvement!

If you'd like to get involved, drop by #ecryptfs in irc.oftc.net, and poke kirkland or tyhicks.

Cheers,

:-Dustin

Introducing ecryptfs-recover-private -- Recover your Encrypted Private Directory!

Once again, this post is long, long, long overdue ;-)

I'm pleased to announce the general availability of a new utility -- ecryptfs-recover-private!

For several years now, we in the #ecryptfs IRC channel and in the eCryptfs community on Launchpad have been pointing people to this blog post of mine, which explains how to manually mount an Encrypted Home or Private directory from an Ubuntu LiveCD.

I'm quite happy to say that this is now an automated process, with the release of the Ubuntu 11.04 (Natty Narwhal) Desktop later this week!

If you find yourself in a situation where you need to recover your Encrypted Home or Encrypted Private directory, simply:

1. boot the target system using an Ubuntu 12.04 (or newer) Desktop LiveCD
2. make sure that your target system's hard drive is mounted
3. open a terminal
4. install ecryptfs-utils 'sudo apt-get install -y ecryptfs-utils'
5. and run 'sudo ecryptfs-recover-private'
6. follow the prompts
7. access your decrypted data and save somewhere else
8. you can also launch the graphical file browser with 'sudo nautilus'  and navigate to the temporary directory

The utility will do a deep find of the system's hard disk, looking for folders named ".Private", and will interactively ask you if it's the folder you'd like to recover.  If you answer "yes", you will then be prompted for the login passphrase that's used to decrypt your wrapped, mount passphrase.  Assuming you have the correct credentials, it will mount your Encrypted Home or Private directory in read-only mode, and point you at the temporary directory where it's mounted.

Here's a video demonstration...





Tossing you a life raft,
:-Dustin