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]

Message-ID: <CAOQ4uxgWCn2u5gbkPRAwf1vsJrADLXA8+aj2Yq_CZheDTMu24w@mail.gmail.com>
Date:	Fri, 8 Jul 2011 09:11:53 +0300
From:	Amir Goldstein <amir73il@...il.com>
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	Allison Henderson <achender@...ux.vnet.ibm.com>,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/2 v3] EXT4: Secure Delete: Zero out file data

On Fri, Jul 8, 2011 at 5:46 AM, Andreas Dilger <adilger@...ger.ca> wrote:
> On 2011-07-07, at 6:09 PM, Amir Goldstein wrote:
>> On Thu, Jul 7, 2011 at 11:19 PM, Allison Henderson
>> <achender@...ux.vnet.ibm.com> wrote:
>>>
>>> Ah, ok then.  Yes, part of the requirements was to make secure delete work
>>> for partial truncates, punch hole, and also indexed files.  So that will
>>> save me some time if I can get the migrate routines work.  Thx for the
>>> pointers all!
>>
>> I realized that there is a basic flaw in the concept of deferred-secure-delete.
>> From a security point of view, after a crash during a secure-delete,
>> if the file is not there, all its data should have been wiped.
>> Orphan cleanup on the next mount may be done on a system that
>> doesn't respect secure delete.
>> So for real security, the unlink/truncate command cannot return before
>> all data is wiped.
>
> I don't necessarily agree.  People who are using secure delete don't
> necessarily want their performance to go into the toilet, which is what
> would happen if each unlink/zero happened sequentially.  It is far more
> efficient to submit a large batch of unlink/zero operations and then do
> an sync() or fsync() at the end.  This allows multiple journal operations
> to be coalesced (e.g. unlinks from directory) and block zero requests to
> be merged.
>
>> The unlink/truncate metadata changes must not even be committed
>> before all data is wiped (or at least part of the data with partial truncate).
>
> That depends on the user, I think.  If someone does "rm -r {dir}" it may
> be better that the files are removed from the namespace more quickly, and
> secure deleted (in a batch) more quickly, than having "rm" wait for each
> file to be unlinked and maybe leave files in the namespace that didn't
> even get a chance to be unlinked.
>

if my system crashes in the middle of "rm -rf my_darkest_secrets/"
I want to be able to see if there are leftovers after reboot, therefore
the directory and files cannot be removed from namespace before
I get the secured delete guaranty.

Amir.
--
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