From kfm-devel Wed Jul 09 00:13:36 2003 From: Keunwoo Lee Date: Wed, 09 Jul 2003 00:13:36 +0000 To: kfm-devel Subject: Re: Trash, Delete, Shred X-MARC-Message: https://marc.info/?l=kfm-devel&m=105770965822522 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)