RE: Read-Only Loopback to Physical Disk
http://www.denisfrati.it/pdf/Linux_for_computer_forensic_investigators.pdf has the results of some research which was done into various "forensic" Linux boot CDs.
>For mounting a drive under Linux you have the
>standard 'mount' command. When mounting you can specify the -o ro
>option, which theoretically puts you in a safe read-only state... or
>does it? Does it always work? Does it stop everything?
It definitely does not always work. For example, partitions which use a journalling filesystem. The filesystem replays the journal on the disk (i.e. writes to the disk) even if "ro" is specified. For ext3, the "noload" option is supposed to prevent that happening. For XFS there is "norecovery" and for NTFS-3G there is "norecover".
IMO that's a terrible design decision; apart from the needlessly-differing option names, no writes at all should be done when "ro" is specified. (Maybe "forceload"/"forcerecovery" mount options could be used if the user for some reason does want to replay the journal and mount ro.)
It's all too easy to forget and end up writing to the disk.
>Another option that I recently found was the 'blockdev' command. You can specify that the blockdev is ro even before mounting.
>blockdev --report
>blockdev --setro /dev/device
>But
>my professor brought up the point - these probably depend on the driver
>used. Maybe a driver for ntfs totally ignores the ro switch? I don't
>totally agree that blockdev would be based on the driver, but how do
>you test whether the drive actually is in ro without writing? What if
>it fails?
Well, the filesystem code will (or *should*) go through the block layer, so using blockdev --setro should be effective. However, partitions don't seem to inherit the read-only flag! In other words, if you have a hard disk /dev/sda with a single partition /dev/sda1, you can do
blockdev --setro /dev/sda
but if you then do
blockdev --getro /dev/sda1
you'll notice that sda1's read-only flag is not set! I haven't verified yet whether sda1 can be written to in those circumstances.
That doesn't of course prevent writes by the underlying driver (i.e. SCSI). You just have to trust that the underlying driver won't do that. (But in theory a badly-written low-level driver might. E.g. to detect whether the medium is write-protected, the driver could read a sector and attempt to write it back.)
Any forensic Linux distribution should by default create all (disk) device nodes with the read-only flag set. That should provide another layer of confidence, in that the user must manually "blockdev --setrw /dev/name" before being able to write to the device. Apparently grml (in forensic mode) does that.
>Then the saving grace - loopback devices. Mount the partition as a file. You don't need to worry about drivers, support, etc.
>To do this use losetup to create a loopback device:
>losetup -r /dev/loop1 /dev/hda1This creates a read-only loopback device pointing to /dev/hda1
>Then you can mount the loopback device (read-only if you are paranoid)
>mount -o ro /dev/loop1 /media/testThis mounts the loopback device loop1 at /media/test. You can then traverse the directory of /dev/hda1 just like it was mounted.
According to the PDF document I mentioned above, doing this:
mount -o ro,loop /dev/hda1 /media/test
should work in a similar way. (But to be sure, you'd need to check the source to see whether mount passes the "-r" option to losetup if ro and loop are specified...)
Ideally, anyone creating a forensic Linux distribution would test it when booting with disks which have "dirty" journals. Are there any hardware write-blocker products which will e.g. sound a buzzer when any write is attempted?
Thanks of the comments Mark!
