All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ric Wheeler <rwheeler@redhat.com>
To: "Ted Ts'o" <tytso@mit.edu>
Cc: Andreas Dilger <adilger@dilger.ca>, Mingming Cao <cmm@us.ibm.com>,
	Amir Goldstein <amir73il@gmail.com>,
	Allison Henderson <achender@linux.vnet.ibm.com>,
	linux-ext4@vger.kernel.org
Subject: Re: [PATCH 1/2 v3] EXT4: Secure Delete: Zero out file data
Date: Mon, 11 Jul 2011 07:42:11 +0100	[thread overview]
Message-ID: <4E1A9B43.8020800@redhat.com> (raw)
In-Reply-To: <20110710233307.GE5615@thunk.org>

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

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2011-07-11  6:42 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-30 21:22 [PATCH 0/2 v3] EXT4: Secure Delete Allison Henderson
2011-06-30 21:22 ` [PATCH 1/2 v3] EXT4: Secure Delete: Zero out file data Allison Henderson
2011-06-30 22:15   ` Andreas Dilger
2011-07-01  0:54     ` Allison Henderson
2011-07-01  1:18       ` Martin K. Petersen
2011-07-01  1:41         ` Allison Henderson
2011-07-01 10:26   ` Lukas Czerner
2011-07-01 16:21     ` Allison Henderson
2011-07-02  9:33   ` Amir Goldstein
2011-07-03  7:00     ` Andreas Dilger
2011-07-03  7:37       ` Amir Goldstein
2011-07-04 17:19         ` Allison Henderson
2011-07-04 17:44           ` Amir Goldstein
2011-07-04 18:19             ` Andreas Dilger
2011-07-04 19:09               ` Allison Henderson
2011-07-06 21:05     ` Allison Henderson
2011-07-07  7:05       ` Amir Goldstein
2011-07-07 19:52         ` Andreas Dilger
2011-07-07 20:19           ` Allison Henderson
2011-07-08  0:09             ` Amir Goldstein
2011-07-08  1:55               ` Allison Henderson
2011-07-08  6:29                 ` Amir Goldstein
2011-07-08 20:43                   ` Allison Henderson
2011-07-10 23:13                   ` Ted Ts'o
2011-07-11 10:01                     ` Amir Goldstein
2011-07-08  2:46               ` Andreas Dilger
2011-07-08  5:46                 ` Ric Wheeler
2011-07-08  6:11                 ` Amir Goldstein
2011-07-08 18:20               ` Mingming Cao
2011-07-08 23:49                 ` Andreas Dilger
2011-07-10  8:19                   ` Ric Wheeler
2011-07-10 23:33                     ` Ted Ts'o
2011-07-11  6:42                       ` Ric Wheeler [this message]
2011-07-11  8:20                         ` Lukas Czerner
2011-07-11 14:24                           ` Allison Henderson
2011-06-30 21:22 ` [PATCH 2/2 v3] EXT4: Secure Delete: Zero out files directory entry Allison Henderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E1A9B43.8020800@redhat.com \
    --to=rwheeler@redhat.com \
    --cc=achender@linux.vnet.ibm.com \
    --cc=adilger@dilger.ca \
    --cc=amir73il@gmail.com \
    --cc=cmm@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.