Support for geli onetime encryption for /tmp?

[Gleb Kurtsou]

On (12/12/2009 23:07), Daniel Thiele wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi,
> 
> I am contentedly using a onetime encrypted swap partition through
> the means provided by rc.d/encswap and fstab, i.e. appending '.eli'
> to the swap partition's name. Since some of the things that accumulate
> in /tmp over the time may contain confidential information, I would
> like to encrypt this partition, too. I know of the clear_tmp_enable
> rc.conf option, but this only deletes /tmp's contents simply by
> utilizing rm(1), which helps but I would not consider this as a
> sufficient solution for the problem of making no longer needed
> /tmp-data unaccessible. So, unless I am missing something, currently
> the only way to go seems to be utilizing geli together with a
> passphrase (and a secret key). Now, for /tmp being a file systems
> for which no guarantee towards persistence across reboots is needed,
> a onetime encryption seems to be the better choice, e.g. no one can
> force you to give away the passphrase or key file.
I'd suggest you trying a stackable cryptographic file system (pefs)
developed as a google summer of code project this year.
Think of it as of nullfs + encryption. No need to create/use separate
partition, etc.

You can create one time passwords on boot and let rc.d scripts clean old
staff:
# pefs mount /tmp /tmp
# dd if=/dev/random bs=16 count=1 | pefs addkey -pv -k - /tmp

I use it to encrypt my home directory for some time already, works
pretty good. It also works on top of tmpfs, if anybody needs it :)

More info: http://gleb.blog.com/tag/pefs/
Recent sources on github: http://github.com/glk/pefs

> While I was looking for a solution, I stumbled upon a patch
> (conf/102700, link below) from 2006 by Shaun Amott (CC'ed) that
> adds support for exactly this kind of encryption. Is there a reason
> why this patch has not made it into the base system yet? I think it
> would be a valuable addition to FreeBSD in regard to security. In
> that context it may be even better to enhance the patch to not only
> support onetime encryption for /tmp, but any kind of file system,
> which a user may specify via fstab. Then, however, the issue of how
> to exactly distinguish between onetime and normal encryption in
> fstab needs to be solved.
> 
> Is there maybe another way to achieve onetime /tmp encryption that
> I am missing? Preferably one that does not involve huge changes to
> the default config files to minimize the time spent mergmaster-ing
> these files during an update. This last point is basically what keeps
> me from applying conf/102700 locally or implementing my own solution.
> 
> 
> Kind regards,
> Daniel