ext2 not NULLing deleted files?

Hi there,

I just recognized there's an "undelete" now for ext2 file systems [a KDE app].

"The Other OS" in its professional version does of course clear the deleted blocks with 0's for security reasons; I would have bet a thousand bucks Linux would do so, too [seems I should have read the source code, good thing no-one wanted to take on the bet :) ].

So how to go about this? With that feature wanted, which fs should one choose under Linux? Is there a patch for ext2 for that feature? Am I the only one liking the idea?

Greetings,
Enver

By "The Other OS" I assume you mean NT. NT does _not_ zero files on delete, either with NTFS or anything else. It merely unlinks them like any other OS. I can't think of anything that nullifies files, except utilities meant solely to do that (often called "sweeping").

Do you have any idea how long it would take to zero files? If you removed even a moderately sized directory, it would take a _very long_ time.

Robert M. Love
rml at ufl.edu
rml at tech9.net

In article <01081709381000.08800@haneman> you write:

That's not much more than a smoke screen, actually. Wiping out data from a disk requires more than merely writing 0's, if the bad guy is assumed to physically have hold of the disk. See, for instance, the paper from Peter Gutmann, "Secure Deletion of Data from Magnetic and Solid-State Memory" (published in Usenix'96). Such games are much dependant on the actual writing technology, and harddisk cache (which cannot be deacticated on some modern IDE disks) gets in the way. Besides, performance is terrible (if you need to rewrite seven times a file with different patterns for each deletion, imagine what happens when you delete a 100 MBytes file...).

The only truly secure way to do is encryption: if all data that gets to the disk is encrypted, physical details about the disk are unimportant, so security cannot be compromised by some smarter physicist with more expensive tools.

--Thomas Pornin

While there is an ext2 file attribute which sets "secure deletion" on a per-file basis, it has never been implemented in the kernel. Several reasons for this:

1) Deleting a file really securely takes more than just a single write of zeros to the disk.
2) It would be a huge performance hit to overwrite a file the 15? or so times (some random, some patterned data) to really securely delete a file.
3) This is easily implemented in user-space, either by aliasing "rm" to a new function, or actually putting in your own "rm" binary which checks for the "S" attribute on ext2 files, and overwrites properly it if it a file only has a single link. Then people can implement a level of security they are comfortable with for their particular needs.
4) Anything that really needs to be secure should not be stored in an insecure manner to begin with. It should only be written to disk in encrypted form (see (a) and (b) above for why), and you also need something like tmpfs + encrypted swap so that you don't get unencrypted copies written to disk by mistake. Reasons for this are manyfold. With enough money and technology it is nearly impossible to really "delete" anything that was written to disk. If it gets written on another part of the disk, you also have to scrub that (think /tmp or swap for editing documents). If you make any backups of the disk, you need to scrub the tapes for every deletion (while keeping copies of all your other documents), very hard.

Cheers, Andreas

Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

not new.

(assuming NT)

No it doesn't, and there even has been cases in the past where its journaling filesystem was, under some conditions, extending files with old data blocks without deleting them (a bit like the OLE `let's put anything which is in RAM in this MS-Word file'), allowing other users to snoop on each other's data / deleted data [no references sorry, from memory].

Special care, as far as I understand it, must be taken when allocating fs data blocks. The following sequence must be followed:

1. reserve them
2. clear them
3. mark them as allocated.

if 2 is too expensive, maybe it's sufficient to mark them as dirty and zero them in memory. But what happens if the system crashes, with the metadata to the disk (block allocated), but the data block not yet filled/zeroed ?

Maybe some flags somewhere telling that those data blocks are allocated but not yet committed ?

Ext2 and ext3 both do this already (with caveats). Since ext2 doesn't impose write ordering constraints, there is not a hard guarantee that the data block makes it to disk before the metadata is updated. If you run ext3 in data=ordered or data=journal mode, then you do have such a guarantee.

If you run in data=writeback mode, you basically have the same situation as ext2 (data may be written before or after the metadata). This is the same as the _current_ reiserfs code, but there are apparently patches available which allow data=ordered mode also.

Cheers, Andreas

Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

VMS. "DELETE/ERASE FOO.BAR" I don't recall whether it's done by the filesystem code or by the DELETE command in userspace, but I'm guessing it's built into FILES-11. (Sorry, my Gray Wall is at home.)

That's why it's optional.

Mark H. Wood, Lead System Programmer   [email protected]
Make a good day.

Regarding the need to do more than just zero unwanted data, I note that there is a U.S. DOD MIL-SPEC (no, I do not know the number) which defines a sequence of patterns to be used for erasing magnetic media. VMS has a hook on which one may hang one's own erasure pattern generator, and I think DEC provided an unsupported implementation of the MIL-SPEC patterns as an example of its use. INITIALIZE /ERASE can use the patterns, but I don't recall whether DELETE /ERASE does. If you don't provide a generator, I think erasure just uses zeros.

I recall hearing that highly-classified data must be destroyed by physically shredding the medium. Yes, throw your disk drive in the shredder! (Just imagine the class of machinery required to digest an RA81 HDA.)

Most of this goes way beyond the need to deter casual snooping.

Mark H. Wood, Lead System Programmer   [email protected]
Make a good day.

In the Usenix paper quoted earlier in this thread (I believe) it was stated that the MIL-SPEC document was actually bogus. REAL secure deletion requirements were much more strict (something like 15 passes of various random and non-random patterns vs. 7 passes of alternating all 0 and all 1 data), but the US government made it think that the MIL-SPEC requirements were enough, so that naive users would follow it, still leaving enough trace data on the disk for the government to retrieve it.

Still, even a single pass of zero writes is enough to prevent 99.9% of attackers from getting the data back.

Cheers, Andreas

Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Bad, the file may still be open and in use. So this rm would 1) destroy work data and 2) leave the data in clear that are written after the sweep.

Andreas E. Bombe <[email protected]>    DSA key 0x04880A44