SELinux policy for QM + BlueChi

[engelmi]

In the context of eclipse-bluechi/bluechi#997, the support for Unix Domain Sockets in BlueChi has been enhanced. This also included the respective SELinux policy (see In eclipse-bluechi/bluechi#1015). On a setup QM + BlueChi it makes sense to mount the UDS of BlueChi into QM and have the bluechi-agent inside connect to it. This, however, is currently rejected due to missing SELinux policy rules.
In this thread eclipse-bluechi/bluechi#1015 (comment) some approaches were briefly discussed on how to solve this. Since BlueChi might be used inside QM and BlueChi doesn't know anything about QM, I think it would make sense extend QMs SELinux policy.

[Yarboa]

UDS are allowed on specific directory
We can verify it again
Please take a look here #469
Domain socket directory should be here
/run/ipc-demo/ipc.socket
Already tried it in the past
/var/run/ipc/controller.sock

Please search for that policy
...File context for ipc programs
/usr/bin/ipc-demo gen_context(system_u:object_r:ipc_exec_t,s0)
/var/run/ipc-demo(/.)? gen_context(system_u:object_r:ipc_var_run_t,s0)
/var/run/ipc(/.)? gen_context(system_u:object_r:ipc_var_run_t,s0)

@engelmi I think Bluechi could use the /var/run/ipc
Please refer this
https://docs.podman.io/en/v5.1.1/markdown/podman-run.1.html

[engelmi]

@Yarboa The SELinux policy for BlueChi was on permissive by default till v0.9.0 (changed in this PR), so even if some actions were not allowed, nothing was blocked. For v0.9.0+ this is no longer the case and qm_t requires allow rules (e.g. via stream_connect_pattern as mentioned in eclipse-bluechi/bluechi#1015 (comment)) for bluechi_var_run_t.

Having a basic setup with QM and BlueChi, I can confirm that it currently gets blocked:

time->Thu Jan  2 16:43:47 2025
type=PROCTITLE msg=audit(1735836227.764:1322): proctitle="/usr/libexec/bluechi-agent"
type=SYSCALL msg=audit(1735836227.764:1322): arch=c000003e syscall=42 success=no exit=-13 a0=a a1=560e4a3f5570 a2=24 a3=7ffd52c50564 items=0 ppid=7792 pid=7951 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="bluechi-agent" exe="/usr/libexec/bluechi-agent" subj=system_u:system_r:qm_t:s0 key=(null)
type=AVC msg=audit(1735836227.764:1322): avc:  denied  { write } for  pid=7951 comm="bluechi-agent" name="bluechi.sock" dev="tmpfs" ino=1697 scontext=system_u:system_r:qm_t:s0 tcontext=system_u:object_r:bluechi_var_run_t:s0 tclass=sock_file permissive=0

Edit:
I see there is already the function container_ipc_stream_connect provided by QM, which should do what is needed. Still would make sense to me to have the QM (sub-)policy take care of this so we don't introduce a dependency cycle.

[alexlarsson]

This is a tricky area. Bluechi is useful without QM, so we can't require the QM selinux policy to use it.
On the other hand, the QM package is not inherently tied to bluechi, and can be used without it, so referencing it there is also somewhat non-ideal.

However, having a third thing that just combines QM with Bluechi is just a total pain in the ass, so I think the right place to put this in is the qm selinux policy. We just have to make sure to wrap that part of the policy in optional_policy() so that it works even when bluechi is not installed. See: https://selinuxproject.org/page/NB_RefPolicy#optional_policy_Macro

@Yarboa We don't want to use the ipc contexts for bluechi. That would significantly lower the security, as any qm process that has access to ipc_t can then pretend to be a bluechi agent. Basically, ipc_t is for generic end users to use, and we should not use it for our base OS policy.