I don't think that any of the attacks Wietse discussed are related to actually reading things out from underneath multiple disk-write cycles (though he does cite Peter Gutmann's 1996 paper on microscopic attacks, but the paper applied to older hard disks).
Everything else is about keeping track of the behaviour of the filesystem code, and making sure the writes hit the disk in the right place [*]. I haven't audited the shred code, but I hope Wietse's bugs have been fixed! [*] One nasty gotcha there is the issue of the disk firmware moving blocks around without telling the operating system at all. I guess in an ideal world, chattr +s would get the OS to tell the firmware to always shred the blocks in that file. On Thu, 2007-05-03 at 23:54 +0100, James Youngman wrote: > On 5/3/07, Peter Eckersley <[EMAIL PROTECTED]> wrote: > > > We're certainly working on making sure that userspace chattr()s the > > attribute. Apparently, for many journalling filesystems (ext3 and maybe > > Reiser, IIRC), shred should still work pretty well as-is -- I guess > > that's because the filesystem promises metadata consistency, not data > > consistency. For the others, we can certainly ping the developers about > > it. We could potentially work on patches too, but that's less likely > > unless there's an obvious case where the patch would make a lot of > > real-world difference. > > There is a very interesting presentation by Wietse Venema which > discusses this in detail (and, sadly, demonstrates that it is much > harder to do this reliably that one might think). > I can't find a link to the talk but there is an HTML version of it in > the Google Cache at > > http://66.102.9.104/search?q=cache:fNI_tJkUHzIJ:www.hack.lu/images/8/80/Venema.ppt+Venema.ppt&hl=en&ct=clnk&cd=3 > > I think his comments about this relate mainly to ZFS and ext3, though. > > James. -- Peter Eckersley [EMAIL PROTECTED] Staff Technologist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
