Re: making encrypted $HOME as easy and convenient as possible
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey list,
Thanks to Jon for raising the topic on this list. It would be great to
enhance the disk encryption support in Debian(-Installer).
Am 13.09.2011 22:14, schrieb Jon Dowland:
> On Sun, Sep 11, 2011 at 10:46:41PM +0200, intrigeri wrote:
>> E.g. data may be written in cleartext swap, in hibernation images,
>> temporary data may be written at various places on disk that are not
>> in $HOME: cups spool, /var/tmp, etc.
>
> That's true. But there are varying levels of risk: a fully-unencrypted system
> has all data vulnerable to anyone who obtains the hard drive. The risk of data
> being recovered from an unencrypted swap partition or hibernation image is much
> lower: not recovering *any* data, I mean; recovering *sensitive* data. The
> hibernation image is the more worrying case, I think: unless the act of
> hibernating could re-lock a password manager in memory such as gnome-keyring…
Actually temporary data is sensitive in many cases.
I consider the ubuntu option to encrypt only the home directory as a bad
solution. At least they should warn the user that sensitive data may be
written to unencrypted parts of the disk.
On the other hand I see that full disk encryption might not be the best
solution for everyone. Especially with cheap and old hardware, encrypted
system disks slow down the system a lot.
But in case that only parts of the disk are encrypted, at least some
caution should be taken to secure the setup. two things come into my
mind right now:
- - either encrypt temp folders like /tmp, /var/tmp or mount as ramfs
- - encrypt or disable swap (e.g. using encrypted image files)
>> The d-i already supports easy *full* system encryption, swap included.
>
> I'll have to double-check to see whether I agree with you about 'easy': at
> least in comparison to ticking a single box, once! Certainly 'not very hard'.
> (not meaning to undermine or criticise the hard work of d-i hackers here).
It's not easy to find the best solution for all use cases: is it in the
interest of our users to support weak setups that provide *some*
security, with unpredictable drawbacks? Or should we rather enhance the
support for setups that we consider as secure enough to not fool the
users with a sense of false security? Or both?
> For a single-user system, is it possible to pass through the decryption
> password to later processes, to avoid needing to provide another password to
> log in? I know you could set your display manager to auto-login, but that
> doesn't get you an unlocked keyring.
This is not possible out of the box. But there already is a tool for
this: tokentube[1]. Unfortunately it's not packaged for Debian yet, but
a RFP bugreport[2] does exist.
> Same question for multi-user systems. In the multi-user case, I'm fairly sure
> it's possible to have multiple decryption pass-phrases. However in that case,
> you would probably want a different encryption key for / as for each user's
> $HOME. Otherwise, each user could decrypt each other's stuff: and the weakest
> pass-phrase would be the weak-point for all users.
For multi-user systems encrypted home folders indeed make sense. I share
your concerns regarding one big encrypted rootfs for all users. My
suggestion would be to encrypt the rootfs and encrypt the home folders
indepently. Tokentube still would be the way to go: a user enters
her*his credentials at boot time, these are used to unlock the rootfs,
to unlock the users home folder, to login the user and to unlock the
keyring.
>> In some threat models, this offers a much greater protection than
>> encrypting $HOME only. I think the specific usecases and threat models
>> that make $HOME -only encryption more fit and desirable should be
>> clearly defined before we look for a solution. What do you think?
>
> I agree. The reasons $HOME-only are more desirable are not to do with them
> safer, but more convenient. Can we make full-disk encryption more convenient?
> Or can we make $HOME-only encryption safer? Or perhaps a frank statement of
> risk?
I believe that this is possible. The installer already supports
automatic partitioning with full encryption. What is needed is automatic
encryption for custom partition schemes (fur sure they would need to
fullfill the requirements like seperate boot partition, etc.)
Another solution would be to wait for the luks support in grub2 [3],
which would obsolete the need for a seperate boot partition.
Greetings,
jonas
[1] http://sourceforge.net/projects/tokentube/
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502772
[3] http://lists.gnu.org/archive/html/grub-devel/2011-01/msg00085.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOb8wTAAoJEFJi5/9JEEn+BAsQAKPMU2x/uiROeN8ZrRheIn4a
gJKpSHwMk/mBD0eEUbYVSSMPKVUjYwylMPQaCBEVa0U3o7WWeawn+uzKZoSYXIe/
TGkHnS3fvgjSO51aTC5bFrcrP+Ym6dpp3Y6Vy7hAz66tQSd6Qymh1lkuxKloOd+b
qGFHkHEjIsNrs+VmaHwuyrp5KenDws+rsjK1pMzVAP4rFRiaS9/Rh4U7oomcJQAX
fCMhYJ0dsFqEQaQXh7f0ugByEI2E96MJLOw01wqICfwYEv5dmBjbmrtjEhJBEgnv
/yClV8gYD/ZQiv+37uLLYqP7pmRkbiLh1YB+vWB49fs8165KEnVgH8lcS4V0xote
2/M0agu4iXOKViJ4pjhcLAI2e+i/LPGMOs0CGbWrZ3eiPYKI2GBw9oK7gy8zk+/q
th9aSJDcgVVqo+Hf79+hAx65Ohrf9SDx7vxE3McNmYPwZB7BGYqDj2go1AAWyBeU
dZ+IOFL2q6m0zf6ehKSaEcx31ggxBquxlxaNLVmsdQ0JWyGrLdlpMSmndIJRbT/T
DV5ArP3MxLt0YHWza05GkeuETHOCq8TRKsC+YYSReLeaHad4F9xgtxlEHwbfJ15F
N7V/pw4ntlMfow+waYhtb7VAfuxRX13euyktuxuHEYWs+XCqlFe4tRRx26LQmBA5
Ovqg6W3w8MipWqvql8Tz
=S9+3
-----END PGP SIGNATURE-----
Reply to: