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.

[Yarboa]

@engelmi
see the merger errors
https://download.copr.fedorainfracloud.org/results/rhcontainerbot/podman-next/centos-stream-10-aarch64/08522773-qm/builder-live.log.gz

Is there a c10s release?
No matching package to install: 'bluechi-selinux'

[engelmi]

I checked with a plain c10s container image and get the same error:

podman run -it quay.io/centos/centos:stream10 /bin/bash
$ dnf install bluechi-selinux 
CentOS Stream 10 - BaseOS                                                                    1.2 MB/s | 6.3 MB     00:05    
CentOS Stream 10 - AppStream                                                                 1.1 MB/s | 2.5 MB     00:02    
CentOS Stream 10 - Extras packages                                                           6.1 kB/s | 3.5 kB     00:00    
No match for argument: bluechi-selinux
Error: Unable to find a match: bluechi-selinux

I cross-checked BlueChi's releases:
https://src.fedoraproject.org/rpms/bluechi
And its available for EPEL10. After enabling EPEL on the c10s container, it found bluechi-selinux.

Is EPEL enabled for the build? I can't find the c10s build trigger in QMs .packit.yaml. @Yarboa

[Yarboa]

I checked with a plain c10s container image and get the same error:

podman run -it quay.io/centos/centos:stream10 /bin/bash
$ dnf install bluechi-selinux
CentOS Stream 10 - BaseOS 1.2 MB/s | 6.3 MB 00:05
CentOS Stream 10 - AppStream 1.1 MB/s | 2.5 MB 00:02
CentOS Stream 10 - Extras packages 6.1 kB/s | 3.5 kB 00:00
No match for argument: bluechi-selinux
Error: Unable to find a match: bluechi-selinux
I cross-checked BlueChi's releases: https://src.fedoraproject.org/rpms/bluechi And its available for EPEL10. After enabling EPEL on the c10s container, it found bluechi-selinux.

Is EPEL enabled for the build? I can't find the c10s build trigger in QMs .packit.yaml. @Yarboa

@engelmi need to check
Please open an issue with this comment,
Then we could close this one

It is failing on build for podman-next
https://github.com/containers/qm/blob/main/.packit.yaml#L27-L34
which related only to rpm build, no tests above it

[engelmi]

Ah, I think I found the issue:
For the copr_build job we add BlueChi's copr repo to the additional_repos list, but only for epel9. I created #708 to add also epel10.

Closing this issue and linked the PR to it (since its only related).
@Yarboa If we should keep this issue open till this is fixed, please reopen it. I think the PR should fix the copr build issue, though.

[Yarboa]

OK there was missing c10s target for Centos-stream 10

Added it, opened for monitoring for next merge