MattockFS; Computer-Forensics File-System : Part Two

This post is the second of an eight-part series regarding the MattockFS Computer-Forensics File-System. This series of post will be based on the MattockFS workshop that I gave at the Digital Forensics Research Workshop three months ago in Überlingen Germany.

In Part One we discussed the concepts of asynchonous processing and the tool-chain approach and how these two concepts do and don't work well together within the context of medium to large scale computer forensic data processing. This to provide the needed context for explaining why something like the MattockFS computer forensic file-system is a valuable and possibly essential component for a future asynchonour computer forensic framework that could supersede the orphaned and deprecated Open Computer Forensic Architecture (OCFA).

In this installment of my MattockFS series, we will discuss an other important aspect of automated computer forensics data processing: Integrity, Priviledge-separation and capabilities. As such, this post may be more of a informtion security post than a forensics post, but bear with me, it will become clear why and how these information security topics are esential to the forensics process later in this post.

Our main security concern in computer forensics when it comes to large scale data processing is the integrity of the forensic process. An important paradigm in the creation of high-integrity systems is what is called the Principle Of Least Authority. In short, this principle states that you only grant permissions to a unit of computing (computer, program, process, object, etc) that is needed for that unit to successfuly complete its task. Nothing more, as more would imply excess authority that can only lead to unneeded exposure to risk. Nothing less as less would stop the unit of computing from successfully completing its task. This principle, depending on things like the operating system or programming language used, can be applied to multiple levels of granularity. Least authority between computers in a network cooperating to complete a task. Different programs running on your PC under the same user id. Different processes or threaths making up a single running program, and even different objects and methods within a single running program. By applying POLA at the process level of granularity, we arive at a concept comonly refered to as privilege separation. But as stated this concept can be applied at each granularity level. The most important advantage of applying POLA on multiple levels of granularity lies in the fact that we minimize the reach of potential breaches. If a component is broken or even maliciously written, POLA will insure that the damage from a crash or breach will be relatively limited. When next to privilege separation we add the concept of revocation to the mix, we end up at a temporal variant of the Principle Of Least Authority. That is, we not only grant only the minimum amount of priviledges to units of compilation, we grant those priviledges for the minimum amount of time and revoke them as soon as the unit of computation is suposed to have completed its task.

There is one caveat in applying POLA to complex systems. For those familiar with information security theory, it is the problem that is easiest shown by the incompatibility between the integrity geared BIBA model of multi-level security versus the confidentiality geared Bell–LaPadula model of multi level security. While multi level security has gone out of fashion over the last decades, and discussion of these models falls outside of the scope of this post, the most important lesson from information security history is that with respect to POLA based design, there will alwys come a moment when you need to choose. Do we put confidentiality first and protect our secrets as most valuable assets, or do we put integrity first and protect powers as most important asset. Powers versus secrets. We pose that for the forensic process, powers, not secrets are our main concern as we are interested mostly in safeguarding the undisputable integrity of the computer forensic process as a whole.

One specifically prudent concern with respect to system and process intgrity is mutable state. In many modern computer based systems, the use of mutable state is done in a way that does not comply to POLA. Mutable state is often public or global and many entities, including entities without valid reasons to need to, can access and change the mutable state, and thereby influence the actions of other units of computation who's workings are defined by the shared mutable state. Systems using shared or global mutable state are notoriously hard to reason about, security wise, and they are notoriously hard to test as well. While there are a small examples of systems that implement POLA while using shared mutable state, in general most shared, and virtually all global mutible state will violate the principle of least authority, as it forms a giant hurdle for minimizing the size of the trusted code-base as required for truly building large scale high-integrity gered systems.

A very interesting and promising approach to POLA is the use of the capability model of security. It is basically a model very closely related to the Object Oriented Programming paradigm that is pervasively used in computer programming. Capabilities are authority only security tokens. The model lacks any concept of identity, and as far as multi granular system integrity is concerned this should be interpreted as dominantly a good thing. Capabilities combine designation with authorization. In fact, being able to designate (using a capability) is considered authorization all by itself. Capabilities also allow for the use of patterns of revocation that allow for temporal least authority.

The most primitive, but very commonly used type of capabilities are sparse capabilities. Spare capabilities basically are huge numbers or relatively long strings that are unguessable due to their sparse nature and designate something, either a unit of computation like an actor or some form of object. You could look at a sparse capability as a capability as data, or as a password without any coresponding user or identity. It is an identity free password to something specific and identity independants. In the past, sparse capabilities actually were sometimes refered to with the appropriate name password capabilities.

One very usefull anology for sparse capabilities can be found in the fairytale Rumpelstiltskin by the brothers Grim. In this story an evil imp provides the service of spinning straw to gold in exchange to the rights to the first-born of a young girl in dire straits. When the imp comes to claim his price, the first-born of the girl, that by then has become the queen, the queen gets a chance to keep her first born if she manages to guess the name of the imp. While the name, Rumpelstiltskin, for all intends and purposes is completely unguessable, one of the queens henchman overhears the imp sining his name in the forest, resulting in the queen being able to safe her first-born. As in this story the name is unguessable and both designates the imp and exeeds authority over him, Rumpelstiltskin can be seen as a very usefull analogy of a sparse capability.

