4/8/2023 0 Comments Mount loopback device![]() Ideally, anyone creating a forensic Linux distribution would test it when booting with disks which have "dirty" journals. (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.) You can then traverse the directory of /dev/hda1 just like it was mounted.Īccording to the PDF document I mentioned above, doing this: >mount -o ro /dev/loop1 /media/testThis mounts the loopback device loop1 at /media/test. >Then you can mount the loopback device (read-only if you are paranoid) >losetup -r /dev/loop1 /dev/hda1This creates a read-only loopback device pointing to /dev/hda1 >To do this use losetup to create a loopback device: You don't need to worry about drivers, support, etc. >Then the saving grace - loopback devices. Apparently grml (in forensic mode) does that. 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. to detect whether the medium is write-protected, the driver could read a sector and attempt to write it back.)Īny forensic Linux distribution should by default create all (disk) device nodes with the read-only flag set. (But in theory a badly-written low-level driver might. You just have to trust that the underlying driver won't do that. That doesn't of course prevent writes by the underlying driver (i.e. 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. ![]() 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 Well, the filesystem code will (or *should*) go through the block layer, so using blockdev -setro should be effective. >you test whether the drive actually is in ro without writing? What if >totally agree that blockdev would be based on the driver, but how do Maybe a driver for ntfs totally ignores the ro switch? I don't >my professor brought up the point - these probably depend on the driver You can specify that the blockdev is ro even before mounting. >Another option that I recently found was the 'blockdev' command. It's all too easy to forget and end up writing to the disk. (Maybe "forceload"/"forcerecovery" mount options could be used if the user for some reason does want to replay the journal and mount ro.) 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. For XFS there is "norecovery" and for NTFS-3G there is "norecover". For ext3, the "noload" option is supposed to prevent that happening. writes to the disk) even if "ro" is specified. The filesystem replays the journal on the disk (i.e. For example, partitions which use a journalling filesystem. ![]() >does it? Does it always work? Does it stop everything? >option, which theoretically puts you in a safe read-only state. >For mounting a drive under Linux you have the has the results of some research which was done into various "forensic" Linux boot CDs. A reader sent a very informative email in reply to this single about Read-Only Loopback Devices. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |