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

Support for drbd-utils is added by the services/drbd module in the
SELinux refpolicy.

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
---
 package/drbd-utils/drbd-utils.mk | 1 +
 1 file changed, 1 insertion(+)

Hello Fabrice,

On Mon, 26 Jul 2021 10:21:31 +0200
Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote:

> Support for drbd-utils is added by the services/drbd module in the
> SELinux refpolicy.
> 
> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
> ---
>  package/drbd-utils/drbd-utils.mk | 1 +
>  1 file changed, 1 insertion(+)

I have a question: are you testing/using all these packages in an
SELinux context ?

Thomas

On Mon, 26 Jul 2021 10:21:31 +0200
Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote:

> Support for drbd-utils is added by the services/drbd module in the
> SELinux refpolicy.
> 
> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
> ---
>  package/drbd-utils/drbd-utils.mk | 1 +
>  1 file changed, 1 insertion(+)

Applied to master, thanks.

Thomas

Hello,

Le lun. 26 juil. 2021 à 14:15, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> a écrit :
>
> Hello Fabrice,
>
> On Mon, 26 Jul 2021 10:21:31 +0200
> Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote:
>
> > Support for drbd-utils is added by the services/drbd module in the
> > SELinux refpolicy.
> >
> > Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
> > ---
> >  package/drbd-utils/drbd-utils.mk | 1 +
> >  1 file changed, 1 insertion(+)
>
> I have a question: are you testing/using all these packages in an
> SELinux context ?
Nope, I'm not doing runtime tests for all these packages.
I'm just trying to extend SELinux support in buildroot by finding
matches between buildroot packages and refpolicy modules.
I'll fix failures raised by autobuilders (e.g.
https://github.com/SELinuxProject/refpolicy/pull/396).
For runtime failures, I'm hoping that users of those packages with
SELinux will report them to https://bugs.buildroot.org.
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Best regards,

Fabrice

Thomas, All,

+Matt, our resident SELinux expert ;-]

On 2021-07-26 14:15 +0200, Thomas Petazzoni spake thusly:
> On Mon, 26 Jul 2021 10:21:31 +0200
> Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote:
> 
> > Support for drbd-utils is added by the services/drbd module in the
> > SELinux refpolicy.
> > 
> > Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
> > ---
> >  package/drbd-utils/drbd-utils.mk | 1 +
> >  1 file changed, 1 insertion(+)
> 
> 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...

And as such, we can just batch-apply Fabrice's patches on the topic.

But I am not an expert in SELinux, so... Maybe an SELinux expert (Matt?)
could chime in and explain a bit?  Please? ;-)

Regards,
Yann E. MORIN.

All, 

> From: Yann E. MORIN <yann.morin.1998@free.fr>
> Sent: Wednesday, July 28, 2021 2:45 PM
> To: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>; Christophe Vu-Brugier <cvubrugier@fastmail.fm>; buildroot@buildroot.org <buildroot@buildroot.org>; Weber, Matthew L Collins <Matthew.Weber@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