Bug 1848683

(In reply to Mauricio Teixeira from comment #0)
> 
> 3. What is the nature and description of the request?
> 
> Use case:
> 
> It would be desirable to be able to pass custom .te, .fc and .if files,
> which would then be compiled on demand in the target host, and installed as
> modules.


Is there a specific reason why to build SELinux modules on nodes? It would mean to install selinux-policy-devel, policycoreutils-devel, checkpolicy, m4, ... on every node a user wants to deploy a custom policy.

 
> Optionally, the role should also be able to accept a pre-compiled .pp file,
> and install it.

Or .cil files.

 
> 5. How would the customer like to achieve this? (List the functional
> requirements here)
> 
> Introduce tasks to install .te, .fc and .if files, either by themselves or
> as a group, then compile them into a custom module, and enable the custom
> module on the target system.


I'd say this should be core of the functionality - upload SELinux modules, either as .pp or .cil files, and install them with requested priority.

This basic functionality could be covered by a configuration like this:

    selinux_install_modules:
      - { path: 'mylocalpolicy1.pp', priority: 400 }
      - { path: 'mylocalpolicy2.cil', priority: 300 }

Then users would probably like to manage SELinux modules as well. e.g.

    selinux_modules:
      - { module: 'mylocalpolicy1', priority: 400, state: 'disabled' }
      - { module: 'mylocalpolicy2', priority: 300, state: 'absent' }

 
> A second run should be able to compare the checksum of the generated .pp
> file, with the currently running policy, and only reload if they differ.
> (requires bz#1731501).

It probably doesn't require bz#1731501, you can use 'semodule -E' to export used module and compare a new one with the exported one.

Is it possible to "cross compile" a .pp file on e.g. RHEL7 and apply that file to RHEL8 and RHEL9 and Fedora and .....?  If not, then we have no choice but to install selinux-policy-devel, policycoreutils-devel, checkpolicy, m4, ... on every node a user wants to deploy a custom policy.  I don't think that will be a big problem - sure, for managing a 500 node cluster, and having to install all of those packages on every node will take a while, but is it a significant fraction of the time it takes to actually apply the policy (not to mention all of the other Ansible tasks for other roles outside of selinux . . .)

It's possible to install one .pp or .cil file on all mentioned systems. You need to use the lowest supported policy modb version, i.e. build it on the lowest SELinux userspace version used on your nodes, and avoid classes and permissions which are unknown for any node. It should not be that hard if there's no interface used in .te file. Interfaces could bring permissions like 'compromise_kernel' which exists only on RHEL7 and such module could not be installed on Fedora.

Or a policy module could be built for different targets using chroots, containers, ... on the host and then just deployed on nodes as pre-built binary .pp, or pre-generated .cil file, and it would not be necessary to install development tools on nodes/servers.

(In reply to Petr Lautrbach from comment #6)
> It's possible to install one .pp or .cil file on all mentioned systems. You
> need to use the lowest supported policy modb version, i.e. build it on the
> lowest SELinux userspace version used on your nodes, and avoid classes and
> permissions which are unknown for any node. It should not be that hard if
> there's no interface used in .te file. Interfaces could bring permissions
> like 'compromise_kernel' which exists only on RHEL7 and such module could
> not be installed on Fedora.

This sounds fragile, and sounds like it would involve a lot of conditional logic in Ansible to handle different cases (but I would think users would have to specify different .te files for different platforms/versions anyway if they wanted to take advantage of platform specific SELinux features - i.e. a myapp.te.rhel7 *and* a myapp.te.rhel8 - which we already mostly handle in the system roles).

> 
> Or a policy module could be built for different targets using chroots,
> containers, ... on the host and then just deployed on nodes as pre-built
> binary .pp, or pre-generated .cil file, and it would not be necessary to
> install development tools on nodes/servers.

Creating the necessary Ansible code to set up a .pp builder "farm" based on the minimal necessary combinations of platform/version; doing the builds; deploying the files, etc. is probably a man month i.e. quite complex to do in Ansible, and would involve considerations above and beyond the normal Ansible such as availability of chroots on the controller machine, availability of package repos for those chroots on the controller machine, availability of a container runtime, repos, availability of network/disk/ram/cpu resources on the builder machines, etc. etc.

What do we recommend (i.e. in official Red Hat documentation) for customers to do today, without Ansible, in order to manage SELinux policy across a large number of machines running heterogeneous platforms and versions?

Note that the simplest way to do this in Ansible will be to install the necessary selinux packages on the remote systems and compile the module there.  Coding that role can be done in a day, give or take.  I understand that it is inefficient in terms of the duplication of resources (network, cpu, disk, memory) used to install the same packages across multiple systems and compile the same .pp file across multiple systems, but this may be a case where the advantages of code simplicity outweighs the disadvantages.

As the original requester of this RFE, me and my team would prefer that the role accepts plain-text .te files, and compile them on-the-fly, because that would allow us to properly track the rules/modules changes in a version control system (Git).

An acceptable compromise would be providing two options: one for landing plain .te files (and building them), another for directly landing binary .pp files. This way the role user can choose whether they want to build the module themselves or not.

Another possible solution would be to have tasks that build the .pp files locally, before uploading them. The problem with that is any possibility of the user running SELinux modules which are incompatible with the destination host. One of those cases would be me running Fedora on my laptop, trying to run the role to install the module on a RHEL server. Or even me running RHEL8 attempting to install a module on RHEL7.

The case for having different .te or .pp files based on RHEL versions can be easily fixed appending the "ansible_distribution_major_version" fact against the file name or a directory.

Red Hat IT has been distributing .pp files for years with Puppet, just cased for the correct OS version. While not ideal, it works and has not been a huge management burden. Seems like something for a MVP, then add support for building from the .te files down the road. There is value in giving sysadmins the choice of building an OS-specific .pp or ensuring each node has the necessary devel packages installed on doing a .te build on the target system.

How do you deploy binary rpms? Do you upload src.rpm on a node, and build it there before you install it?


> Creating the necessary Ansible code to set up a .pp builder "farm" based on
> the minimal necessary combinations of platform/version; doing the builds;
> deploying the files, etc. is probably a man month i.e. quite complex to do
> in Ansible, and would involve considerations above and beyond the normal
> Ansible such as availability of chroots on the controller machine,
> availability of package repos for those chroots on the controller machine,
> availability of a container runtime, repos, availability of
> network/disk/ram/cpu resources on the builder machines, etc. etc.

Does the "farm" need to be written in Ansible code? Could you a simple shell script in CI which would generate necessary binary components on every commit/release?


> What do we recommend (i.e. in official Red Hat documentation) for customers
> to do today, without Ansible, in order to manage SELinux policy across a
> large number of machines running heterogeneous platforms and versions?


I'm not sure about the past, but it's suggested to ship policy modification using <component>-selinux rpm package -  https://fedoraproject.org/wiki/SELinux/IndependentPolicy
so you don't even need this role as the policy is installed and managed by rpm

(In reply to Petr Lautrbach from comment #10)
> How do you deploy binary rpms? Do you upload src.rpm on a node, and build it
> there before you install it?

See below.

> 
> 
> > Creating the necessary Ansible code to set up a .pp builder "farm" based on
> > the minimal necessary combinations of platform/version; doing the builds;
> > deploying the files, etc. is probably a man month i.e. quite complex to do
> > in Ansible, and would involve considerations above and beyond the normal
> > Ansible such as availability of chroots on the controller machine,
> > availability of package repos for those chroots on the controller machine,
> > availability of a container runtime, repos, availability of
> > network/disk/ram/cpu resources on the builder machines, etc. etc.
> 
> Does the "farm" need to be written in Ansible code? Could you a simple shell
> script in CI which would generate necessary binary components on every
> commit/release?

The "Ansible code" can be whatever you want it to be e.g. a "simple" shell script - Ansible will be just a wrapper around whatever is the ultimate implemenatation.

> 
> 
> > What do we recommend (i.e. in official Red Hat documentation) for customers
> > to do today, without Ansible, in order to manage SELinux policy across a
> > large number of machines running heterogeneous platforms and versions?
> 
> 
> I'm not sure about the past, but it's suggested to ship policy modification
> using <component>-selinux rpm package - 
> https://fedoraproject.org/wiki/SELinux/IndependentPolicy
> so you don't even need this role as the policy is installed and managed by
> rpm

I would think we wouldn't want to make customers who just want to tweak or provide custom SELinux policy to have to get into RPM management, but perhaps that is the price of admission into SELinux policy management?

At any rate, we don't have to solve this today, for this BZ, because the customer requesting the feature has said that, while not ideal, they are already used to building .pp files and distributing them.  https://bugzilla.redhat.com/show_bug.cgi?id=1848683#c9

https://github.com/linux-system-roles/selinux/pull/56

testing coverage is tests/tests_selinux_modules.yml

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (rhel-system-roles bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:4159