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… > 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). 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. 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. > 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? -- Jon Dowland -- 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/20110913201439.GA10715@pris
