From: Jesse Pollard <pollard@admin.navo.hpc.mil>
To: "Albert D. Cahalan" <acahalan@cs.uml.edu>, linux-kernel@vger.kernel.org
Cc: kentborg@borg.org, alan@lxorguk.ukuu.org.uk, jgarzik@pobox.com
Subject: Re: Where is ext2/3 secure delete ("s") attribute?
Date: Fri, 22 Nov 2002 08:13:12 -0600 [thread overview]
Message-ID: <200211220813.12136.pollard@admin.navo.hpc.mil> (raw)
In-Reply-To: <200211220122.gAM1MQY305783@saturn.cs.uml.edu>
On Thursday 21 November 2002 07:22 pm, Albert D. Cahalan wrote:
> Alan Cox writes:
> > On Thu, 2002-11-21 at 19:05, Kent Borg wrote:
> >> Another example of why this needs to be done in the file system. (And
> >> that help is sometimes needed from the "disk" particularly in cases
> >> like flash IDE rives.)
> >
> > The file system can't do it
> > The flash device won't give you the info to do it
> > The ide disk wont give you the info to do it
>
> That's being an idealist. You can protect against everybody
> except the NSA and the disk manufacturer. Most likely they'd
> need to spend lots of money in a clean room to get your data.
incomplete list....
NSA
DoD
Homeland Defense gestapo
disk manufacturer
anybody willing to spend about $1000-$5000.
And I'm not sure it is impossible to just reset the bad block list either.
I've been able to do that to SCSI drives in the past, so I think it is
still possible to do.
> Forget the shred program. It's less useful than having the
> filesystem simply zero the blocks, because it's slow and you
> can't be sure to hit the OS-visible blocks. Aside from encryption,
> the useful options are:
>
> 1. plain old rm (protect from users)
> 2. filesystem clears the blocks (protect from root/kernel)
> 3. physically destroy the disk (protect from NSA & manufacturer)
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
next prev parent reply other threads:[~2002-11-22 14:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-22 1:22 Where is ext2/3 secure delete ("s") attribute? Albert D. Cahalan
2002-11-22 1:30 ` Jeff Garzik
2002-11-22 2:41 ` Albert D. Cahalan
2002-11-22 4:39 ` Jeff Garzik
2002-11-22 5:55 ` Albert D. Cahalan
2002-11-22 7:12 ` Ingo Oeser
2002-11-22 13:38 ` Alan Cox
2002-11-22 13:27 ` Nikita Danilov
2002-11-22 2:06 ` Mike Dresser
2002-11-22 14:13 ` Jesse Pollard [this message]
2002-11-22 21:31 ` Krzysztof Halasa
-- strict thread matches above, loose matches on Subject: below --
2002-11-24 6:40 Albert D. Cahalan
2002-11-21 18:20 Marc-Christian Petersen
2002-11-21 22:43 ` Harald Arnesen
2002-11-21 17:52 Kent Borg
2002-11-21 18:24 ` Jeff Garzik
2002-11-21 18:39 ` Kent Borg
2002-11-21 19:20 ` Alan Cox
2002-11-21 19:05 ` Kent Borg
2002-11-21 20:28 ` Alan Cox
2002-11-21 19:14 ` Jeff Garzik
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=200211220813.12136.pollard@admin.navo.hpc.mil \
--to=pollard@admin.navo.hpc.mil \
--cc=acahalan@cs.uml.edu \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jgarzik@pobox.com \
--cc=kentborg@borg.org \
--cc=linux-kernel@vger.kernel.org \
/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.