making encrypted $HOME as easy and convenient as possible

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

making encrypted $HOME as easy and convenient as possible

Jonathan Dowland
I like encrypted $HOME and making the use of them as easy for people
as possible.

On creation of the first user, Ubuntu's installer offers a checkbox
labelled something like "Encrypt the user's files".  That's it: just
one check-box. If set, upon login, a PAM module unlocks and mounts a
loopback device over the user's $HOME location, transparently.

On Debian I have achieved this for some time using dm-crypt/LUKS + the
excellent support for the two (and LVM) in d-i.  I then supplant that
with libpam-mount.  The result works,  but has drawbacks:  manual
configuration of libpam-mount;  unpredictable fscks with no visual
feedback; some bugs with concurrent logins; unreliable
unmount-on-logout; etc.

One difference between these two schemes is that Ubuntu's scheme is
orthogonal to whether /home or /home/foo is a distinct partition from
/.  This, IMHO, is a good thing:  novice users need not enter the
(sometimes confusing) world of partitioning: legacy DOS partition
table limitations; or schemes like LVM.  Sometimes I don't care to
have $HOME separate from / myself (except to achieve encryption).

I think it would be wonderful to have such ease-of-use $HOME
encryption in Debian.  Ubuntu's scheme uses ecryptfs.  Before I begin
looking into how best I might help work towards this, I was wondering
if experienced people could weigh in with advice on whether ecryptfs
is likely to be the most sensible way to achieve the desired result,
or is something else worthy of consideration?


Thanks,

--
Jon Dowland


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20110911132337.GA5608@pris

Reply | Threaded
Open this post in threaded view
|

Re: making encrypted $HOME as easy and convenient as possible

intrigeri-3
Hi,

Jon Dowland wrote (11 Sep 2011 13:23:37 GMT) :
> I like encrypted $HOME and making the use of them as easy for people
> as possible.

So do I.

However, before we go deep into implementation details, I need to ask
what kind of usecase(s) and threat model(s) you have in mind and are
trying to solve.

When discussing such matters, one needs to be aware of the drawbacks
of encrypting $HOME only; one of these drawbacks can be summed up as:

  any data stored in your encrypted $HOME has non neglictible chances
  to be written in cleartext on the disk at some point, and stay
  there, recoverable by standard forensics tools, during a more or
  less long time.

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.

The d-i already supports easy *full* system encryption, swap included.
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?

Bye,
--
  intrigeri <[hidden email]>
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
  | Do not be trapped by the need to achieve anything.
  | This way, you achieve everything.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/85wrdeq026.fsf@...

Reply | Threaded
Open this post in threaded view
|

Re: making encrypted $HOME as easy and convenient as possible

martin f krafft
also sprach intrigeri <[hidden email]> [2011.09.11.2246 +0200]:
> The d-i already supports easy *full* system encryption, swap
> included.

I think this is what people should be using, not a high-level hack
like ecryptfs.

However, I suppose you can only set this up during installation, and
converting a system later is not trivially possible. Or is it?

--
 .''`.   martin f. krafft <[hidden email]>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"the strength of women comes from the fact
 that psychology cannot explain us.
 men can be analyzed, women merely adored."
                                                        -- oscar wilde

digital_signature_gpg.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: making encrypted $HOME as easy and convenient as possible

Rolf Kutz-2
On 12/09/11 06:50 +0200, martin f krafft wrote:
>also sprach intrigeri <[hidden email]> [2011.09.11.2246 +0200]:
>> The d-i already supports easy *full* system encryption, swap
>> included.
>
>I think this is what people should be using, not a high-level hack
>like ecryptfs.

There might be different use cases. An encrypted
/home can still be backuped easily by
administrators without being able to see inside.

regards
Rolf

--
... And there comes a time when one must take a position that is neither
safe, nor politic, nor popular but one must take it because one's
conscience tells one that it is right. — Martin Luther King, Jr.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20110912074111.GB19003@...

Reply | Threaded
Open this post in threaded view
|

Re: making encrypted $HOME as easy and convenient as possible

martin f krafft
also sprach Rolf Kutz <[hidden email]> [2011.09.12.0941 +0200]:
> There might be different use cases. An encrypted /home can still
> be backuped easily by administrators without being able to see
> inside.

True. At the same time, it exposes quite a lot of information, e.g.
structure of the tree. I don't know how much of that could be used
in a plain-text attack.

Note, however, that I don't really know ecryptfs. I only briefly
looked at encfs and was horrified by some of its design choices.
Maybe ecryptfs is better. Meanwhile, however, I chose to stay with
dm-crypt, which simply seems saner.

--
 .''`.   martin f. krafft <[hidden email]>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
people with narrow minds usually have broad tongues.

digital_signature_gpg.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: making encrypted $HOME as easy and convenient as possible

Rolf Kutz-2
On 12/09/11 10:12 +0200, martin f krafft wrote:
[ecryptfs as /home]
>True. At the same time, it exposes quite a lot of information, e.g.
>structure of the tree. I don't know how much of that could be used
>in a plain-text attack.

Ack.

>Note, however, that I don't really know ecryptfs. I only briefly
>looked at encfs and was horrified by some of its design choices.
>Maybe ecryptfs is better. Meanwhile, however, I chose to stay with
>dm-crypt, which simply seems saner.

I use ecryptfs when storing files on a 3rd party
server, like dropbox and full disk encryption with
luks and dm-crypt for my laptop and workstation.
They are there for different use cases.

regards
Rolf

--
Cowardice asks the question, 'Is it safe?' Expediency asks the question, 'Is it
politic?' Vanity asks the question, 'Is it popular?' But, conscience asks the
question, 'Is it right?' And there comes a time when one must take a position
that is neither safe, nor politic, nor popular but one must take it because
one's conscience tells one that it is right. — Martin Luther King, Jr.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20110912083206.GC19003@...

Reply | Threaded
Open this post in threaded view
|

Re: making encrypted $HOME as easy and convenient as possible

Luca Capello
In reply to this post by martin f krafft
Hi there!

On Mon, 12 Sep 2011 06:50:29 +0200, martin f krafft wrote:
> also sprach intrigeri <[hidden email]> [2011.09.11.2246 +0200]:
>> The d-i already supports easy *full* system encryption, swap
>> included.
>
> I think this is what people should be using, not a high-level hack
> like ecryptfs.

+1, but if you use dm-crypt I still have not understood if SSD TRIM
could be supported or not:

  <http://www.saout.de/pipermail/dm-crypt/2010-April/000742.html>
  <http://www.saout.de/pipermail/dm-crypt/2010-August/001155.html>
  <http://sourceforge.net/tracker/index.php?func=detail&aid=2997551&group_id=136732&atid=736684>

JFTR, the configuration of my 80GB SSD is a separate 200MB /boot, then
everything else including swap as dm-crypt+LVM (except the last 5GB for
paranoid reasons), working like a charm with hibernation as well:

  <http://bugs.debian.org/600671>

Thx, bye,
Gismo / Luca

attachment0 (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: making encrypted $HOME as easy and convenient as possible

Philipp Kern-4
On 2011-09-12, Luca Capello <[hidden email]> wrote:
> On Mon, 12 Sep 2011 06:50:29 +0200, martin f krafft wrote:
>> also sprach intrigeri <[hidden email]> [2011.09.11.2246 +0200]:
>>> The d-i already supports easy *full* system encryption, swap
>>> included.
>> I think this is what people should be using, not a high-level hack
>> like ecryptfs.
> +1, but if you use dm-crypt I still have not understood if SSD TRIM
> could be supported or not:

Apparently it's merged into 3.1.  You might need to use dmsetup in the meantime
to set allow_discard.  (See the kernel documentation bits for dm-crypt and
[0]).

Kind regards
Philipp Kern

[0] http://www.saout.de/pipermail/dm-crypt/2011-July/001825.html


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/slrnj6ri58.n1t.trash@...

Reply | Threaded
Open this post in threaded view
|

Re: making encrypted $HOME as easy and convenient as possible

Luca Capello
Hi there!

On Mon, 12 Sep 2011 10:54:00 +0200, Philipp Kern wrote:
> On 2011-09-12, Luca Capello <[hidden email]> wrote:
>> On Mon, 12 Sep 2011 06:50:29 +0200, martin f krafft wrote:
n>>> also sprach intrigeri <[hidden email]> [2011.09.11.2246 +0200]:

>>>> The d-i already supports easy *full* system encryption, swap
>>>> included.
>>> I think this is what people should be using, not a high-level hack
>>> like ecryptfs.
>> +1, but if you use dm-crypt I still have not understood if SSD TRIM
>> could be supported or not:
>
> Apparently it's merged into 3.1.  You might need to use dmsetup in the meantime
> to set allow_discard.  (See the kernel documentation bits for dm-crypt and
> [0]).
Thank you for the news!

Something I completely forgot in my first email, which is the real
question: are my data as much secure with SSD TRIM as without?

Thx, bye,
Gismo / Luca

attachment0 (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: making encrypted $HOME as easy and convenient as possible

Jonas Meurer
Hey list,

Am 12.09.2011 12:55, schrieb Luca Capello:

> On Mon, 12 Sep 2011 10:54:00 +0200, Philipp Kern wrote:
>> On 2011-09-12, Luca Capello <[hidden email]> wrote:
>>> On Mon, 12 Sep 2011 06:50:29 +0200, martin f krafft wrote:
> n>>> also sprach intrigeri <[hidden email]> [2011.09.11.2246 +0200]:
>>>>> The d-i already supports easy *full* system encryption, swap
>>>>> included.
>>>> I think this is what people should be using, not a high-level hack
>>>> like ecryptfs.
>>> +1, but if you use dm-crypt I still have not understood if SSD TRIM
>>> could be supported or not:
>>
>> Apparently it's merged into 3.1.  You might need to use dmsetup in the meantime
>> to set allow_discard.  (See the kernel documentation bits for dm-crypt and
>> [0]).
>
> Thank you for the news!
>
> Something I completely forgot in my first email, which is the real
> question: are my data as much secure with SSD TRIM as without?

No, they're not. Milan Broz, upstream author of cryptsetup and linux
device-mapper/dm-crypt hacker wrote a very good article about that topic
recently:

http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html

Greetings,
 jonas


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/4E6DE782.7010104@...

Reply | Threaded
Open this post in threaded view
|

Re: making encrypted $HOME as easy and convenient as possible

Luca Capello
Hi there!

On Mon, 12 Sep 2011 13:05:38 +0200, Jonas Meurer wrote:
> Am 12.09.2011 12:55, schrieb Luca Capello:
[TRIM support for dm-crypt merged into Linux 3.1]
>> Something I completely forgot in my first email, which is the real
>> question: are my data as much secure with SSD TRIM as without?
>
> No, they're not. Milan Broz, upstream author of cryptsetup and linux
> device-mapper/dm-crypt hacker wrote a very good article about that topic
> recently:
>
> http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html

Thank you very much for the link and the answer, which I was in some way
expecting.

Thx, bye,
Gismo / Luca

attachment0 (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: making encrypted $HOME as easy and convenient as possible

Jeremy Stanley
In reply to this post by Rolf Kutz-2
On Mon, Sep 12, 2011 at 09:41:12AM +0200, Rolf Kutz wrote:
[...]
> An encrypted /home can still be backuped easily by administrators
> without being able to see inside.

An administrator (assuming by administrator you mean root or an
account with access to root-level privs) can easily trojan the
necessary bits of the system and then lie in wait to capture the
authentication credentials or the decrypted data itself, unless
encryption and decryption is only ever done on a separate remote
system to which the administrator has no privileged access.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP([hidden email]); FINGER([hidden email]);
MUD([hidden email]:6669); IRC([hidden email]#ccl); }


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20110912204325.GH1369@...

Reply | Threaded
Open this post in threaded view
|

Re: making encrypted $HOME as easy and convenient as possible

Jonathan Dowland
In reply to this post by intrigeri-3
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20110913201439.GA10715@pris

Reply | Threaded
Open this post in threaded view
|

Re: making encrypted $HOME as easy and convenient as possible

Jeremy Stanley
On Tue, Sep 13, 2011 at 09:14:39PM +0100, Jon Dowland wrote:
[...]
> Can we make full-disk encryption more convenient?
[...]

I'm not sure it could be any more convenient than it already is to
configure, at least as far as D-I is concerned. It has a
partitioning option or two which are guided with full-disk
encryption, so pretty much fire-and-forget.

About the only ease of use issue I have is that I'd like to get
keyfile-on-a-USB-stick working with the default initrd scripts. I've
seen a few examples in circulation already, it's just a matter of
finding the time to test them.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP([hidden email]); FINGER([hidden email]);
MUD([hidden email]:6669); IRC([hidden email]#ccl); }


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20110913202549.GI1369@...

Reply | Threaded
Open this post in threaded view
|

Re: making encrypted $HOME as easy and convenient as possible

Jonas Meurer
In reply to this post by Jonathan Dowland
-----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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/4E6FCC1A.907@...

Reply | Threaded
Open this post in threaded view
|

Re: making encrypted $HOME as easy and convenient as possible

Josselin Mouette
In reply to this post by Jonathan Dowland
Le mardi 13 septembre 2011 à 21:14 +0100, Jon Dowland a écrit :
> 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.

If your filesystem is encrypted, you can setup a password-less 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.

I think this is mostly a non-issue. What use case are you trying to
address precisely?

--
 .''`.      Josselin Mouette
: :' :
`. `'
  `-

signature.asc (197 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: making encrypted $HOME as easy and convenient as possible

Wouter Verhelst
In reply to this post by Jonathan Dowland
On Sun, Sep 11, 2011 at 02:23:37PM +0100, Jon Dowland wrote:
> I think it would be wonderful to have such ease-of-use $HOME
> encryption in Debian.  Ubuntu's scheme uses ecryptfs.  Before I begin
> looking into how best I might help work towards this, I was wondering
> if experienced people could weigh in with advice on whether ecryptfs
> is likely to be the most sensible way to achieve the desired result,
> or is something else worthy of consideration?

Yes: full-disk encryption is better than homedir encryption.

The reason is that the idea that all your data resides in your $HOME is
a fallacy. Maybe you've got a database installed, which means you've got
significant gobs of data in /var. The actual packages you've got
installed on your machine will leak some information, too. Most
importantly, temporary files get written to your /tmp, and if that's a
mounted partition, anyone who knows how to retrieve removed files (which
really isn't all that hard) can get, say, the contents of most files
you've been editing over the last few days/weeks/months (depending on
free disk space).

You might think that the above is overly paranoid, but then why go
through the effort of encrypting at all if you're going to leave such
glaring holes in the system?

And guess what, Debian already supports installing with full-disk
encryption.

--
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a

signature.asc (853 bytes) Download Attachment