|
|
| (9 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| == Fedora Modularity Introduction == | | == SELinux Modularity Landing Page == |
|
| |
|
| {{admon/note|Potentially outdated information|This introduction to Fedora Modularity is based on [https://langdon.fedorapeople.org/20160131-fosdem-linux-distros.html 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 [https://docs.pagure.org/modularity Fedora Modularity web site].}}
| | This is the main landing page for Fedora's SELinux Modularity effort, below you will find links to other SELinux Modularity pages which provide more information on specific areas. |
|
| |
|
| 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.
| | === Design and Prototype === |
|
| |
|
| 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.
| | * [[SELinuxModularityDesign]] - Introduction and High Level Design |
| | * [[SELinuxModularityPrototype]] - Prototype Module for [https://memcached.org memcached] |
|
| |
|
| 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.
| | === Guidance for Packagers === |
|
| |
|
| 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/IndependentPolicy]] - Guidance for Packaging SELinux Policy with RPM |
| | | * [[SELinuxModularityPackagingGuidance]] - Guidance for Including SELinux Policy RPMs in Fedora Modules |
| == 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.
| |
| | |
| == SELinux Modularity Impact ==
| |
| | |
| Decomposing the delivery of the SELinux policy has the potential to impact a large number of people and teams.
| |
| | |
| === Users ===
| |
| | |
| For those users who are satisfied with the default SELinux policy and configuration, there will likely be little impact; they may notice more SELinux activity during FM module management operations, but the impact to their business should be negligible.
| |
| | |
| Users who customize their SELinux configuration either through third-party policy modules or a custom semanage based configuration (e.g. SELinux booleans, custom file labels, etc.) may experience a noticeable impact depending on their exact configuration, but it should be easily resolved (e.g. missing booleans due to the fact that they are no longer relevant).
| |
| | |
| Regardless of a customer’s level of SELinux customization, they will see benefits from the SELinux Modularity effort. The SELinux policy quality is expected to improve as the policy moves closer to the application modules, the SELinux impact on system resources should be less as the system will only install/load SELinux policy for the software installed on the system, and SELinux troubleshooting/customization should be improved as a side effect of the improved developer/QE tools and documentation.
| |
| | |
| === Independent Software Vendors and Partners ===
| |
| | |
| ISVs that currently ship SELinux policy with their applications do so with little guidance from the distribution, and in many cases develop their own methods for managing their SELinux policy. The ISV experience should improve significantly with the SELinux Modularity effort as the entire system will be delivered as modules, with each module potentially delivering its own SELinux policy module. The same tools and guidance that we develop for our own use in developing, testing, and delivering SELinux policy in FM modules can be used by ISVs for their own products.
| |
| | |
| === Fedora Engineering and Quality Teams ===
| |
| | |
| The current SELinux policy packaging and distribution model makes it difficult for teams to keep SELinux policy synchronized with their applications. Moving the SELinux policy closer to the application should encourage and enable application developers, and packagers, to be more proactive when it comes to testing and verification of the associated SELinux policy. Engineering teams will no longer have to worry about hitting SELinux policy problems late in the release cycle; teams can continuously test each change against the SELinux policy that will ship with their updated application.
| |
| While it is difficult to predict all problem areas at the early design stages, it is reasonable to assume that there will be a transition period where problems are encountered. These issues will likely vary as each application/module, and each team, could present different challenges. However, due to the nature of the modularity effort, the transition can be done incrementally with a limited number of FM modules at any given time to limit the impact.
| |
| | |
| === Fedora SELinux Core Team ===
| |
| | |
| The SELinux core team will be impacted the most as the SELinux Modularity effort is a significant change from how SELinux policy is delivered today. The creation of new tools and documentation will also present a challenge, but the Fedora SELinux Independent Policy effort should help reduce the amount of new work required. While this project will be difficult, as we near the end of the effort there should be a number of advantages for the SELinux core team: higher policy quality and reduced support burden as other teams engage in proactive testing, easier long term policy maintenance as policy can be branched and managed per-application/module, and higher ISV/third-party involvement as policy development/packaging becomes easier.
| |
| | |
| === Upstream SELinux Community ===
| |
| | |
| As the Fedora Modularity effort is limited to Fedora and not the broader Linux community, many of the SELinux Modularity benefits will not be visible outside of Fedora based distributions. However, as Fedora is often considered the “Gold Standard” for SELinux in general purpose Linux distributions, a better SELinux experience on Fedora reflects well on the SELinux project as a whole.
| |
| | |
| Regardless of how Fedora deploys SELinux policy, the work on improving the individual SELinux policy modules, userspace tools, and kernel support will still remain useful upstream and our commitment to a strong upstream SELinux community will remain unchanged.
| |
