MattockFS (A strangely hybrid file-system)

Though originally not in any way capability related, the Computer 
Forensics project I'm currently working on ended up becoming a weird 
hybrid of what is basically a read-only CF file-system that allows the 
logical equivalent of pointer arithmetic with a stricter set of 
sparsecap enforced operation possibilities for things that will end up 
expanding the data in the file-system.

I just created a 'Wall-o-Text' web-page describing the outline of what 
I'm working on. I thought it may hold some interesting aspects for some 
of the Friam/cap-talk crowd.

  http://pibara.github.io/MattockFS/

The most relevant chunks:

"MattockFS is a Computer Forensics File-System. More accurately, it's a 
user-space file-system that aims to provide a major part of the 
underpinning of an envisioned message-passing based Computer Forensics 
Framework for use in a Computer Forensics laboratory. MattockFS aims to 
be a component in a Computer Forensics Framework aimed at medium to 
large scale investigations that is suitable for both professional 
investigation settings yet also suitable as basis for a framework that 
takes into account the need for compatibility with a more academic 
setting. MattockFS is not a full Digital Forensics Framework. Rather, 
MattockFS is a central component for a three part Computer Forensics 
Framework. It performs multiple key functionalities that a Computer 
Forensics Framework requires, and fulfills a linking function between 
the other two sub-frameworks."


"MattockFS will provide the per-node access to one of the data 
repositories, more on this below. While read-access is provided 
globally, MattockFS provides strict context and access control for 
adding and unforgeable provenance logged access to any writing 
operations. "


"We consider the use of a seperate UID and the use of the file-system as 
writing and logging deputy to be essential privilege separations 
constructs for the overall robustness of the Mattock framework. We take 
the conservative approach that a single unaudited third-party module 
having the power to corrupt the archive or the provenance log as a 
result of hostile-data processing should be considered an unacceptable 
risk for large-scale multi-module processing setups. The data corruption 
capacity of the archive data by a vulnerable tool should be limited to 
those parts of the archive ascribable to the vulnerable tool. "

"After the module is finished creating the file, MattockFS allows the 
module to freeze the mutable data and obtain a CarvPath to the frozen 
read-only version of the file."

"While MattockFS in general is meta-data achnostic (MattockLib generated 
meta-data is treated as just an other mime-type), our privileged 
separation needs require lab-side provenance related meta-data to be 
handled by MattockFS. We do this by creating a first provenance record 
when the first job in a tool-chain is created, appending a short 
provenance record for each consecutive job, and writing all records (as 
single-line JSON) to a provenance log file."

"As shown in MinorFS, just using sparse capabilities is insufficient a 
guard against such issues. MattockFS implements a sparse capability 
based interface as FS based API, but the use of mandatory access control 
(like AppArmor) should be considered to fully secure the forensic 
process from integrity attacks through vulnerable modules."

Any input b.t.w is greatly appreciated.

Kind Regards,

Rob