Inadvertent opening of encrypted dir

[markb]

I've found what I think is quite a significant bug in ecryptfs. I am a user who has auto-login enabled so it means that ecryptfs correctly (as designed) does not automatically mount ~/.Private/. I've discovered that any time you use "sudo" that your password get installed in the kernel keyring and your ~/.Private dir becomes automatically available to be mounted merely by (anybody) clicking on the standard "Access your Private data" link. No password/passphrase is then required to be explicitly entered to open your private dir. The same problem applies even if you don't use auto-login - you may think you have closed off private access with ecryptfs-umount-private but a simple sudo somewhere else makes your private directory available again without entering a password.

It is un-reasonable and dangerous that a typical naive user should have to be aware that he has exposed his private dir just because he did an sudo somewhere completely unrelated. There should be no correlation between sudo and this ecryptfs functionality.

I'm using ecryptfs-utils version 73-0ubuntu6 on jaunty.

[Dustin Kirkland  (kirkland)]

This was fixed in ecryptfs-utils-74.

    - pam_ecryptfs.c: don't try to unwrap key for users not using pam mounting

:-Dustin

[markb (mark-blakeney)]

I added Dustin's PPA and confirmed this is fixed in ecryptfs-utils 74-0ubuntu1~ppa1 on jaunty.

[markb (mark-blakeney)]

Reopening this because it is reoccurring on my jaunty laptop with 74-0ubuntu1~ppa1. May not be related but the only thing different there is that i am running ubuntu kernel 2.6.30-020630rc5-generic (to overcome intel video problems).

I have noticed that, after mounting, running ecryptfs-umount-private returns a message:

mark@lt:~ ecryptfs-umount-private
keyctl_unlink: Invalid argument

but ~/Private does unmount. Repeating that command again produces no message 2nd and subsequent times. Then clicking on the desktop link brings up the password launcher but the password is not asked for and ~/Private mounts openly again.

[markb (mark-blakeney)]

Further to my comment above, I updated my jaunty laptop kernel to ubuntu 2.6.30-020630rc6-generic and the symptoms are different. From the point I execute sudo, my ~/Private becomes openly available for anybody to see without entering a password. They just need to click on the desktop link at any later time, even after the sudo timeout has expired. Also, from that point on, executing ecryptfs-umount-private manually returns no response or error, but ~/Private *never* umounts (no matter how many times I run it). Presumably ecryptfs-umount-private is getting an error but not reporting it to the user (nor any log I can find). This lack of error message could be a separate bug?

I'm not sure if the kernel upgrades are responsible here but it is a great concern that ecryptfs fails so dangerously. It seems ecryptfs-utils 74-0ubuntu1~ppa1 did implement some kind of fix as I found above on my main pc, but must be a *very fragile* fix which can fail wrong-side, e.g. merely by me upgrading my ubuntu kernel package.

This bug happens 100% repeatably on my laptop and I am willing to perform specific tests/diagnosis if somebody is interested in investigating this serious bug. This ubuntu ecryptfs stuff has good potential use but is nowhere near ready for prime-time with these kind of bugs hanging around.

[markb (mark-blakeney)]

As of recently this bug has started happening (again) on my pc as well. It is predictably repeatable. I am running the stock jaunty kernel (2.6.28-11-generic) on my pc so ignore my comments above about the kernel. It just seems like the fix I confirmed in ecryptfs-utils 74-0ubuntu1~ppa1 has faded away and we are back to bug condition as originally reported. Still running that same ecryptfs-utils package version so it seems some other ubuntu update has affected this?

[Dustin Kirkland  (kirkland)]

Hi Mark-

Thanks for the testing.

I can confirm that this is fixed in karmic, in ecryptfs-utils-78.

Please reopen this bug if you can reproduce the problem in ecryptfs-utils-78.

Thanks,
:-Dustin

[markb (mark-blakeney)]

Dustin, I am on the current release of ubuntu (i.e. jaunty) and am running the latest ecryptfs-utils package I can find, i.e. 74-0ubuntu1~ppa1 from your ppa. It still exhibits this bug daily. Is there any chance you can produce an updated package for jaunty?

[Dustin Kirkland  (kirkland)]

On Fri, Jul 24, 2009 at 5:06 PM, markb<email address hidden> wrote:
> Dustin, I am on the current release of ubuntu (i.e. jaunty) and am
> running the latest ecryptfs-utils package I can find, i.e.
> 74-0ubuntu1~ppa1 from your ppa. It still exhibits this bug daily. Is
> there any chance you can produce an updated package for jaunty?

The Karmic ecryptfs-utils package is not backwards compatible with
Jaunty. I'd need to do some non-trivial build work to get it going.
Sorry.

:-Dustin

[markb (mark-blakeney)]

So, after all this time, I have upgraded to Karmic today and exactly the same bug still exists there on ecryptfs-utils 81-0ubuntu3.

This is a terrible security hole so, apart from it existing for so long, I am amazed more users have not complained about it.