On Apr 19, 2021, at 7:59 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> 
> On Mon, Apr 19, 2021 at 03:53:52PM -0700, Eric Biggers wrote:
>> On Mon, Apr 19, 2021 at 04:21:00PM +0000, Leah Rumancik wrote:
>>> Upon file deletion, zero out all fields in ext4_dir_entry2 besides inode
>>> and rec_len. In case sensitive data is stored in filenames, this ensures
>>> no potentially sensitive data is left in the directory entry upon deletion.
>>> Also, wipe these fields upon moving a directory entry during the conversion
>>> to an htree and when splitting htree nodes.
>> 
>> This should include more explanation about why this is useful, and what its
>> limitations are (e.g. how do the properties of the storage device affect whether
>> the filename is *really* deleted)...
> 
> Well, it might be useful to talk about how this is not a complete
> solution on its own (acknowledge that more changes to make sure
> filenames aren't leaked in the journal will be forthcoming).
> 
> However, there is a limit to how much we can put in a commit
> description, and I'd argue that the people for whom caveats about
> flash devices having old copies of directory blocks which could be
> extracted by a nation-state intelligence angency, etc., are not likely
> going to be the people reading the git commit description.  :-)  That's
> the sort of thing that is best placed in a presentation given at a
> conference, or in a white paper, or in LWN article.
> 
> Commit descriptions are targetted at developers, so a note that "more
> commits to follow" would be appropriate.

Since the "delete-after-the-fact" method of security is always going
to have holes in terms of recovering data from the journal, from the
flash device, etc. why not use fscrypt for this kind of workload, if
the data actually needs to be secure?

Cheers, Andreas