Created attachment 329304 [details] Text file of session to show commands used to reproduce problem Description of problem:Any passphrase entered at mount will decrypt file Version-Release number of selected component (if applicable): ecryptfs-utils-61-0.fc10.i386 kernel-2.6.27.9-159.fc10.i686 How reproducible:Entering a wrong passphrase will decrypt file Steps to Reproduce: 1.As root, mount directory using ecryptfs 2.put file in directory 3.umount directory 4.mount directory again with wrong passphrase 5.file can be retrieved Actual results: file can be retrieved Expected results:should not be able to read file if wrong passphrase is entered at mount Additional info: Everything works as expected on FC9. Giving wrong passphrase during mount gives the error "Input/output error" when trying to access crypted file.
I think this is a feature, not a bug. The first passphrase ended up cached in your kernel crypto keychain, and so was still available to decrypt your old files. If you wish to clear it, use keyctl. Other users will not be able to see these files by entering arbitrary passphrases. -Eric
Hi Eric, Thanks a lot for the explanation. I played with keyctl and now see what is going on. However, this automatic caching leads to a false sense of security. Whatever strength I use for the crypted FS key (30+ characters), the overall security is only as strong as my (8 to 10 character) password. And I don't get any warning of this fact. Is there a way to disable this automatic caching? Until I understand more completely the whole process, it seems I must do an alias on the umount command to be immediately followed by "keyctl clear @u" command. Thank you very much for the time you spent on this.
Hi, I've talked about this with upstream with this conclusions: 1) it's not a bug, it's a feature. Even gnome-keyring doesn't clear out a key after an application uses it 2) If you want to clear your keyring, use `keyctl clear @u` 3) the password at mount time is not a password to read existing files. It is a password that is turned into a key which is used when creating new files 4) there will be added new mount option that will automatically clear keyring after umount (so mount with wrong passphrase will not work any more)
Thanks for the precisions. Item 3) makes it very clear and 4) will be a welcome enhancement. Thanks again.
extract from irc: > let me answer this question a different way, "when is this an actual problem?" > first, only a root user can perform an ecryptfs mount > non-root users can perform mounts through the setuid binary, mount.ecryptfs_private, but in that case, what they can do is tightly constrained > to perform a generic mount, it has to be a root user > now, for this to be a problem, the *root* user must: > a) establish an ecryptfs mount with one passphrase > b) unmount > c) do *not* clear the keyring > d) do *not* logout of the session > and then a malicious user must obtain access to *that* session > by either sitting down at the terminal, or accessing via vnc or screen or some such > at that point, the malicious user has a root shell > and while accessing some encrypted data is a bad thing, there are a lot of bad things that can happen at that point > so we can help with (c) by clearing the keys on unmount > but ultimately, (d) is the biggie ... the root user needs to logout of the session if they want their data protected so I think you can still feel yourself safe :) anyway, there is still plan to add new feature mentioned before
Hi Michael, Thanks for your follow-up. At least on my system (Fedora 10), "the biggie" point d) is not true. I am logged in as a normal user, I issue a "su" command, mount the ecrypted FS as root with the valid password. Then I umount, exit out of the "su" command and even logout the normal user. (No one is now logged on to the system.) I log again with my normal user account, do a "su" and mount the ecrypted FS with another password. The file is unencrypted again. In other words, only a `keyctl clear @u` or a reboot will clear the key. That is more frightening. I think that even without the new added feature, documenting the fact as clearly as you did in your email of the 26th would go a long way toward eliminating a false sense of security when using the ecryptfs. Thanks a lot
this feature has been added into ecryptfs-utils v. 70 you can add ecryptfs_unlink_sigs mount option that clears your keyring during umount
It should also be noted that the eCryptfs mount helper adds ecryptfs_unlink_sigs to the mount options by default now.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
ecryptfs-utils-70-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
Is this really fixed? With the automount of ~/Private I got a similar problem. Specifically: 1) log in with a user having the ~/Private thing 2) log out 3) as root change to user (su - user) Then, without asking for password of course, ~/Private is mounted. Does this belong to this bug or should I open a new one? Thanks, piergiorgio
(In reply to comment #11) > Is this really fixed? Yes and no :) * "add umount option to clear per-user keyring" - is done, there is new mount option and it works - it's mount option so it works if you add it to mount -t ecryptfs .... -o ecryptfs_unlink_sigs,... * clear per-user keyring with ecryptfs-(u)mount-private (or auto mount after login) doesn't work *yet* = in version 70 I'll let you know in this bz when working version is released (it'll be v. 72 I guess)
(In reply to comment #12) > I'll let you know in this bz when working version is released (it'll be v. 72 I > guess) unfortunately, released version 73 still doesn't contain the fix...