Write-Protection us...
 
Notifications
Clear all

Write-Protection using Linux

6 Posts
5 Users
0 Likes
1,348 Views
(@a_kuiper)
Posts: 69
Trusted Member
Topic starter
 

Does anyone know of any research how to write-protect devices with Linux.

The most obvious way is via fstab. Also autofs can be configured to mount devices read-only.

I am quite certain both ways (done properly *g*) are forensically sound. You may prove me wrong!

Are there any other ways write-protecting devices with Linux?

Only software-solutions please… no hardware ;).

Cheers!

 
Posted : 22/01/2011 5:53 pm
(@athulin)
Posts: 1156
Noble Member
 

The most obvious way is via fstab. Also autofs can be configured to mount devices read-only.

There's an interesting paper called 'The Fallacy of Software Write Protection in Computer Forensics' by Mark Menz & Steve Bress – you may want to read it (just Google for it).

Their conclusion is simple economy – the cost saved will very probably be lost later when the case is prepared for court.

You also want to read Ernst Baca's report 'Knoppix Bootable CD Validation Study for Live Forensic Preview of Suspects Computer', in which the conclusion begins

"It was quite startling to find that mounting EXT3 and reiserfs partitions read-only changed the state of the drive."

Things may have improved since.

>You may prove me wrong!

I don't think so – it's more probably you who have to convince the court (or equivalent body) that the method you used is sound.

So how have you verified that the method you propose is sound? May we see your test method and protocols?

NIST has a 'Software Write Block Tool Specification & Test Plan' that you might be interested in. And very close to that report, they also have links to test reports for a few soft solutions for write blocking, though they all seem to be for DOS/Windows.

 
Posted : 23/01/2011 12:13 am
(@thefuf)
Posts: 262
Reputable Member
 

The best way to write-protect storage devices in Linux is to disable any mounting scripts and use 100% read-only tools like TSK to examine the data. Unfortunately, there are no ways to boot Live CDs based on Ubuntu/Debian and KNOPPIX without mounting file systems on hard disk drives, except the way of changing the boot scripts (there are some modifications used by grml, CAINE, DEFT Linux, PALADIN and Raptor distros that disable any writes to evidentiary media during the boot).

If you want to forensically mount a file system then use "-o ro,loop" options - I never captured a write command passed through a read-only loopback device ("loop" is required even when mounting a block device, not a regular file (i. e. dd image), since it successfully blocks all writes sent by buggy file system drivers when using only "ro" option). Setting block devices to read-only mode ("blockdev –setro /dev/sda1", "hdparm -r1 /dev/sda1") is ineffective.

You can also look at several reports (sorry for bad English in them wink )
http//www.computer-forensics-lab.org/pdf/Linux_for_computer_forensic_investigators_2.pdf
http//www.computer-forensics-lab.org/pdf/Linux_for_computer_forensic_investigators.pdf

I'm also aware of at least one forensic distribution that claims to mount devices in read-only mode, but actually sends tons of write commands when working "read-only" with some file system types, but the data remains unchanged, so it is probably overwriting data with the same data D

 
Posted : 23/01/2011 1:08 am
nannib
(@nannib)
Posts: 13
Active Member
 

You can also look at several reports (sorry for bad English in them wink )
http//www.computer-forensics-lab.org/pdf/Linux_for_computer_forensic_investigators_2.pdf
http//www.computer-forensics-lab.org/pdf/Linux_for_computer_forensic_investigators.pdf

Hi, those reports regards old releases of Caine, the version 2.0 is fully patched against any type of mounting, TheFuf gave me a special patch for avoiding the fake-casper problem too wink

In any case….if you boot by Caine, you can see that any device is mounted, so you can make a forensically sound image file directly using as source /dev/sdX.

bye

 
Posted : 23/01/2011 12:50 pm
(@a_kuiper)
Posts: 69
Trusted Member
Topic starter
 

Thanks for the comments lads ).

From what I found out for instance the Linux-distribution grml uses blockdev and a dynamically generated fstab (rebuildfstab). Seemingly the fstab can be made to protect the filesystem but not other "actions" which could occur to a HDD (swapping, journalling - if supported…).

So working with a write-protected (via fstab) HDD could be a risky whilst simple acquisition might be fine. Obviously this is not forensically sound and with RAID-systems it is advisable to use a hardware write-blocker.

 
Posted : 23/01/2011 7:08 pm
(@hydrocloricacid)
Posts: 37
Eminent Member
 

Re GRML

I emailed their support regarding the above quoted paper and they told me the following

The attack mentioned in the referenced paper was against an older version of Grml.
We discussed this issue with the author of the paper back those days and came up with different approaches to solve this issue.
This issue is no longer present in current versions of Grml and we even have additional protection methods built into Grml-Forensic (and are working on further features to make the system forensically sound for any possible situation).

 
Posted : 31/01/2011 2:49 am
Share: