Preventing information leaks from ext4 filesystems

Encryption on a directory-per-directory or file-by-file basis is not that good, but as pretty much every CPU (for us x86-64 users anyway) has AES (cat /proc/cpuinfo | grep aes) we're good, IIRC the Sandy Bridge i3's didn't have it, Skylake i3s do, not sure about the middle

There's really no reason not to use it, but even then we should write random crap to the drive first (but this hurts SSDs) most of us probably dont and this means sectors filled with 0s leaks "there's no data here", an attacker that can image the drive even if you write random crap first can see where sectors are changing at least

This has its own problems like watermarking attacks but that was a thing that was solved in the 2.63 or even older kernels, however it can still leak some information

File names, I've gotta say, with directory names and that should not be "scrubbed" - I'm not even sure we over-write the data (I don't think we do?) - but obviously if a file is allocated a range that should be 0ed or otherwise not-actually-read by the file until it writes there.

TheTimeIDidTheCrime.txt - if that sensitive should be on an encrypted drive

A netbook of mine was once stolen (good riddance, hated that fad and the tiny keyboard and the Atom CPU) - full disk encryption means I get to write about it with a smile not worrying about whatever was on there being a problem for me (not to sound dodgy but you see what I mean)

If we did do this, symlinks may also need protecting, or NFS/sshfs type deals, it'd be bad

So I doubt encryption-in-the-fs would be safe anyway it'd certainly complicate things (see the watermarking attack I mentioned) - I really like our block device solution of LUKS and the like letting ext4 operate on /dev/mapper/whatever as if it were a drive

We also can pass through trim and stuff like that (at the cost of the drive now contains zeros) - but it helps our SSDs.