ecryptfs-users team mailing list archive

[David Tomaschik <david@xxxxxxxxxxxxxxxxxx>]

Nobody else can use the keys in one user's user keyring to mount an
eCryptFS system.  Just because they could see the files, doesn't mean
they have access to the keys.  Try this:

- Add a key as user1
- Mount an eCryptFS system as user1
- Unmount the eCryptFS system as user1
- As user2, attempt to mount the same eCryptFS system. This operation
should (and does on my system) fail.

David


2011/2/16 kapetr <kapetr@xxxxxxxxx>:
> 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" <kirkland@xxxxxxxxxx>
> Komu: "kapetr" <kapetr@xxxxxxxxx>
> Předmět: Re: [Ecryptfs-users] (un)security of eCryptfs ?
> Datum: 16.2.2011 - 18:13:52
>
>> 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
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ecryptfs-users
> Post to     : ecryptfs-users@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ecryptfs-users
> More help   : https://help.launchpad.net/ListHelp
>



-- 
David Tomaschik, RHCE, LPIC-1
System Administrator/Open Source Advocate
OpenPGP: 0x5DEA789B
http://systemoverlord.com
david@xxxxxxxxxxxxxxxxxx