Encrypted file systems

"Official" abstract, from the BoF web site:

Me

About me: I work at
XPonCard A/S
Telecom R&D division: Systems administrator, software developer, release manager.

ToC

• Disclaimers and introductory notes
• Why
• FUSE+EncFS
• Swap
• /tmp, /var/tmp
• Performance
• Alternatives

Slides available at http://troels.arvin.dk/sslug/bof2006/

Disclaimers and introductory notes

• I'm not a crypto expert.
• In January, Henrik Grove gave a presentation about Setting up an encrypted root file system.
• My offspring cardinality recently doubled.
  

Why

One (and only one?) objective: Keep data private in case of theft.

(Many people—even in the IT business—seem to believe that data are 100% protected by a good OS login password.)

(Grove also mentioned: nerd value.)

Means: Not so relevant for servers?

How — the live example

Wanted: An encrypted sub-directory of home directory on my laptop.

• ~/.encrypted-private will be storing the encrypted data (what the thief gets)
• ~/private will contain the decrypted data, when mounted.

Will use FUSE+EncFS.

Will talk about other options later.

How — the live example — part II

• yum -y install fuse-encfs (From Fedora Extras.)
• usermod -aG fuse troels
• encfs ~/.encrypted-private ~/private
• To unmount: fusermount -u ~/private

But!

What about

• swap
• temporary files (/tmp and /var/tmp)

Swap

Swap is easy: Create a new, (LUKS-)encrypted swap area on every boot, with a randomly generated key.

Probably troublesome if used for hibernation, etc. Should probably remove "Suspend" menu and button options.

Relevant commands:
cryptsetup -d /dev/random create swap /dev/hda3 &&\
  mkswap /dev/mapper/swap

/tmp

The contents of /tmp after a runlevel 1 boot:

The contents of /tmp after a runlevel 5 boot and an ssh access:

/tmp — part II

Giving /tmp normal (0755) directory permissions:

• System boots without hiccups, but
• in runlevel 3, users can log in to a console, but startx yields a hanging, empty GUI
• in runlevel 5, users cannot log in (session ends immediately)
• ssh X forwarding broken

/tmp — part III

Idea: Use shared memory (tmpfs).
Means: Nothing stays between reboots; probably OK for a workstation.

In fstab:
  tmpfs /tmp tmpfs defaults 0 0

Beware: SELinux. /tmp needs context system_u:object_r:tmp_t

/var/tmp

/var/tmp is used for:

• Building RPM packages, if you build them as root (don't!)
• By Konqueror, it seems. == Potentially heaps of bytes in shared memory. Hopefully, there is a way to make KDE use a ~/tmp directory instead(?)
• ...?...

My suggestion: Treat it as /tmp, or make it a link or a binding mount to—e.g.—/tmp

Easy?

Quoting from abstract:

Luckily, by now, it is really easy for Linux users to make use of encrypted file systems.

Hmm. Does anyone know about GUI integration?

Performance

Benchmark at Tom's Hardware:

• LUKS (which I'm using for swap) almost on par with native performance
• FUSE+EncFS much, much slower

Alternatives

• Encryption in the disk. Products from Seagate, Hitachi. Requires suitable BIOS.
• Full-Disk Encryption (FDE) / Encrypted root FS: All but bootstrapping encrypted. Can be a pain.
• FUSE+CryptoFS, like FUSE+EncFS.
• FUSE+EncFS or FUSE+CryptoFS, but with complete home directories. May be done by clever use of PAM (pam_script package). Beware: Password changes must propagate.
• Upcoming (slated for Kernel 2.6.19): eCryptfs.

Further...

• What did I forget?
• What are people's long-term experiences?
• What's the status of LUKS/FUSE/... on other distributions?
• And how about {Free,Open}BSD?

The End

The End.

Ugly, unfinished init-script.