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
|