lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 7 Feb 2015 05:56:45 +0000 (UTC) From: Russ Dill <Russ.Dill@...il.com> To: linux-kernel@...r.kernel.org Subject: Re: [PATCH 0/5] RFC: Offer a way for userspace to request real deletion of files Alexander Holler <holler <at> ahsoftware.de> writes: > > Hello. > > I've set up a repository at github which contains the 3 pathches to add > limited support to the Linux kernel for wiping files on ext4 and (v)fat > with 3 small patches and a total of "9 files changed, 101 insertions(+), > 8 deletions(-)" here: > > https://github.com/aholler/wipe_lnx > > Feel free to send me any comments, patches or even flames in privat > (off-list)! because I don't want to become involved in annoying > discussions here anymore. > > Alexander Holler > This is certainly a case of "The Emperor's New Clothes". Lets say I use vim to edit my file containing my deep dark secrets. Lets strace it and see what happens when I edit it and save a new copy: rename("secure_document.txt", "secure_document.txt~") = 0 open("secure_document.txt", O_WRONLY|O_CREAT|O_TRUNC, 0664) = 3 write(3, "secrete:s\n", 10) = 10 fsync(3) = 0 close(3) = 0 chmod("secure_document.txt", 0100664) = 0 setxattr("secure_document.txt", "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x04\x00\x06\x00\xff\xff\xff\x ff \x00\x04\x00\xff\xff\xff\xff", 28, 0) = 0 unlink("secure_document.txt~") = 0 You'll find that just about every program that deals with files properly does something like this. If it didn't, there'd be a good chance of losing all your work if the computer or program crashed while saving your file. This is layer one of the problem. Layer 2 is filesystems, as others have noted, filesystems have all sorts of paths for blocks no longer being associated with inodes. Log structured file systems doubly so. And layer 3, media, which we have no control over and may be storing duplicate copies of the data for any number of reasons. But as you've pointed out, is likely to require significant funds to get at. As pointed out, the best you could do is some sort of flag on the inode that instructed the filesystem to wipe blocks before separating them from the inode. Programs would need to be modified though as you can see in the vim case, any copying of file mode bits are only done after data has been written to disk. Luckily there is an easy solution out there that solves all these problems. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists