Re: [PATCH] ext4: mark extents index blocks as dirty to avoid information leakage

[Theodore Y. Ts'o]

On Tue, Mar 03, 2020 at 04:51:06PM +0800, brookxu wrote:
> From: Chunguang Xu <brookxu@xxxxxxxxxxx>
> 
> In the scene of deleting a file, the physical block information in the
> extent will be cleared to 0, the buffer_head contains these extents is
> marked as dirty, and then managed by jbd2, which will clear the
> buffer_head's dirty flag by clear_buffer_dirty. However, when the entire
> extent block is deleted, it is revoked from the jbd2, but  the extents
> block is not redirtied.
> 
> Not quite reasonable here, for the following concerns:
> 
> 1. This has the risk of information leakage and leads to an interesting
> phenomenon that deleting the entire file is no more secure than truncate
> to 1 byte, because the whole extents physical block clear to zero in cache
> will never written back as the page is not redirtied.
> 
> 2. For large files, the number of index block is usually very small.
> Ignoring index pages not get much more benefit in IO performance. But if
> we remark the page as dirty, the page is then written back by the system
> writeback mechanism asynchronously with little performance impact. As a
> result, the risk of information leakage can be avoided. At least not wrose
> than truncate file length to 1 byte
> 
> Therefore, when the index block is released, we need to remark its page
> as dirty, so that the index block on the disk will be updated and the
> data is more security.
> 
> Signed-off-by: Chunguang Xu <brookxu@xxxxxxxxxxx>

Trying to zero the extent block is only going to provide pretend
security; the data blocks are still there, and anyone looking for the
data can still find it if they look hard enough.  Also, for most
files, it really doesn't matter.

So, no, I don't think this patch is appropriate.a

If you are really worried about the security for deleted files, I
would suggest trying to implement the secure delete flag (chattr +s)
for ext4, and actually trying to zero out the data blocks for those
files where this kind of security is required.  (Please note that for
SSD's, this probably won't provide as much security as you would like
unless they implement the secure discard operation.)

							- Ted