Bug 480547 - RFE: add umount option to clear per-user keyring
RFE: add umount option to clear per-user keyring
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: ecryptfs-utils (Show other bugs)
10
All Linux
low Severity high
: ---
: ---
Assigned To: Michal Hlavinka
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-18 14:22 EST by Denis Lebeuf
Modified: 2009-03-21 05:27 EDT (History)
4 users (show)

See Also:
Fixed In Version: 70-1.fc10
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-09 19:04:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Text file of session to show commands used to reproduce problem (3.02 KB, text/plain)
2009-01-18 14:22 EST, Denis Lebeuf
no flags Details

  None (edit)
Description Denis Lebeuf 2009-01-18 14:22:45 EST
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.
Comment 1 Eric Sandeen 2009-01-23 15:21:59 EST
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
Comment 2 Denis Lebeuf 2009-01-24 10:39:49 EST
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.
Comment 3 Michal Hlavinka 2009-01-26 11:56:31 EST
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)
Comment 4 Denis Lebeuf 2009-01-27 05:58:22 EST
Thanks for the precisions.
Item 3) makes it very clear and 4) will be a welcome enhancement.
Thanks again.
Comment 5 Michal Hlavinka 2009-01-29 03:58:23 EST
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
Comment 6 Denis Lebeuf 2009-01-30 11:58:25 EST
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
Comment 7 Michal Hlavinka 2009-02-16 05:37:11 EST
this feature has been added into ecryptfs-utils v. 70

you can add ecryptfs_unlink_sigs mount option that clears your keyring during umount
Comment 8 Tyler Hicks 2009-02-16 13:48:05 EST
It should also be noted that the eCryptfs mount helper adds ecryptfs_unlink_sigs to the mount options by default now.
Comment 9 Fedora Admin XMLRPC Client 2009-02-18 02:47:16 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 10 Fedora Update System 2009-03-09 19:04:40 EDT
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.
Comment 11 Piergiorgio Sartor 2009-03-10 16:58:58 EDT
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
Comment 12 Michal Hlavinka 2009-03-11 04:39:49 EDT
(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)
Comment 13 Michal Hlavinka 2009-03-21 05:27:18 EDT
(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...

Note You need to log in before you can comment on or make changes to this bug.