Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Andreas Dilger <adilger@dilger.ca>
Message-Id: <3D2D6626-DF0A-4476-AD2D-8E43477A6176@dilger.ca>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_1C9A64EB-EA0F-4624-A214-6889C2DD6972";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [PATCH v3] ext4: wipe filename upon file deletion
Date:   Thu, 22 Apr 2021 11:44:49 -0600
In-Reply-To: <YH41aghszkzcwdDx@mit.edu>
Cc:     Eric Biggers <ebiggers@kernel.org>,
        Leah Rumancik <leah.rumancik@gmail.com>,
        linux-ext4@vger.kernel.org
To:     Theodore Ts'o <tytso@mit.edu>
References: <20210419162100.1284475-1-leah.rumancik@gmail.com>
 <YH4KAHWphO+0xubA@gmail.com> <YH41aghszkzcwdDx@mit.edu>
Precedence: bulk


--Apple-Mail=_1C9A64EB-EA0F-4624-A214-6889C2DD6972
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Apr 19, 2021, at 7:59 PM, Theodore Ts'o <tytso@mit.edu> wrote:
>=20
> 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.
>>=20
>> 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)...
>=20
> 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).
>=20
> 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.
>=20
> 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


--Apple-Mail=_1C9A64EB-EA0F-4624-A214-6889C2DD6972
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAmCBthEACgkQcqXauRfM
H+Akfw//ae7W/tZsqKaDflklgNwe8+yYL1UQrAKEd1VU4oX1iGjguGDuYrfbF6jK
cmYkdias+kobarmM7QUqORl1Rqh6mF2gxf8+sNMamHf4FJXQAc+xlHLT4mTaUnS1
lWAVeakEIWZsZPThPY/WaGC/O9VU/fJ0ZFK0PerPG371EunGYAKF67lBY5y6z4Ac
cmBF6FHfqvvs8M4cU0OqKzdLokhJfUrTVQTZqz7TcDImlEd3Rlbt6hT3b/CaoY7w
cfkPNdcRjWxOMM/2ntdipjQp4TuzXymVMTOA+f2NOFvdohOHhdJZvDeAfib8W2wp
YZfpQKe3Dz9ryFAm41oFjO5LT4GlOGdhvDxGay0musVPSkkaGRS5GgLsk744JTKT
TcGdG7bcQUSP26mrjRS4wqwu8vncCSfQLazdyLx7BkNVjMESdtRWqLkeQMwHmeFs
0YnjUGoIgvbX8fnez99ixViv97eRCfCNiEkK7FGhuAR/ZE2AvHP5zoxwDPUf0M51
eTAV+36xdmpilTn+4ve78/OjSraB/NUSiyV24bPsWoIvQBrPdBfc2tU476nnqmUc
+PdCfhKS+n4cVI/BNZv6+LRJe1T6MBG9eiJrhFMV0xnJUvwV6dPZXakRdZArNPMj
xCyppVV4+0nhMzrJoqOj3NOF72WiOuD0KVHFvMtPC84pJT1LKdg=
=9De0
-----END PGP SIGNATURE-----

--Apple-Mail=_1C9A64EB-EA0F-4624-A214-6889C2DD6972--