Fedora Modularity Introduction
This introduction to the Fedora Modularity plan is based on Langdon White’s Flock 2016 presentation, and since the design/plan is still in the early stages it is reasonable to expect changes, especially involving the smaller details. This is intended to be a brief, high level introduction to the Modularity effort, not a comprehensive description. Current, and more detailed, information can be found on the Fedora Modularity web site.
Traditional Fedora systems have relied on individual application packages/RPMs and package groups for the installation and management of software on the system. While this model is well understood by both developers and administrators, it doesn’t fit well with many of Fedora’s long term goals, or the technical and usability goals of a solution based OS distribution. The proposed Modularity design intends to correct this by moving the focus from individual application packages to solution based modules which provide integrated, configured, and tested bundles (modules) that can be quickly installed on a system.
Initially these modules will rely on RPM packages to deliver the included packages, but the design of the module platform is such that modules can be composed from any number of application package formats, including containers. Modules can be used to deliver almost any data to the system, including a nested stack of other modules.
Another goal of the Modularity effort is to decompose the monolithic Fedora distribution into a collection of modules, each with different support lifetimes. For example, the core “base-runtime” module, with a relatively long support lifetime, will provide a very stable set of applications, libraries, and interfaces. Higher level solution specific modules can have varying levels of support lifetimes; longer lifecycles offer better support and stability, while shorter lifecycles trade stability for the ability to better track upstream development.
The Modularity effort presents a number of opportunities for us to rethink how we deliver SELinux policy in Fedora, but with those opportunities comes challenges. The shift towards a modular, solution focused OS offers us the chance to provide a default SELinux policy that is better matched with usage requirements while at the same time reducing the runtime policy size (better performance, smaller memory footprint, etc.). However, modularizing our SELinux policy delivery introduces new concerns around dependency management, object labeling, and support that will need to be addressed.
SELinux Modularity Introduction
The current Fedora approach to delivering SELinux policy is to deliver the entire distribution provided policy in a single RPM package. This approach worked well when SELinux was first introduced, undergoing rapid and substantial changes to the policy, and it fit within the existing Fedora RPM model of installing and managing the system. However, as the legacy Fedora model starts to shift towards a less monolithic approach, both with containers and the Fedora Modularity effort, so should the SELinux policy to better adapt to how systems are composed and managed; we are calling this effort “SELinux Modularity”.
The idea behind SELinux Modularity (SM) is to decompose our SELinux policy package such that the SELinux policy associated with a Fedora Modularity (FM) module is shipped as part of the FM module. While this represents a significant shift in how we deploy the core SELinux policy, it isn’t vastly different from what partners, ISVs, and other third-party SELinux policy providers do today. The current third-party application/policy model shares a number key points with the core ideas behind the SELinux Modularity design.
Match SELinux Policy with Application Usage
Deploying SELinux policy with the application as part of a single FM module allows the SELinux policy development to focus on a specific set of use cases instead of every single possible scenario as is required with the current monolithic approach. Module, and profile, specific customizations could include changes to the the filesystem labels, network labels, SELinux user/role assignments, SELinux boolean settings, and even updated/overloaded SELinux policy (higher priority SELinux module overriding a lower priority SELinux module).
Synchronize SELinux Policy and Application Release
SELinux policy is tightly bound to the application, due both to changes in the design/implementation as well as to the intended usage. Deploying SELinux policy with the application allows the policy to be developed and tested alongside the application, instead of the current disjointed, and reactive, SELinux policy development process.
Distribute SELinux Policy Development and Support Burden
In order to continue to advance SELinux policy development it is important to find ways to distribute the development and support of application policies. Unfortunately, the current SELinux development and deployment models make this difficult. The recent improvements to the SELinux policy module store (priorities) should help remove some of the technical barriers around managing third-party SELinux policies, and I expect that the SELinux Modularity effort will continue to build upon these improvements through better tooling, documentation, and a well defined deployment mechanism for SELinux policies.