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]
Date:   Tue, 29 Aug 2017 11:54:47 +0800
From:   Anand Jain <anand.jain@...cle.com>
To:     "Theodore Ts'o" <tytso@....edu>
Cc:     Eric Biggers <ebiggers3@...il.com>, 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




>>> If *no* applications care whether the filenames are encrypted or not, sure.
>>> But are you absolutely sure that no applications care?  How do you know?  And what
>>> is the advantage of not encrypting the filenames anyway?  It is better to
>>> encrypt by default.
>>>
>>   File-name is a kind of File-system semantic and altering based on the on
>> the user key context does not guarantee the system will be compatible with
>> all their legacy applications.
> 
> In theory we could make it optional whether or not file names are
> encrypted.  But that means extra complexity, and extra complexity
> means potential bugs and vulnerabilities --- both potential
> implementation bugs, vulnerabilities caused by users getting confused
> by how they configure the system settings.  So in general with
> security systems it's better to limit the complexity to the bare
> minimum.

  That's right from the dev perspective. But for every security fix 
there is a convenience that is being sacrificed by the user. Providing a 
security fix even if there is no threat just adds pain to the 
user/solution and nothing else. Of course it all depends on the use case.


  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.

  [1]
    Kernel: https://github.com/asj/linux-btrfs-fscryptv1



> The only case which you've come up with in terms of potential
> vulnerabilities is backup and restore, and backup and restore is
> complicated for a number of numbers, since you need to be able to
> backup and restore not just the file name and the encrypted data
> blocks, but also the encrypted per-file key.

>  So getting this right
> will almost certainly require that the backup/restore software be
> fscrypt aware.

  Not necessarily, as below..

> 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.

Thanks, Anand

> Cheers,
> 
> 					- Ted

Powered by blists - more mailing lists