In response to a previous post about using the hdparm command as a
software write-blocker, a couple people sent private e-mails
suggesting a hardware write-blocker should always be used.
One particular concern was that doing Linux read-only mount of a
filesystem does make small changes to the filesystem and causes the
md5 hash to change.
Below are my thoughts of why this is not really feasible and expresses
my hope that linux software write-blockers be implemented:
=====
I agree that mounting a drive read-only from Linux has the opportunity
to modify the original.
The fact that linux does so is a bug, and is recognized by at least
one filesystem support team as such. (XFS from SGI).
Still the bug has existed in various versions of the linux kernel for
various filesystems at various times, so I agree it is definately best
practice to not mount subject drives.
OTOH, I do not think I will ever have all the write-blockers necessary
to successfully image (and protect) ATA, SATA, SCSI, SAS, FC, USB,
Firewire, Flash, etc.
Further, I have no idea how to image a truly complex hardware RAID
like the Compaq Smart Array series one disk at time. The RAID
segments are dynamic and moved around between the drives as drives are
added/deleted. Only by using the existing RAID controller can one
hope to get a coherent image.
For these more complex setups, I prefer to boot to Linux and perform a
read-only dd/md5sum images if we can.
I'm currently depending on my skills (quite extensive) with Linux to
ensure I do not make a mistake and inadvertently modify the subject
drive (or logical volume in hardware RAID).
It is my hope is that Linux will eventually have low-level software
write-blockers that will prevent even buggy kernel code from modifying
the subject drive under analysis.
From my rather limited understanding of the Linux 2.6 Kernel, there
are only 3 fundamental storage types supported: Traditional IDE, Newer
ATA, and SCSI. Most of the newer systems are being mapped into the
SCSI architecture.
If that is true, it may be possible for as few as 3 software
write-blocker modules to be developed.
-----------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com
