Hello, probably You do not understand what I mean - sorry please my English.
I do not more talk about ecryptfs and access control like ugo/rwx. I have accepted this behaviour of ecryptfs (even if I do not agree with lost chance to make it else). I'm talking about key management - read please my post ones again. See specially the parts/questions with "!!!" --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: 16.2.2011 - 18:13:52 > 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
