Hello,
I wrote a Bash script to automatically write protect a chosen USB device to run on Linux. The script works fine. However, I want it to mount the USB storage device in a forensically sound manner and nothing can be changed in this usb. I got across a paper about mounting the file system in a forensically sound manner, but I'm not sure if what I did consider to be good.
This is the article
Linux for computer forensic investigators «pitfalls» of mounting file
systems
http//
This is what I wrote in the script
mount -o ro,noatime,loop /dev/$USB /mnt/block
blockdev --setro /dev/$USB
This is the USB after it mounted
/dev/sdb1 on /mnt/dev/sdb1 type vfat (ro,noatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
My question is why we use loop when we mount the device and is it necessary to use blockdev –setro after we mount the device. Also, when I was searching I found noatime option and it said this option prevent the system from changing the timestamps, is it?
Thank you.
Hello,
…
This is the article
Linux for computer forensic investigators «pitfalls» of mounting file
systems
http//www.computer-forensics-lab.org/pdf/Linux_for_computer_forensic_investigators.pdf
Hello.
I'm the author of that paper.
This is what I wrote in the script
mount -o ro,noatime,loop /dev/$USB /mnt/block
blockdev --setro /dev/$USB
That's ok, but "noatime" is redundant here ("ro,loop" options together forbid writing to a file system, so no atime updates will pass through).
My question is why we use loop when we mount the device
"loop" option tells mount/libmount code to place a block device on an intermediary loop device (this is often used to mount raw image files). "ro,loop" options combination tells libmount code to switch the intermediary loop device to read-only mode (this is an equivalent of running "blockdev –setro /dev/loop0", but libmount doesn't call any external program). The kernel's loop driver blocks all write and TRIM (discard) commands going through a read-only loop device to the underlying block device. Consider "ro,loop" options as a write protection layer.
and is it necessary to use blockdev –setro after we mount the device
No.
You may also ask can I do "blockdev –setro" BEFORE mounting the device instead of using "ro,loop" options?
The answer is no. The kernel's loop driver blocks all write and discard commands going through a read-only loop device to the underlying block device, but there is no such code in the generic block device driver. It's up to a file system driver to obtain the status of the read-only flag on a block device and to refuse to send write/discard command to such device; if a file system driver ignores the status of the read-only flag on a block device (due to a bug, for example) then write/discard command will be passed to the drive smoothly. As of today, there are many places in the kernel where a driver sends write/discard command to a block device regardless of the read-only flag on that device. That's why you need to use "ro,loop" options every time you want to mount a file system.
Also, when I was searching I found noatime option and it said this option prevent the system from changing the timestamps, is it?
Yes, but as I said before, "ro,loop" options make "noatime" option redundant.
You also need to distinguish mount options from read-only mode on block devices (the latter is described above). Currently there is no universal way to mount a file system truly read-only without using read-only loop devices. For example, running "mount -o ro,noload,noatime" against a block device with Ext3/4 file system will delete all orphan inodes; and there is no file system option to disable orphan inodes deletion (so you always need to use read-only loop device here).
Take a look at the "mount-forensic" script
Thank you very much for all the info thefuf. I didn't expect the same author to answer my questions. I really appreciated.
Try using the hdparm command to change the device to read only BEFORE you mount anything.
Try using the hdparm command to change the device to read only BEFORE you mount anything.
That's dangerous, since kernel can do writes to a block device ignoring the read-only status.
Hi,
I have been testing the timestamps with stat command, but this is what I get.
# stat /mnt/sda1
Size 1024 Blocks 2 IO Block 1024 directory
Device 801h/2049d Inode 1 Links 3
Access (0700/drwx——) Uid ( 0/ root) Gid ( 0/ root)
Access 1970-01-01 000000.000000000
Modify 1970-01-01 000000.000000000
Change 1970-01-01 000000.000000000
and this is before the mounting.
# stat /dev/sda1
File /dev/sda1
Size 0 Blocks 0 IO Block 4096 block special file
Device 5h/5d Inode 1354 Links 1 Device type 8,1
Access (0600/brw——-) Uid ( 0/ root) Gid ( 0/ root)
Access 2014-08-22 121132.000000000
Modify 2014-08-22 120844.000000000
Change 2014-08-22 120844.000000000
How do you check the timestamps in this case?
P.S. I'm root on the system
How do you check the timestamps in this case?
What timestamps do you want to get? Currently you are viewing the timestamps of /mnt/sda1 and /dev/sda1 in a file system of your computer.
How do you check the timestamps in this case?
What timestamps do you want to get? Currently you are viewing the timestamps of /mnt/sda1 and /dev/sda1 in a file system of your computer.
I want to test the write blocker if it works or not. The /mnt/sda1 is the mount point for the write protected device.
I want to test the write blocker if it works or not. The /mnt/sda1 is the mount point for the write protected device.
Try to use MD5 hash function for that
md5sum /dev/sda1 (execute this before and after mounting a file system and compare the values)
You can also try to debug IO functions
1) execute "sysctl vm.block_dump=1" to enable debugging;
2) all read/write requests will be logged to the syslog ("less /var/log/syslog" or something similar to view all read/write requests made, write requests will look like "WRITE block 821424 on dm-1 (8 sectors)");
3) execute "sysctl vm.block_dump=0" to disable debugging.