linux-ext4 - Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170831181015.GC5023@gmail.com>
Date:   Thu, 31 Aug 2017 11:10:15 -0700
From:   Eric Biggers <ebiggers3@...il.com>
To:     Anand Jain <anand.jain@...cle.com>
Cc:     Theodore Ts'o <tytso@....edu>, linux-fscrypt@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-ext4@...r.kernel.org, Jaegeuk Kim <jaegeuk@...nel.org>,
        Richard Weinberger <richard@....at>,
        Michael Halcrow <mhalcrow@...gle.com>,
        Eric Biggers <ebiggers@...gle.com>
Subject: Re: [PATCH] fscrypt: add a documentation file for filesystem-level
 encryption

Hi Anand,

On Tue, Aug 29, 2017 at 11:54:47AM +0800, Anand Jain wrote:
> 
>  BTRFS has an experimental fscrypt implementation[1] which does not
> include the file-name encryption part it should be included but as
> an optional since not all uses cases saves sensitive information in
> the file-name. OR even if the attacker is able to identify a file
> called secrete.txt and break it then its still points at the
> weakness of the file-data encryption. Can we say that ? apparently
> from the discussion here it seems the answer is yes.
> 

Filenames by themselves can be sensitive information, since a filename can serve
as a strong indicator of what a file is.  For example, a filename could be used
as evidence that a person had access to a certain document.

> >Hence, making the encryption of the filenames optional doesn't just to
> >make life easier for backup/restore isn't a compelling argument, since
> >the backup/restore program is going to have to have special case
> >handling for fscrypt protected file systems *anyway*.
> 
>  fscrypt backup and restore does not work even without file-name
> encryption because the Extended Attribute needs special ioctl in the
> fscrypt (I did rise this objection before).
> 
>  But its entirely possible to create a string based encryption
> metadata which can be updated/retrieved using the legacy backup
> tools such as
> 
>   rsync --xattrs
> 
>  That will be a design for fscryptv2 probably..
> 
>  OR I mean to say possible optional file-name encryption is not the
> ground reason for the encrypted backup and restore challenge.
> 

This was already discussed.  You cannot simply add and remove the encryption
xattr from random files and directories; what happens to all the open file
descriptors, memory maps, pagecache pages, dcache entries, etc.?  Are the
existing contents and directory entries supposed to be left unencrypted, or are
they supposed to be already encrypted, or is the filesystem supposed to
automatically encrypt them when the xattr is set?  What about when the xattr is
removed?  Again, you're of course free to propose a design which takes into
account all of this and makes the argument for adding an xattr-based API, but I
haven't seen it yet.

Eric