Re: [PATCH v3] ext4: wipe filename upon file deletion

On Apr 19, 2021, at 7:59 PM, Theodore Ts'o [off-list ref] wrote:

On Mon, Apr 19, 2021 at 03:53:52PM -0700, Eric Biggers wrote:

quoted

On Mon, Apr 19, 2021 at 04:21:00PM +0000, Leah Rumancik wrote:

quoted

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