2011/2/16 kapetr <[email protected]>: > Thank You very much for answer, > > you wrote: > >> It's critical that you understand the kernel > keyring and how it >> works. >> > Most importantly, you need to understand when and how to clear >> keys >> > from your keyring. You must have the keys in your keyring when >> it's >> > mounted. And you should clear those keys on unmount. > > > You are right! That's absolutely the point. > I had made some other tests - e.g.: > > -------------------------------------------- > users: U1, U2; folder S1, S2 (in /tmp with rw for all); files F1, F2 > (r to all) > > 1. root mounts .sec (ecryptfs folder) on S1 with password P1 > 2. U1 creates in S1 file F1 > 3. root mounts .sec (ecryptfs folder) on S2 with password P2 > 4. U2 creates in S2 file F2 > 5. U2 can see F1 and F2 in S2, but can read only F2. > -> nobody can read F1 in S2 at this time point > 6. U2 adds P1 to its @u keyring > 7. U1 still can not read F1 in S2 > 8. U2 try to read F1 in S2 - success > 9. U1 from now can read F1 in S2 too > > So ... I thing it works this way: > > I. concrete ecryptfs collects all keys used in it - by mount or > access with key (from WHOEVER) - in keyring and from this time point > ANYBODY can read files in it > II. even if the key is deleted from keyring, the key STAYS in this > concrete ecryptfs until unmount - so files are accessible continued > after "keyctl clear @u" > > > But - this behaviour is VERY confusing ! > > ------------------------------------------------------------------------------ > Why are there user/process/thread keyrings at all ? > ------------------------------------------------------------------------------ > > When if e.g. someone 1. times uses his key, then from this time > point anybody can read by this key encoded key of files can read > them ? > > !!! For what is good keyctl clear @u at all ? If the key is used > further ? !!! > > You wrote: "And you should clear those keys on unmount." > Why ? > > Does it mean that someone else could mount this ecryptfs again > WITHOUT knowing the password ? Up to unlog or reboot ? !!! > > The problem is that documentation of eCryptfs is minimal and doc. of > keys management is NONE at all. > > So I would like to understand this key management - but ... > I thing that in security issues the understanding (=> documentation) > is essential. > So in case of eCryptfs: if I do not know, where/how/by who are keys > stord, managed, .., who can use them, at what time point are they > usable, ..., then I can't use it :-(( > > --kapetr > > > > > ----- PŮVODNÍ ZPRÁVA ----- > Od: "Dustin Kirkland" <[email protected]> > Komu: "kapetr" <[email protected]> > Předmět: Re: [Ecryptfs-users] (un)security of eCryptfs ? > Datum: 14.2.2011 - 18:11:23 > >> On Fri, Feb 4, 2011 at 12:29 PM, kapetr >> <[email protected]> wrote: >> > Hello, >> > >> > I'm new in using of eCryptfs, but the first test >> > do not let me >> > > sleep. >> > >> > I'm using Ubuntu 10.10 - standard installation. >> > >> > Let see my steps: >> > >> > 1. I mount (as root or with sudo) my first >> > eCryptfs in user1 subdirs >> > > with passwd1. >> > 2. the key is ONLY in keyring @u of root, NOT by >> > user1 - but: >> > > >> > user1 can create and read files in that FS (file >> > system) root can >> > > the same. >> > >> > ?? How can user1 work with files in this FS even >> > if user1 has no key >> > > in his keyring ?!!! >> > >> > 3. root clears kis keyring with keyctl clear @u, >> > but the FS is >> > > usable further ??!! >> > >> > 4. root unmounts this FS and mounts it again >> > with another password >> > > passwd2 >> > >> > 5. user1 can not see content of previous files >> > (but can see >> > > names/size in "ls") and can create new files - >> > AGAIN WITHOUT key >> > > >> > 5. user1 adds passwd1 with ecryptfs-manager - so >> > passwd2-key is in >> > > @keyring of root and passwd1-key is in keyring >> > of user1 >> > > >> > 6. user1 can now see content of ALL previous >> > files ??!! root too >> > > ??!! >> > >> > 7. and now! another user - user2 can also see >> > all files, even if he >> > > has no keys !! >> > >> > HOW IS IT POSSIBLE ?? >> > >> > I thing, that access to content of encrypted >> > files should have ONLY >> > > the one, who has key of proper password in his >> > keyring - and NOBODY >> > > ELSE. >> > >> > But this is by eCryptfs not so. Once anybody >> > adds passwdX to his >> > > keyring, than anybody else !!! can read files >> > encrypted with this >> > > password. Even if this user deletes this key >> > from his keyring !!! >> > > >> > I can not believe my eyes ?! >> > >> > Please HELP. >> >> Hi there, >> >> It's critical that you understand the kernel >> keyring and how it works. >> Most importantly, you need to understand when and >> how to clear keys >> from your keyring. You must have the keys in your >> keyring when it's >> mounted. And you should clear those keys on >> unmount. If you add the >> mount option "ecryptfs_unlink_sigs", >> umount.ecryptfs will clear those >> keys out of the keyring when the filesystem is >> unmounted. If you're >> using Ubuntu Encrypted Home / Encrypted Private >> option, that will be >> done automatically for you in 11.04 (and an update >> to older versions >> of ecryptfs-utils is pending but should be >> available within the next >> few days). >> >> As for access of the mounted filesystem by root or >> other users... The >> stated goal of eCryptfs is to protect your data >> "at rest". This is >> mainly about protecting your data in the event of >> someone physically >> stealing your device, and protecting your data >> when you backup the >> encrypted files to a remote system. eCryptfs has >> never meant (nor >> claimed) to protect you from a malicious or >> snooping root user. In >> other words, eCryptfs does not provide MAC >> (Mandatory Access >> Controls). Instead. eCryptfs expects that DAC >> (Discretionary Access >> Controls) protect your data while it's mounted. >> That said, we would >> *welcome* patches from an enterprising user who >> wants to provide >> SELinux and/or AppArmor extensions for eCryptfs >> that could >> cryptographically enforce MAC. However, we've >> looked at this >> repeatedly in the past, and while not impossible, >> it is rather >> complicated. >> >> All this said, there are tons of different file >> encryption solutions >> out there, each one serving a different user's >> needs. >> >> I espouse eCryptfs because I believe that it >> provides the right >> balance of security, usability, and performance >> for my needs. I use >> eCryptfs to protect my $HOME directory (the >> aforementioned Ubuntu >> Encrypted Home Directory feature). Should someone >> steal my laptop >> (God forbid), my data is cryptographically >> protected and I do not need >> to worry about my most private information (which >> I necessarily store >> in $HOME) being stolen. I use 2-factor >> authentication (placing >> $HOME/.ecryptfs/wrapped-passphrase) on removable >> media, so a brute >> force attacker will have to crack a 128bit >> password. I am the root >> user (and only user) of my laptop, so I'm not >> concerned about what >> root might do on my machine. I rsync the >> cryptographic files to a >> shared backup server on the Internet where I'm not >> root. Again, >> because the wrapped-passphrase is stored >> separately, I have no cause >> for concern about the security that data.
Once again, the point of eCryptfs is not to protect you from root or other authorized/authenticated users of the system. For that, you have DAC (discretionary access controls) [1]. eCryptfs is designed to protect you from unauthorized, unauthenticated users -- users who have stolen your hard drive or computer and are trying to mount or read your data. [1] http://en.wikipedia.org/wiki/Discretionary_access_control -- :-Dustin Dustin Kirkland Ubuntu Core Developer _______________________________________________ Mailing list: https://launchpad.net/~ecryptfs-users Post to : [email protected] Unsubscribe : https://launchpad.net/~ecryptfs-users More help : https://help.launchpad.net/ListHelp
