Re: Question about secure empty trash/srm
- From: shamino@xxxxxxxxxx (David C.)
- Date: Sun, 10 Jun 2007 16:47:43 GMT
Mike Lindsay <here@xxxxxxxxxxxx> writes:
I know that the Finder (10.3 &10.4) secure empty trash command uses
the Unix srm command. However, I'm unclear about exactly what it's
doing.
Quoting from the srm man page:
srm removes each specified file by overwriting, renaming, and truncat
ing it before unlinking. This prevents other people from undeleting or
recovering any information about the file from the command line.
As the man page says: it overwrites the file multiple times (once, 7
times, or 35 times, depending on the options you run it with.) The
prevents any disk-scavenging software from being able to extract the
data.
The simple one-pass algorithm will work fine for any software that goes
through normal OS channels to read/write disk blocks. The multi-pass
algorithms are designed to randomize the magnetic patterns that the
drive hardware composes the logical bits/bytes from (a simple overwrite
with all-zeros doesn't necessarily reset the magnetic image back to its
factory-provided all-zeros pattern.)
The directory entry (name) is changed. Is only a single character
written to effect the name change, or could a technique such as
magnetic force microscopy retrieve the original directory entry?
You're mixing two different subjects here.
I'm not sure what srm does to the directory entry. I think a few others
have commented on htat.
If MFM data extraction is a serious concern of yours, you're SOL.
Traces of data can remain after dozens of rewrites. An bulk-
demagnetizers sufficiently powerful to wipe the bits of a modern hard
drive platter have to be so powerful that the substrate itself will be
damaged.
If you have something so sensitive that this is a concern, nothing short
of physical destruction of the drive will be sufficient to protect your
data.
Are you really storing data so sensitive that you need to protect
against recovery procedures that only mega-corporations and governments
could affort to pay for?
Truncation means to shorten. Are parts of of the file moved to unused
areas of the disk before overwrite? Probably not.
At the disk-block level, there is no such thing as "moved". Data is
only written (that is copied) and overwritten ("erased"). And as
mentioned before, erasure can never be complete - only good enough for
most purposes.
The definition of unlinking should be obvious - but to someone with
waaay to much time on his hands (like me) it isn't.
Unlinking is a UNIX term for removing a directory entry.
File systems that support UNIX semantics support "hard linking". That
is, multiple directory entries that point to a single file. (This is
different from "symbolic links" and Mac "aliases", which are files
containing data that refers to another file.)
On UNIX systems, a file is "freed" (that is, its disk blocks made
available for other files to use) when the last link (that is, directory
entry) is removed and there are no processes with open handles to the
file.
SRM's documentation says that it overwrite the a file's data and then
unlinks it - that is, it removes the directory entry you ran srm with.
If there are other directory entries (that is, hard links) to the file,
they will remain valid, but will refer to the overwritten-file's
content.
Oh yeah.......................by default journaling is enabled on HSF+
disks. What is it's role in this process?
With journaling, disk-writes are first committed to the journal file
(which can usually be done much faster than writing to other parts of
the disk), and are later copied to the proper place on the disk.
With respect to SRM, I would assume that it makes a point of flushing
the results of each write-pass before beginning the next one. This will
force the writes out of cache to the disk, and presumably out of the
journal file to the actual data area. So this won't affect the storage
location for your file.
It may, however, be possible to scavenge some data from the journal
file. Repeated writes to the same disk block don't necessarily
overwrite the same block in the journal's file. But all writes to the
disk go through the journal, so your data will eventually be overwritten
multiple times anyway.
So, if you write something sensitive and then srm it, and then
immediately remove the drive, it is possible that some of the data may
be extractable from the journal. But that window of opportunity will
shrink rapidly as other files are written to the volume.
If security is that critical, I recommend disabling the journal for your
disk volumes and deal with the fact that reovery from abnormal shutdowns
will be slower and less reliable.
But if you're this serious about security, the disk volume is only one
concern of many. Physically securing the location where the computer is
stored is even more important - restrict who can enter/leave the room,
soundproof it, EMI-shield it, and make sure the computers have no access
whatsoever to the internet (or any other network that isn't entirely
contained within the secure room), and don't install any software (even
system updates) that hasn't been thoroughly reviewed and tested by your
information-security staff.
But do you really need this level of security? If you have a legitimate
need for it, then you are probably working for a defense or intelligence
agency and should already have solid security procedures in-place.
-- David
.
- References:
- Question about secure empty trash/srm
- From: Mike Lindsay
- Question about secure empty trash/srm
- Prev by Date: Re: Mail Photo Question
- Next by Date: Re: Unable to delete some 'hidden' Mac file from Win2003 server
- Previous by thread: Re: Question about secure empty trash/srm
- Next by thread: G4 crashes
- Index(es):
Relevant Pages
|
