MinorFs is a set of cooperating user-space filesystems that work with AppArmor to provide a flexible form of discretionary access control that operates at the process level. This type of process-level authority restriction is roughly equivalent to that seen in object-oriented programming, providing least-authority restrictions by parameter passing without requiring the administrative overhead of policy controls seen in mechanisms like SELinux. Least authority also is known as least privilege or POLA (Principle Of Least Authority).
In Linux, access to filesystem data is managed by two different access-control mechanisms. First, there is the basic and familiar UNIX discretionary access-control system. The DoD document “Trusted Computer System Evaluation Criteria” (aka the “Orange Book”) defines discretionary access control as “a means of restricting access to objects based on the identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject (unless restrained by mandatory access control)”.
Linux also provides access control through the Linux Security Module (LSM) interface. LSM provides hooks for additional access-control mechanisms, such as mandatory access controls, while leaving the base UNIX discretionary access-control mechanisms untouched. The Orange Book defines mandatory access controls as “a means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e., clearance) of subjects to access information of such sensitivity”.
These two constructs are combined restrictively, which means if either one denies access, access is denied. Well known users of the LSM interface are Security-Enhanced Linux (SELinux), used in Debian and Red Hat, and AppArmor used in SUSE and Ubuntu.
Although the UNIX discretionary access control for filesystem access has remained at the same (simple user level) granularity for decades, mandatory access control has become more fine-grained (process level). This granularity, however, comes at relatively large administrative costs. SELinux, for example, is known among many administrators for the large amount of overhead that comes with maintaining profiles.
When designing and writing object-oriented (OO) programs, avoiding global variables, using data hiding, passing references between objects and using established design patterns (like proxies and factories) are concepts we are used to and comfortable with, and most of us have come to appreciate the many advantages these techniques offer. What many of us fail to realize when working with these concepts, however, is the fact that part of what we are doing can be considered access control.
If we look at the OO paradigms from an access-control viewpoint, it is easy to see that the model used by OO programs is both discretionary and suitable for the highest granularity. Therefore, you could say that OO programs internally use an extremely fine-grained form of discretionary access control. We must note, however, that this form of access control is actually older than the whole concept of object-oriented programming. The access-control mechanism used implicitly by OO programmers is, in fact, to a large extent equivalent to the access-control mechanisms in use in so-called capability-based systems. Capabilities, often called keys, are an unforgeable authority token that can be passed between programs. In capability-based systems, having a capability gives you the right to use the referenced object within the boundaries specified by the rights associated with the capability. With capabilities, there is no need to check other access-control mechanisms (for example, ACLs); the capability itself contains all the necessary information.
So, why not use this same form of discretionary access control at a slightly coarser level of granularity for access to files and directories by processes? MinorFs aims to do just that, with a lot of help from AppArmor.
First, let's look at how classes, objects and member data, as used in OO design and programming, compare to programs, processes and filesystem data. There are clear indications that we could be dealing with the same set of abstractions at a different granularity level.
You could look at a program the same way you look at a class. A process is an instance of a program (the disk image), the same way that an object is an instance of a class. Most objects have state, in the same way that most processes have state. You could say the same abstractions are there both at the object level of granularity and at the process level of granularity.
Next, we need to map the persistent on-disk directory structures to the same OO model that we just used to model programs and processes. A couple hurdles need to be overcome to accomplish this. First, there is process persistence, which is to say that processes are “not” persistent, so how do they fit the model?
Second, there is pass by reference. If an object wants to share part of its private state with another object that it knows, the object can pass either a copy of or a reference to a part of its internal state. Processes, however, to a great extent are confined to passing copies, not references.
|When BirdCam Goes Mainstream||Oct 27, 2016|
|Nightfall on Linux||Oct 26, 2016|
|Daily Giveaway - Fun Prizes from Red Hat!||Oct 25, 2016|
|Installing and Running a Headless Virtualization Server||Oct 25, 2016|
|Ubuntu MATE, Not Just a Whim||Oct 21, 2016|
|Non-Linux FOSS: Screenshotting for Fun and Profit!||Oct 20, 2016|
- Nightfall on Linux
- Installing and Running a Headless Virtualization Server
- Secure Desktops with Qubes: Compartmentalization
- Daily Giveaway - Fun Prizes from Red Hat!
- When BirdCam Goes Mainstream
- Ubuntu MATE, Not Just a Whim
- Nasdaq Selects Drupal 8
- Build Your Own Raspberry Pi Camera
- Non-Linux FOSS: Screenshotting for Fun and Profit!
- Canonical Ltd.'s Ubuntu Core