Trash, Delete, Shred

[Keunwoo Lee]

Delayed reply...

On Thu, 3 Jul 2003, Michael S. Mikowski wrote:

> I took a look at the documents but didn't see a reference to journaled
> file systems [jfs].  Perhaps you can give me some pointers, if you have
> a minute.
> 
> My impression is that "shredding" means overwriting the entire file
> contents *on the physical disk* with random bits perhaps 3-4 times.  
> From what you have written it appears that shredding value is impossible
> on jfs.  My limited understanding of jfs is that old data remains on the
> disk until new data is committed.  Is the trouble that it is impossible
> to physically overwrite the "old" data?

I am not aware of papers that specifically discuss secure deletion on
journaled file systems.  However, the essence of the problem is that on a
journaling or log-structured file system, it is not clear which disk
blocks a file has been written to.

On a traditional filesystem, a file gets written to a certain set of
blocks on disk, and it stays in those blocks until the OS reclaims those
blocks (the file's deleted + overwritten, or the disk gets defragged).  
On a journaled file system, data gets written to the journal, then later
moved/copied to its "permanent" location.  In the process, depending on
the jfs implementation, both the file and the journal could end up using a
different set of blocks, so that even overwriting both the file's current
blocks and the entire current journal won't necessarily overwrite all
traces of the file's data.  (Not to mention that overwriting the entire
current journal may not be an operation the fs supports in the first
place.)

> Do you know if any jfs does or will support a "shred" capability?

None to my knowledge.  Designing a stable, high-performance journaling FS
is a tricky enough business.  Shredding isn't high on the list of
priorities.  When security really matters, people rely on the incinerator.

> > The result eventually will be that most users are working on
> > filesystems that don't support shredding, but the menu option will be
> > there anyway.  Of course, one could put off removing the menu option
> > until that day arrives.
> 
> It would be good if the option were grayed-out if shredding wouldn't
> work...

It is rather difficult for software to know whether shredding will work.  
You could imagine

 (1) reverse-resolving the file:/// URL to its partition
 (2) looking up the partition type in /etc/mtab or /proc/mounts
 (3) matching that type against a catalog of known filesystem types that 
     *may* support shredding

But even this might not work---the disk hardware may write redundant
copies of the data in places that can later be accessed by sufficiently
privileged software (e.g., a device driver).  Plus, /etc/mtab and
/proc/mounts are Linux-isms that are not available on other Unices (e.g.
Solaris does not support them).  In short, attempting to write software
that even detects when shredding *might* work would be a maintenance
nightmare.

BTW this thread appears to have forked off on kde-usability separately
from kfm-devel:

http://lists.kde.org/?t=105676309000002&r=1&w=2

Waldo's point that the file may have been written to any number of places
by software layers *above* the filesystem (e.g. the browser) before
arriving at its present location is a good one.

Anyway, this is all getting long-winded.  Bottom line:

1. Physical-layer attacks are beyond the scope of our concern.

2. Shredding effectively prevents software-layer attacks in certain
circumstances.

3. However, we can't detect automatically whether those circumstances
actually hold.

Based on these bullets, I am inclined to agree that shred doesn't belong
in the GUI.  Anyone sophisticated enough to know whether shred might work
will be familiar with the console.  Anyone else will only be deceived by
the shred option.

~k

-- 
GPG public key id: 0x5CFD1761 (available on a key server near you)