ecryptfs-users team mailing list archive

[Dustin Kirkland <kirkland@xxxxxxxxxx>]

2011/2/16 kapetr <kapetr@xxxxxxxxx>:
> 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" <kirkland@xxxxxxxxxx>
> Komu: "kapetr" <kapetr@xxxxxxxxx>
> 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
>> <kapetr@xxxxxxxxx> 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