Current day examples of sparse capabilities, include sparse caps used in shareable google docs links.

A more advanced form of capabilities, and one with superiour security properties ar object-capabilities. Object capabilities arn't just unguessable, they are unforgeable. To use the Rumpelstiltskin analogy again, the henchman would not have been able to just overhear an object capability version of the imp name. The only way for him to get the name from the imp would be the imp explicitly and intentionally giving it to him in an act of delegation.

Object capabilities can be easiers understand as object references in a memory safe programming language. A programming language though using a very strict subset of Object Oriented Programming. A subset that bans all forms of global mutable state.

As we discussed before, capabilities can be used in design patterns that allow for temporal POLA. The most elemental pattern for doing this is the so called caretaker pattern. This pattern allows for the temporary delegation of a priviledge by using a proxy and delegating a forwarding capability to the proxy to the entity we want to have the priviledge. Once we decide it is time to revoke the authority we granted, we ask the proxy to stop proxying and by that effectively revoke the authority we delegated earlier.

So now that we know about POLA and about capabilities, what tools does our MattockFS target platform Linux offer us in terms of implementing priviledge seperation using some form of capabilities. Well, first there are the basic access controlls on users or user id's. One important thing to grasp that a user id or uid does not need to refer to any actual user. They can designate specific sub systems, and it is possible to have a single software system that has its components running as different proceses running under different uid's. File-system access controls work on uid's and so called group id's and these can be used to share or not share specific data file with orher components, either with full access or with attenuated (read only) access.

A second facility available in Linux and the one most closely resembling object capabilities, are unix domain sockets. The interesting property of unix domain sockets is that they can be used as a way to delegate file and socket descriptors to an other process in the same way that object capabilities can be used to delegate object references to other objects by invoking a third object and passing the delegated object reference to the third object.

A third, and very important facility available in Linux is Mandatory Access Controll (MAC). The Linux kernel allows for the use of a MAC framework like SELinux or AppArmor to restrict access to resources in ways much stricter and far more granular than possible with the standard Discretionary Access Controlls (DAC) that we know since the early UNIX variants. These facilities allow us to design systems where even different processes, even those running under the same uid, have some relative privacy from other processes, and can have access to resources, files or other processes, unavailable to other processes running under that or other uid's.

The 4th and final usefull facility we have at our disposure, a facility that works especialy well in conunction with MAC, is the concept of user space file-systems. File systems in USEr (FUSE) space are basically user space processes that through the FUSE kernel module and library expose functionality as a file-system to other processes. The use of sparse capabilities in such a file-system, especialy if we can protect these sparse capabilities using MACX, can be a usefull way to augment the priviledge seperation offered by UID's, DAC and MAC.

Now let us get back to computer forensics. In 2006, Schatz and Clark intoduced the concept of the Sealed Digital Evidence Bag as a way to address integrity concerns with respect to the chain of custody. While their work focuded on data formats used and cryptographic integrity measures, the most important aspect of their publication is that it brought forensic process integrity concerns into focus. They made it blindingly clearforensic process concerns had been neglected for years by computer forensic industry and science, and as such raised the bar for large scale computer forensic data processing frameworks as wel. In later installments we will show how MattockFS tries to partially address these concerns.

So why would we care so much about security and integrity concerns in a forensic context?Well for starters, as Schatz and Clark showed, the integrity of the computer forensic process is of foremost importance. Especially provenance logs, as created by computer forensic frameworks should have a 100% integrity guarantee. Lastly, we truly should not underestimate the impact that a vulnerable and potentially maliciously exploitable module could have have on the integrity of processing outside of its own imediate task.

So how bad was all this before. To know that we need to first evaluate our shared mutable state in for example the Open Computer Forensics Architecture. Evaluating OCFA shows quite a bit shared mutable state that was accessible potentially to any module running. This was all common practice when OCFA was first built, and the threath landscape for forensics really wasn't half as bad as it is now. With anti forensics being a reality , the theats against the computer forensics process have become very real, and we truly can draw no other conclusion than that forensic frameworks need evidence sealing too.

So what is the whole fuss with integrity and bad modules? Wel,the list above should make that clear. A bad module can truly do a lot of damage in a non-POLA designed forensic framework such as OCFA.

So far for the base concepts of system & process integrity, POLA, capabilities and the need for evidence sealing and trusted provenance logs in the context of forensic frameworks. In the next installalment of this series we shall look at the FUSE based ancestors of MattockFS, MinorFS and CarvFS, and we will look at how these ancestors influenced the design of MattockFS.
I hope you enjoyed this post and hope you'll be back to read the other six upcoming instalments in this series.