fscrypt and potential issues from file sparseness

fscrypt and potential issues from file sparseness

[David Howells]

Hi,

I'm looking at doing content encryption in the network filesystem support
library.  It occurs to me that if the filesystem can record sparsity in the
file, then a couple of issues may arise if we wish to use that to record
zeroed source blocks (ie. the unencrypted blocks).  It further occurs to me
that this may occur in extent-based filesystems such as ext4 that support
fscrypt and also do extent optimisation.

The issues are:

 (1) Recording source blocks that are all zeroes by not storing them and
     leaving a hole in a content is a minor security hole as someone looking
     at the file can derive information about the contents from that.  This
     probably wouldn't affect most files, but it might affect database files.

 (2) If the filesystem stores a hole for a *source* block of zeroes (not an
     encrypted block), then it has the same problems as cachefiles:

     (a) A block of zeroes written to disk (ie. an actually encrypted block)
     is very, very unlikely to represent a source block of zeroes, but the
     optimiser can punch it out to reduce an extent and recover disk space,
     thereby leaving a hole.

     (b) The optimiser could also *insert* blocks of zeroes to bridge an
     extent, thereby erasing a hole - but the zeroes would be very unlikely to
     decrypt back to a source block of zeroes.

     If either event occurs, data corruption will ensue.

     To evade this one, we have to do one of the following:

	1. Don't use sparsity to record source blocks of zeroes
	2. Disable extent optimisations of these sorts
	3. Keep a separate map of the content

Now, I don't know if fscrypt does this.  It's hard to tell.

David

Re: fscrypt and potential issues from file sparseness

[Eric Biggers]

Hi David,

On Wed, Jan 26, 2022 at 12:44:14PM +0000, David Howells wrote:
> Hi,
> 
> I'm looking at doing content encryption in the network filesystem support
> library.  It occurs to me that if the filesystem can record sparsity in the
> file, then a couple of issues may arise if we wish to use that to record
> zeroed source blocks (ie. the unencrypted blocks).  It further occurs to me
> that this may occur in extent-based filesystems such as ext4 that support
> fscrypt and also do extent optimisation.
> 
> The issues are:
> 
>  (1) Recording source blocks that are all zeroes by not storing them and
>      leaving a hole in a content is a minor security hole as someone looking
>      at the file can derive information about the contents from that.  This
>      probably wouldn't affect most files, but it might affect database files.

This is working as intended; it's a known trade-off between security and
usability that is documented in Documentation/filesystems/fscrypt.rst.  eCryptfs
worked differently, and that caused lots of problems because things that would
be fast on normal filesystems were instead extremely slow.

> 
>  (2) If the filesystem stores a hole for a *source* block of zeroes (not an
>      encrypted block), then it has the same problems as cachefiles:
> 
>      (a) A block of zeroes written to disk (ie. an actually encrypted block)
>      is very, very unlikely to represent a source block of zeroes, but the
>      optimiser can punch it out to reduce an extent and recover disk space,
>      thereby leaving a hole.
> 
>      (b) The optimiser could also *insert* blocks of zeroes to bridge an
>      extent, thereby erasing a hole - but the zeroes would be very unlikely to
>      decrypt back to a source block of zeroes.
> 
>      If either event occurs, data corruption will ensue.
> 
>      To evade this one, we have to do one of the following:
> 
> 	1. Don't use sparsity to record source blocks of zeroes
> 	2. Disable extent optimisations of these sorts
> 	3. Keep a separate map of the content
> 
> Now, I don't know if fscrypt does this.  It's hard to tell.
> 

Changing an all-zeroes region to a hole (or vice versa) in an encrypted file is
impossible without the key, so yes that sort of thing needs to be disabled, e.g.
based on whether the inode has the encrypt flag set or not.

As far as I know, neither e2fsprogs nor f2fs-tools implement this sort of
optimization.  e2fsck supports optimizing how the extents are represented on
disk, but it doesn't mess with the actual data blocks.

- Eric