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] [day] [month] [year] [list]
Date:	Mon, 11 Jul 2011 07:24:53 -0700
From:	Allison Henderson <achender@...ux.vnet.ibm.com>
To:	Lukas Czerner <lczerner@...hat.com>
CC:	Ric Wheeler <rwheeler@...hat.com>, "Ted Ts'o" <tytso@....edu>,
	Andreas Dilger <adilger@...ger.ca>,
	Mingming Cao <cmm@...ibm.com>,
	Amir Goldstein <amir73il@...il.com>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/2 v3] EXT4: Secure Delete: Zero out file data

On 07/11/2011 01:20 AM, Lukas Czerner wrote:
> On Mon, 11 Jul 2011, Ric Wheeler wrote:
>
>> On 07/11/2011 12:33 AM, Ted Ts'o wrote:
>>> On Sun, Jul 10, 2011 at 09:19:58AM +0100, Ric Wheeler wrote:
>>>> Just to wrap up this thread, I will throw out some of the use cases
>>>> that I have seen....
>>> Unless we clearly articulate what use case we are hoping to address, I
>>> have to admit I'm a little dubious about whether it's worth it to add
>>> "secure delete".  There are plenty of other solutions, including
>>> user-space shred, destruction of an encryption key, etc.  All of these
>>> solutions have tradeoffs between performance and security.
>>>
>>> So if we're going to implement something, we should think very
>>> carefully about what problem we are hoping to solve, and what sort of
>>> adversaries/threat environment where we'd think this would be useful.
>>>
>>> I'll observe that in many cases, where you have the sweating Enron
>>> executive trying to destroy evidence, they're going to be thwarted by
>>> automatic backup policies.  This is also true BTW if you're worried
>>> about employment records --- and pawing through several terabytes of
>>> backup tapes to delete (only) the employee records for Léo Apotheker
>>> Platner after he resigned from SAG AG would really be unpleasant.  :-)
>>>
>>> And of course, if you are using devices such as SSD's or
>>> thin-provisioned devices, file-system level erasure may not really do
>>> a lot of your anyway, even if you are using discard.
>>>
>>> So --- does anyone have some thoughts about how this would actually
>>> used by potential customers?  If not, my vote would be to keep things
>>> as simple as possible, and if it's too complicated, to think carefully
>>> about whether it's worth it to (re)-add this feature.
>>>
>>> 					- Ted
>>
>> I do think that the synchronous secure delete is useful to have, even if slow.
>>
>> That said, as you point out, there are lots of ways that this will fail
>> potentially, including:
>>
>> * you might have copied a file or had blocks paged out that leave a "ghost"
>> trace
>>
>> * a simple secure delete that overwrites with zeros is not "sufficient" to
>> erase tracks for some users (look at the multi-pass options shred does for
>> example)
>>
>> * ssd's or other devices do wear levelling and move data around internally so
>> you might be able to rip the device apart and look at the raw flash and
>> recover data
>
> This is my concern as well. Allison I think that if you are going to do
> next spin of the patches it would be nice to detect whether the device
> supports secure discard or at least regular discard is zeroing the data,
> because otherwise just plain overwrite with zeroes is not going to help
> at all. SSD will use some other blocks and the data will be still there,
> so there is no point in doing overwrite.

Alrighty, initially the patches did have the discard, but we weren't 
sure where the appropriate place to put it was, so we decided to leave 
it out and add it as an optimization later.  We were thinking it needs 
to be where ever the existing code for discard is (which is in the 
callback commit), but it sounds now like the discard needs to be where 
ever the zero out is happening, so I will add that back in in the next set.

>
> However if you do use discard (not sure what secure discard is actually
> doing) then you're still not guaranteed to have everything wiped out,
> because there might still be some parts of the file in other places of
> the device due the previous rewrites. You'll have to use fitrim to get
> rid of the other parts, but still there might be some data left in the
> user restricted area of the device which the fw uses for better wear-
> leveling.
>
> Thanks!
> -Lukas

Ok then, I will check into fitrim and also to see if there are any 
solutions to the wear leveling problem.  Thx!

Allison Henderson

>
>>
>> That said, for all normal users, I do think that the zero out is still useful
>> and reasonable.  The simple goal is that once securely deleting, your sys
>> admin cannot use recovery tools or scan a block device and see your deleted
>> file's data blocks.
>>
>> Ric
>>
>> --
>> 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
>>
>
> --

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