±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 2 Overall: 36006
New Yesterday: 0 Visitors: 137

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

±Latest Videos

±Latest Jobs

linuxfromscratch

Computer forensics discussion. Please ensure that your post is not better suited to one of the forums below (if it is, please post it there instead!)
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Page 1, 2  Next 
  

seanmcl
Senior Member
 

linuxfromscratch

Post Posted: Jan 26, 10 00:01

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.  
 
  

thefuf
Senior Member
 

Re: linuxfromscratch

Post Posted: Jan 26, 10 00:59

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.  
 
  

kovar
Senior Member
 

Re: linuxfromscratch

Post Posted: Jan 26, 10 02:51

Greetings,

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

-David
_________________
CISSP, CCE, EnCE, Licensed Private Investigator (CA) 
 
  

Patrick4n6
Senior Member
 

Re: linuxfromscratch

Post Posted: Jan 26, 10 03:09

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.
_________________
Tony Patrick, B. Inf Tech, CFCE
www.patrickcomputerfor...s.com/blog
www.twitter.com/Patrick4n6 
 
  

thefuf
Senior Member
 

Re: linuxfromscratch

Post Posted: Jan 26, 10 03:13

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).  
 
  

farmerdude
Senior Member
 

Re: linuxfromscratch

Post Posted: Feb 01, 10 23:21

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  
 
  

ecophobia
Senior Member
 

Re: linuxfromscratch

Post Posted: Feb 04, 10 20:53

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?  
 

Page 1 of 2
Page 1, 2  Next