Refine BlueChi's SELinux policy

[engelmi]

Describe the bug

In #850 we changed the bluechi-selinux policy from permissive to enforcing by default. This leads to various errors.

Known issues

Blocked systemd calls
When enforcing it prevents various essential calls for bluechi-agent (and probably bluechi-controller). For example starting a systemd service from the bluechi-agent is blocked:

type=USER_AVC msg=audit(1713363081.067:544): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { start } for auid=n/a uid=0 gid=0 path="/etc/systemd/system/simple.service" cmdline="" function="bus_unit_method_start_generic" scontext=system_u:system_r:bluechi_agent_t:s0 tcontext=unconfined_u:object_r:systemd_unit_file_t:s0 tclass=service permissive=0 exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'

These need to be added to bluechi.te. For reference, please see https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/modules/system/systemd.if

Files can't be read
BlueChi reads its configuration files from /etc. However, it is possible to pass in paths to configuration files via the -c CLI option. The policy only allows reads from /etc, though. Using chcon it is possible to allow reads for files on other locations.

This needs to be changed in:

• the documentation (readthedocs, man pages, etc.)
• the integration tests to apply chcon on a common directory, e.g. /tmp/bluechi and then chcon -R -t etc_t /tmp/bluechi/, where all configuration files passed in via -c are located

To Reproduce

Installing the latest BlueChi from snapshot repo on copr:
https://copr.fedorainfracloud.org/coprs/g/centos-automotive-sig/bluechi-snapshot

Starting bluechi-controller and bluechi-agent. Then starting a unit via bluechictl to trigger the denial for starting systemd units, for example.

Expected behavior

All functionalities from BlueChi (in expected uses) aren't denied by the SELinux policy.

[engelmi]

After #935 was merged, the integration tests were run in multihost mode (with SELinux enforced enabled) to find any potential SELinux issues:
https://artifacts.osci.redhat.com/testing-farm/e78806b7-b700-4286-b367-1093ffa62064/
A few tests failed - not due to issues with the SELinux policy, but because of other reasons (e.g. timeout). These test failures need to be investigated. However, the refined SELinux policy doesn't break any integration test, so we can close this issue.