linux-ext4 - Re: [PATCH 1/2 v3] EXT4: Secure Delete: Zero out file data

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 10 Jul 2011 19:13:37 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Amir Goldstein <amir73il@...il.com>
Cc:	Allison Henderson <achender@...ux.vnet.ibm.com>,
	Andreas Dilger <adilger@...ger.ca>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/2 v3] EXT4: Secure Delete: Zero out file data

On Fri, Jul 08, 2011 at 09:29:16AM +0300, Amir Goldstein wrote:
> 
> Well, that really depends of the precise definition of "secure delete".
> If you agree with the "100% secure" interpretation, then your current patch
> is "almost" correct.
> I can see 2 things that are missing:
> 1. ext4_unlink() will have to invoke ext4_truncate(0) directly just
> like truncate system call does.
> This is to prevent an attacker from keeping the protected file open
> and preventing freeing
> of it's data when the file is removed from the name space.

Um, no.  This breaks Unix semantics, which is going to cause any kind
of headaches, especially if someone sets the secure delete flag on a
directory, and then a hapless application creates a file in said
directory expecting standard Posix semantics.

If the attacker has a handle on the file, he can just simply copy out
the data to another file; if you're worried about someone who manages
to open the file just 1 millisecond before you do the delete (as
opposed 100 milliseconds, when he would have copy out the file), I
don't think it's worth it.

> 2. ext4_truncate() currently changes i_disksize first (and adds inode
> to orphan list)
> and then frees the blocks. for 100% secure delete, you cannot change i_disksize
> before zeroing the blocks, so it has to be:
> - zeroout range
> - change i_disksize and add to orphan list
> - free blocks

What are you worried about here?

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html