[Buildroot] [PATCH 1/1] package/drbd-utils: add SELinux module

[Weber, Matthew L Collins]

All, 

> From: Yann E. MORIN <yann.morin.1998 at free.fr>
> Sent: Wednesday, July 28, 2021 2:45 PM
> To: Thomas Petazzoni <thomas.petazzoni at bootlin.com>
> Cc: Fabrice Fontaine <fontaine.fabrice at gmail.com>; Christophe Vu-Brugier <cvubrugier at fastmail.fm>; buildroot at buildroot.org <buildroot at buildroot.org>; Weber, Matthew L Collins <Matthew.Weber at collins.com>
> Subject: Re: [Buildroot] [PATCH 1/1] package/drbd-utils: add SELinux module 
>  

[snip]

> > 
> > I have a question: are you testing/using all these packages in an
> > SELinux context ?
> 
> That is eaxctly what I was pointing out with our addition of the
> handling of the SELinux refpolicy in our package infrastructure.
> 
> On one side, either we consider that the refpolicy is authoritative and
> represents the state of the art of the SELinux policy for packages, in
> which case we can "blindly" add SELinux metadata to our packages, or...
> 
> on the other side, I fail to see how a generic policy can be applied to
> a specialised product, where constraints vary wildly from the "server
> world" where refpolicy and SELinux originate from, and even vary wildly
> between different specialised products, in which case basing out SELinux
> handling in our infra on refpolicy does not make much sense.
> 
> So, it is my understanding that we decided that the refpolicy was to be
> seen as the gold-standard of a policy, from which customised, local
> policies would be derived, and as such we could safely use the refpolicy
> modules on the assumption that a local policy would also have them...
> 

Correct, "refpolicy" can be used as the "common" gold-standard collection of what use to be considered "contrib" policy.  Refpolicy previously was the main repository of distro customizations and common items.  Then a second "refpolicy-contrib" repository contained the common package policies (ntp, util-linux, etc).  Today the repositories have been consolidated and the focus is on the common parts, not customizations specific to a product/distro.  Most distros today have a fork/patchset that contains the customizations (Fedora, Redhat, Yocto, probably others).  This was the direction Antoine Tenart headed with the Buildroot per package support.  The goal was to dynamically build a policy based on enabled packages and then allow a user to supplement customizations that make it completely work for their target.  Most Buildroot build failures we'll find in the refpolicy modules will be related to dependencies that larger distros don't encounter with filesystems including fully-featured packages.

The Buildroot SELinux refpolicy support breaks down into the following.
- Builds a smaller refpolicy, not selecting all the modules by default.  Disables all non-base modules by default and only re-enables core ones that would be needed for all builds.
- Allows packages to select extra SELinux modules within the refpolicy to be built in the policy. This allows applications and libraries already supported in the refpolicy to be supported when selected in the Buildroot configuration. This is done thanks to a per-package variable,  <pkg>_SELINUX_MODULES. This better supports Systemd.
- Allows users to provide their own SELinux modules, and to select extra dependencies that would be available in the upstream refpolicy.  This is done thanks to two Kconfig options, one pointing to a  directory containing SELinux modules sources and one listing extra modules to enable in the refpolicy.
- Allows users to provide a fully custom refpolicy, overriding all the logic described above. This is done by providing a Git repository in  Kconfig pointing to a fork of the refpolicy, provided by the user.
- Allows packages to provide their own SELinux modules, by having an 'selinux' subfolder (package/<name>/selinux/). Those SELinux modules are copied to be part of the generated policy when their Buildroot packages are selected.
- Handles the creation of filesystems that have extended attributes setup to match the refpolicy's filecontext definition at build time.  (No runtime R/W activity on first boot with restorecon)
- Provides runtime tests for a base systemd target with ext2/squashfs (extended attribute enabled filesystems) .  Good examples if someone is looking at how to build a basic SELinux enabled system.  This route was suggested vs adding a "qemu board defconfig example" for upkeep reasons.

Regards,
Matt