MinorFs

Although delegation of temporary subgraphs to processes is relatively simple, the concept of the same process being an incarnation of some pseudo-persistent process needs a bit more thought.

MinorViewFs looks at pseudo-persistent processes on a so-called n-th claim basis. What it basically boils down to is that if a program is instantiated while two earlier instantiated versions of the program already are running, the new process will claim the third slot. If the system is rebooted, you also will need to restart the first and second instantiation of the program.

Although appropriate for dæmon-like programs, this, indeed, may be inconvenient for programs like editors and other user-driven programs. To work around these problems, and also to work around the problem posed by scripts and Java programs all being instances of the same program, MinorViewFs uses some simple tricks to determine program, or more specifically, program-invocation-based identity.

So how does MinorViewFs determine a program-invocation identity? First, there is the process parent chain. The process parent chain, including both programs and libraries loaded by those programs, contributes to a unique identity for the invocation. If the parent chain is insufficient as an invocation identity, the system administrator could add a config file under /etc/minorfs/.

Here is an example of a config file for the E language interpreter:

<codefile path="/usr/local/e/e.jar" cmdline="true" slots="256">
    <env>DISPLAY</env>
</codefile>

The example config adds the command line to the identifying properties of the program invocation. So, using optional config files, MinorViewFs is able to create and re-create a uniquely identifying set of data that allows it to re-delegate a subgraph to a new incarnation of the same program.

The E language named above takes this concept one step further; it allows large subsystems within an E program to be taken together and be serialized and synchronized to disk storage automatically. What's more, the E language is an object-capability language; thus, combining AppArmor and MinorFs with the E language allows you to combine both least authority and private storage all the way down to the object level of granularity. Although E is a bit of an esoteric language, it is a mature and complete language that is worth considering when doing high-integrity projects.

When a process is started and accesses the /mnt/minorfs/priv/home symbolic link, this symbolic link will point to the same MinorCapFs subgraph as the previous time the program was invoked into the same slot.

Next to being useful to new programs designed with privilege separation and least authority in mind, MinorViewFs also can be used with legacy programs like the SSH client. This does, however, involve the usage of the admin tool 2rulethemall that helps the user bypass the basic process-based access-control mechanism with a per-user password. You can put your unprotected SSH private key in the SSH client's private persistent storage space. Again, no program not run by root other than MinorViewFs, SSH or 2rulethemall would be able to access the private key.

MinorFs brings an extreme (capability-based) form of discretionary access control to your AppArmorized Linux system. It uses a form of access control that embraces delegation as a beneficial thing for security. Although MinorFs still is being developed, and is incomplete, it already should provide a useful and intuitive way to create privilege-separated programs that use filesystem access. It provides a way to protect serialized data stored on disk for persistent processes, and a way to protect process private data. And, it's an alternative to the troublesome usage of temp directories.

Upcoming versions of MinorFs will include a third filesystem, MinorCtkrFs that will implement attenuation in a generic way based on the so-called Caretaker pattern. This MinorCtkrFs should add different kinds of read-only capabilities to files and directories, as well as revocable read/write and read-only capabilities.