Howdy,

I just prepared a round of SRUs to fix this bug in Karmic, Lucid, and
Maverick.

I would really appreciate if some of the people suffering from this bug
could test out the proposed packages as soon as they're accepted and
built.

Cheers!
Dustin

** Description changed:

  How to reproduce :
  
  1) setup a private directory
  2)
  sudo -s
  
  cd /
  
  mkdir source
  
  mkdir target
  
  cp ~user/.Private/example.pdf source
  
  file /source/example.pdf
  /source/example.pdf: data
  
  mount -t ecryptfs source target
  Passphrase: type anything that is not your passphrase or passwords
- Select cipher: 
-  1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (loaded)
-  2) blowfish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
-  3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
-  4) twofish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
-  5) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
-  6) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
- Selection [aes]: 
- Select key bytes: 
-  1) 16
-  2) 32
-  3) 24
- Selection [16]: 
+ Select cipher:
+  1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (loaded)
+  2) blowfish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
+  3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
+  4) twofish: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
+  5) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
+  6) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
+ Selection [aes]:
+ Select key bytes:
+  1) 16
+  2) 32
+  3) 24
+ Selection [16]:
  Enable plaintext passthrough (y/n) [n]: n
  Attempting to mount with the following options:
-   ecryptfs_key_bytes=16
-   ecryptfs_cipher=aes
-   ecryptfs_sig=4c748f746abcc24e
+   ecryptfs_key_bytes=16
+   ecryptfs_cipher=aes
+   ecryptfs_sig=4c748f746abcc24e
  WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
- it looks like you have never mounted with this key 
- before. This could mean that you have typed your 
+ it looks like you have never mounted with this key
+ before. This could mean that you have typed your
  passphrase wrong.
  
  Would you like to proceed with the mount (yes/no)? yes
  Would you like to append sig [4c748f746abcc24e] to
- [/root/.ecryptfs/sig-cache.txt] 
+ [/root/.ecryptfs/sig-cache.txt]
  in order to avoid this warning in the future (yes/no)? no
  Not adding sig to user sig cache file; continuing with mount.
  Mounted eCryptfs
  
  file /source/example.pdf
  /source/example.pdf: PDF document, version 1.4
  
+ Now I know that the files are really encrypted (using a wrong passphrase
+ on files copied to another computer makes the file unreadable), but I
+ don't understand how root on my system can mount my files without the
+ correct passphrase... is the passphrase stored somewhere? This is really
+ strange and doesn't give me too much confidence in this technology.
+ Let's hope I overlooked something.
  
- Now I know that the files are really encrypted (using a wrong passphrase on 
files copied to another computer makes the file unreadable), but I don't 
understand how root on my system can mount my files without the correct 
passphrase... is the passphrase stored somewhere? This is really strange and 
doesn't give me too much confidence in this technology. Let's hope I overlooked 
something.
+ ============
+ SRU Justification:
+ 
+ Impact: This bug affects users of Ubuntu's encrypted home/private
+ directory feature if they are concerned about a malicious or snooping
+ root user on the system.
+ 
+ Minimal patch: The minimal patch can be found in upstream commit r520:
+  * http://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/revision/520
+ 
+ Reproduce instructions:  Follow the excellent instructions in this bug
+ description.
+ 
+ Regression potential: Minimal.  The key removal code is the last thing that 
happens before the umount is attempted.  If for some reason the new 
key-unlinking code failed (it should not; errors are ignored; keys are removed 
on a best-effort basis), then the umount might not happen.  As I said, this 
should be a near impossible situation.  I think this update should be very 
safe.  It's been in Natty now for a couple of weeks.
+ ============

** Changed in: ecryptfs-utils (Ubuntu Karmic)
    Milestone: None => karmic-updates

** Changed in: ecryptfs-utils (Ubuntu Lucid)
    Milestone: None => lucid-updates

** Changed in: ecryptfs-utils (Ubuntu Maverick)
    Milestone: None => maverick-updates

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/313812

Title:
  umount of ecryptfs does not automatically clear the keyring (can be
  mounted by root later)

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to