[cap-talk] MattockFS (A strangely hybrid file-system)

[rmeijer]

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
_______________________________________________
cap-talk mailing list
cap-...@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk