The MinorFs user-space filesystems works with AppArmor to provide a flexible form of discretionary access control.
Pseudo-Persistent Processes According to MinorViewFs

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">

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.

Rob Meijer is a computer forensic and security software development professional from the Netherlands. He started his career as a UNIX system administrator, switching one decade ago to software development. In his spare time, he is working on several least-authority-related open-source projects, including MinorFs.


One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix