Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 12 Dec 2009 23:07:58 +0100
From:      Daniel Thiele <dthiele@gmx.net>
To:        freebsd-current@freebsd.org
Cc:        shaun@FreeBSD.org
Subject:   Support for geli onetime encryption for /tmp?
Message-ID:  <4B24143E.2060803@gmx.net>

next in thread | raw e-mail | index | archive | help
-----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.

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



conf/102700: http://www.freebsd.org/cgi/query-pr.cgi?pr=102700&cat=conf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJLJBQ3AAoJEB+84OrFyizNoZgQAICpe+vPcU3RAkZwVw1bUwCH
HD42SUUg8CX2t21dBsZLYLTzfdP5A3Bkwo2BhlEQtEd9OJrWD9blFbXU88/z1P+V
J0xXL3HNfJU+ufwi7D7sSBclnwrERpMhtxCzyO95bI/CqCdbYvdrfdOGX4L05jkO
nILa/wsL1qp1a6/c1LYbqDWuY2OGLNX7YiQi8yevioADXjBkTQWSaCExCZTfqRGx
y8CaMdjagQrPoYU02x4CxCt7txUZH0NlYdMGO4qTx6rrNZmIZDyxvtkZYGLqx/XF
o+FR9zciXKGQupBgQrp4mtNLObifmP/cKRgbEwI9sj+EZcnkR2RAoXZDH0TRyVxe
y52evOk4ljy2Lupc85eWVhiiR8E0sBdoyHMKbkBdMjP46aFJT1JTqPpZMCQf5lgc
gMY/TgTXr8sM9XsdJUZxzUK8MbRtx/S0yh5okl44/pF9CwfYFI0DPzOX3NTueaEK
da2C85MQ1ZQtTuvsO2pAf7nkHhOuSbT7kmWPWVVrNMkZAOmZR3igkQTF7fSBosVI
e7j56k2qWzv9hjB6uEjnjvtxmbuqXDgShIDuhw1LGIu3YH4TyGKAVXphUXM7dZ8p
t1ZJ+yeLMw+domat8ExQ4EKsUB2/iF2hiSNDRHQsTz0rTsSWFfkHT462DEmyNqM4
iCMhtsEoW9QwzQ1XwlQR
=Kh0d
-----END PGP SIGNATURE-----



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B24143E.2060803>