← Back to team overview

ecryptfs-users team mailing list archive

Re: (un)security of eCryptfs ?

 

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
> 




Follow ups

References