Notifications
Clear all

linuxfromscratch

8 Posts
6 Users
0 Likes
443 Views
(@seanmcl)
Posts: 700
Honorable Member
Topic starter
 

I debated starting this in Open Source but the issue is less about open source and more about whether there would be value to the community to do something like what I am about to suggest.

What started this idea was the discussion of pyFlag and the fact that I have had some difficulty compiling it with 64-bit Linux and the latest libs/etc.

For the last five to seven years, I have been building my own forensic Linux kernels using the Hardened Linux From Scratch toolchain (http//www.linuxfromscratch.org). My reasons were many

First, many of the distros that I had seen were heavily bloated, and did not lend themselves well to Live CD/DVDs. I wanted a distro that had only the programs that I needed

Second, I often found problems with compiling the various programs with which I most often worked due incompatibilities with headers, libraries, GCC versions, etc.

Third, I wanted certain security features such as GRSecurity PaX kernel, position independent executables, process randomization, etc., which were, then, only available in experimental kernels.

Fourth, I wanted to customize the boot process so as to avoid common issues that made some Linux distros forensically unsound.

Fifth, I wanted to have a reliable schedule for updates which incorporated a repeatable testing methodology.

Finally, I wanted a well documented toolchain build which would fully document each step of the system build process, from beginning to end.

I wonder what, if any, support exists in this forum for the creation of a community build process for a forensic Linux distro?

I realize that there are many good flavors of such out there, already, and rather than compete with these I would look at this process as a way to build consensus toward a common platform.

The advantage for the developers of tools would a stable implementation against which to code.

The advantage for users of the build would be a community review process which could help address pseudo-concerns about "open source" forensics.

Last but not least, it would give the participants a better understanding of what is going on under the hood, especially insofar as development of testing and validation tools is concerned.

 
Posted : 25/01/2010 11:01 pm
(@thefuf)
Posts: 262
Reputable Member
 

Hi!

I think this is a great idea. But I would give my vision of the problem first

The main problem of all open source forensic Live CDs is that when user asks "is that Live CD forensically sound?" he would receive replies like "test it yourself". The next step that most users in this situation would perform is to verify a hash value for a tested file system before and after the boot, before and after the mount and so on. This approach has a very serious weak point most users do not know what they should do.

For example I have discovered recently that most Ubuntu-based forensic Live CDs do recover damaged Ext3 file systems during the boot. Most Live CD developers were not able to reproduce the bug during the first N tests and suggested that bug does not exist. Later, they confirmed and fixed it. One of the questions I asked myself why this bug was not noticed before? I think the answer is that there were no tests conducted with damaged (e.g. by not unmounting before shutting the system down) Ext3/4 file systems.

Another example is a bug discovered by grml developer when (un)mounting XFS file systems (no matter what mount options are used, except the situation with read-only loopback devices) a write command is passed to the drive.

There were also other issues discovered how writeblocking failes in Raptor Live CD and, the most sweet one, how most Live CDs can boot a system from a HDD without user's permission (currently, there are only two forensic distributions that do not have this bug - RIPLinux and SMART Slackware).

There were also many cases when Live CD developers made false claims about their products.

So, I think, there is a need to develop a list of common "fail situations" for both users and developers knowledge. Perhaps, together with "how-to build forensically sound system from Ubuntu". I already started to write the first one.

 
Posted : 25/01/2010 11:59 pm
(@kovar)
Posts: 805
Prominent Member
 

Greetings,

Do you have a citation for the Raptor writeblocking failure? I'd love to see more details on this.

-David

 
Posted : 26/01/2010 1:51 am
(@patrick4n6)
Posts: 650
Honorable Member
 

Also, whilst unmounting a drive might result in an attempted write command, this would only be an issue if you were only using R/O mounting as your form of protection. The whole idea of write protection is to protect against both unintentional and intentional writes. Hence if the drive is locked at a lower level than the unmount in your particular example is working, then although the OS might try to write, the write will be prevented. Please therefore distinguish as to whether in your XFS example, whether the drive itself were locked - with for example hdparm - or whether in that test they were relying soley on mount -r as their protection mechanism.

 
Posted : 26/01/2010 2:09 am
(@thefuf)
Posts: 262
Reputable Member
 

Do you have a citation for the Raptor writeblocking failure?

Two issues here

1) Previous release (before Raptor 20091026) activated swap partitions and tried to writeblock them by running "hdparm -r1 /dev/<device>". It failed;
2) Current release and previous release do pass ATA write commands when working with XFS even when the block device is "write-blocked" using hdparm (thanks to kernel bug).

Please therefore distinguish as to whether in your XFS example, whether the drive itself were locked - with for example hdparm - or whether in that test they were relying soley on mount -r as their protection mechanism.

I do distinguish it. However, some time ago I thought that setting the block device r/o itself would solve the problem. But later tests showed that to be false (the only way to protect yourself from XFS writes on older kernels is to use "-o ro,loop" options).

 
Posted : 26/01/2010 2:13 am
(@farmerdude)
Posts: 242
Estimable Member
 

I think that you should choose your words carefully when making statements such as … "(currently, there are only two forensic distributions that do not have this bug - RIPLinux and SMART Slackware)".

This statement is _incorrect_. THE FARMER'S BOOT CD (FBCD) also does not "have this bug" as you say.

Perhaps wiser wording might be "Of the CDs I have tested, I have found these distributions to not have this bug…".

Cheers!

farmerdude

www.onlineforensictraining.com

www.forensicbootcd.com

 
Posted : 01/02/2010 10:21 pm
ecophobia
(@ecophobia)
Posts: 127
Estimable Member
 

Spot on farmerdude.

thefuf, if you had a chance to test any of these Forensic Live CD's, would you mind sharing your findings with us?

 
Posted : 04/02/2010 7:53 pm
(@thefuf)
Posts: 262
Reputable Member
 

thefuf, if you had a chance to test any of these Forensic Live CD's, would you mind sharing your findings with us?

OK.

Distributions that recover damaged Ext3 file systems on HDDs during the boot
Helix3 2009R1, SMART Linux (Ubuntu) 2010-01-20, FCCU GNU/Linux Forensic Boot CD 12.1, SPADA 4 (write-blocking is applied after recovery).

Distributions that allow booting using malicious root file system images on connected HDDs
Helix3 2009R1, Helix3 Pro 2009R3, CAINE 1.5, DEFT Linux 5, Raptor 20091026, grml 2009.10, BackTrack 4, SMART Linux (Ubuntu) 2010-01-20, FCCU GNU/Linux Forensic Boot CD 12.1, SPADA 4, LinEn Boot CD, BitFlare 1.3.3.

I have listed only latest versions of Live CDs tested. If you need proof-of-concept disk images used during root file system spoofing tests then send me a PM.

 
Posted : 09/02/2010 3:16 pm
Share: