-----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----- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e6fcc1a....@freesources.org
