add flag for building bluechi-selinux with any port

[engelmi]

Fixes: #836

Previously, the SELinux policy for BlueChi only contained one type for the port and was used only by the bluechi-agent. This adds a new port type and and uses one for the bind of bluechi-controller and another for the connect of bluechi-agent.
Based on this, tunable policies are added to turn on/off the option to use any port for both components.
In addition, it removes the implicit permissive policy so that violations to the policies are enforced by default (can be set permissive later on by the user again).

This PR also updates the RPM spec of BlueChi so that it does not require the semange tool and thus is not pulling in python as a dependency anymore. It adds also another option to the build to enable any port policy for bluechi-controller an bluechi-agent.

It also adds documentation about BueChi's SELinux policy, restructuring the order of the table of contents and introducing the section Security which contains the selinux policy and mTLS double proxy approach.

NOTE:

The changes for the documentation look like this:

[coveralls]

coverage: 84.169% (+0.02%) from 84.151%
when pulling 382e6d5 on engelmi:loosen-selinux-port-policy
into b3c1a68 on eclipse-bluechi:main.

[mwperina]

LGTM

[engelmi]

@rhatdan PTAL

[alexlarsson]

This doesn't seem right to me. The selinux module still references the bluechi_port_t type, and if the semanage call was never called, then this will not be set to anything. I don't know selinux that well, so I'm not sure if that will lead to some error, or if the port is assumed to be zero or something.

Either way, unless I'm totally off, there is no way this can correctly work.

I think we need something like systemd_socket_proxyd_bind_any in
https://github.com/fedora-selinux/selinux-policy/blob/85bbb6d1bc69e84ea2440cff647e426b74f1b40a/policy/modules/system/systemd.te

This has both a port type which can be assigned with semanage (systemd_socket_proxyd_port_t) and boolean options ( systemd_socket_proxyd_bind_any and systemd_socket_proxyd_connect_any) which instead makes the rules work on any port. I think the right approach is to use something like that with the boolean options set to true by default, and then have the optional rpm post-scripts set both the port and the boolean.

[alexlarsson]

This doesn't seem right to me. The selinux module still references the bluechi_port_t type, and if the semanage call was never called, then this will not be set to anything. I don't know selinux that well, so I'm not sure if that will lead to some error, or if the port is assumed to be zero or something.

I guess what happen is that no port will ever get that label assigned, so no port will ever pass the rules.

[engelmi]

This doesn't seem right to me. The selinux module still references the bluechi_port_t type, and if the semanage call was never called, then this will not be set to anything. I don't know selinux that well, so I'm not sure if that will lead to some error, or if the port is assumed to be zero or something.

I guess what happen is that no port will ever get that label assigned, so no port will ever pass the rules.

The port would need to be assigned to that label with semanage later on. Till then, basically no port is assigned and an AVC is always created - but the name bind itself is not blocked.

I'll have a look at the systemd_socket_proxyd_bind_any.

[alexlarsson]

The port would need to be assigned to that label with semanage later on. Till then, basically no port is assigned and an AVC is always created - but the name bind itself is not blocked.

I feel this being permissive like this makes the whole selinux module not very useful though.

[engelmi]

I feel this being permissive like this makes the whole selinux module not very useful though.

I agree. In addition, I think it can't be changed from permissive to enforcing later on (since it wasn't added by semanage according to [the man page]).

I did a bunch of changes, incl. the tunable policy for the ports based on the systemd example.
Could you have another look? @alexlarsson

[mwperina]

Just noticed that we forgot to remove dependency on policycoreutils-python-utils

[alexlarsson]

Other than the default change pointed out by dan i think this looks good.

[engelmi]

Thank you for your help! @alexlarsson @rhatdan @mwperina
Merging.