Configuring the Development Environment
The goal of this section is to help people setup their system to build SELinux policy and Fedora Modules.
Building Fedora Modules
Module build is facilitated by the fm-oschestrator (module-build-service package), which is controlled by a set of fedpkg commands.
# dnf install fedpkg module-build-service
Building SELinux Policy modules and RPMs
SELinux policy module build is a multi step process covered by a Makefile provided by selinux-policy-devel package together with all the necessary tools. Since the finished module will be packaged in an rpm, we also need rpm-build package.
The following is only necessary for local testing of the SELinux policy package since the build is otherwise done by the module-build-service.
# dnf install selinux-policy-devel rpm-build
By default dnf does not have access to FM repositories even though it is able to work with modules. Install "fedora-repos-modular-<fedora version>" package to gain acces to "Fedora Modular" modules.
# dnf install fedora-repos-modular-28
Packaging SELinux Policy
From modularity point of view the SELinux policy needs to be available in the form of RPM package. It's up to the maintainer to choose whether the policy package is standalone or a sub-package of the corresponding software. The former is covered by the Independent Policy Project (IPP) wiki. The latter only differs in the RPM spec file and can be seen in the memcached package.
SELinux Policy Priorities
Priority 200 should be used for all custom policy modules falling under IPP project regardless of the means of distribution (FM, RPM, ...). This value is set in the %selinux_modules_install macro and should not be overridden by package maintainers.
SELinux Base Policies
There are 3 different base policies available on Fedora also referred to as policy types. Targeted is the most commonly used and is the default policy type. MLS is significantly more strict and utilizes all the capabilities of Multi Level Security to comply with high security standards. Minimum is a policy type used on small devices (less overhead) or as a base for highly customized security policies.
It is usually best to ship single custom policy module for all supported policy types, using conditional statements for rules specific to single policy type. For more complex policies it is also possible to ship separate policy modules. In that case all the steps described in the IPP documentation would be duplicated, making use of the "policy type" parameter when available.
Example SELinux Policy RPM specfile
See memcached-selinux spec file for example of standalone SELinux policy RPM spec file, or memcached spec file for example of SELinux policy subpackage.
Bundling SELinux Policy RPMs in Fedora Modules
Including the policy RPM in a Fedora module is as simple as specifying the RPM source repository name and branch in the components section of the modulemd file.
components: rpms: foo: rationale: Primary component of this module. ref: master foo-selinux: rationale: Provides SELinux policy for foo ref: master
In case the SELinux policy RPM is a sub-package, this step is already done (the Module Build Service (MBS) will build the specified component including all sub-packages automatically.)
Adding the SELinux Policy to the Module Install Profiles
For user convenience it is also recommended to include the policy package in one or more install profiles, which serve as suggestions for which packages should be installed in listed use cases.
It is recommended to have the policy RPM as part of the default install profile. Depending on the primary component it may be useful to include an install profile without the policy module to be used for example inside a container. The policy does not take effect inside a container and would only bring in unnecessary dependencies.
profiles: default: rpms: - foo - foo-selinux container: rpms: - foo
Complete example modulemd file which includes SELinux policy module RPM (sub-package) can be seen in the memcached module repository.