Bug 2056565

I'm not 100% sure whether that isn't an issue with labeling here as well. It seems like this is a problem that should also be reported against the main policy as I don't think it's specific to something OpenStack is doing or where it's installing things?


Just noting the SELinux policy version for reference: selinux-policy-34.1.25-1.el9.noarch

I'm also finding references to this kind of issues happening when /tmp is mounted with tmpfs_t context instead of tmp_t (e.g. [1]). Not sure if this may be the difference between the two versions here, I'm not sure if the output of ls -lZ /tmp is available in the logs, or if that's where the file is being accessed.


[1] https://bugs.centos.org/view.php?id=10069

I've submitted a test patch to check selinux labels of /tmp.
 https://review.opendev.org/c/openstack/puppet-openstack-integration/+/831900

I'll check the type assigned to that directory once ci run completes.

Sorry for the delay. Have you been able to get the information? Based on your last comment on the review, I will move the bug to CentOS 9 if there is no objection as that seems like a more future-proof place to fix this if the path isn't specific to OpenStack. Thank you!

Sorry this bug has dropped from my memory. I'll put needinfo on me and will update you.

Just fyi, I noticed this is causing rabbitmq to fail to start when selinux is enforced
so this might have higher severity than expected.

I've captured the information in CentOS 9 job.

Auditd complains that rabbitmq tried to access a file with context tmpfs_t .
~~~
type=AVC msg=audit(1654738461.728:4975): avc:  denied  { write } for  pid=40600 comm="beam.smp" name="memfd:vmem" dev="tmpfs" ino=4106 scontext=system_u:system_r:rabbitmq_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=file permissive=1
~~~

However according to the output of `$sudo ls -laZ /tmp`, /tmp has tmp_t instead of tmpfs_t...
~~~
total 1520
drwxrwxrwt. 22 root  root  system_u:object_r:tmp_t:s0             4096 Jun  9 02:26 .
drwxr-xr-x. 21 root  root  system_u:object_r:root_t:s0            4096 Jun  9 01:32 ..
drwx------.  2 zuul  zuul  unconfined_u:object_r:user_tmp_t:s0    4096 Jun  9 01:23 ansible_command_payload_fw0z6y6k
...
~~~

It seems rabbitmq fails to start because of this selinux denial when selinux is enforced.

~~~
Jun 08 18:11:27 centos-9-stream-ovh-gra1-0029941684 systemd[1]: Starting RabbitMQ broker...
Jun 08 18:11:27 centos-9-stream-ovh-gra1-0029941684 rabbitmq-server[38490]: beam/jit/x86/beam_asm.cpp:167:pick_allocator(): Internal error: jit: Cannot allocate executable memory. Use the interpreter instead.
Jun 08 18:11:27 centos-9-stream-ovh-gra1-0029941684 systemd[1]: Created slice Slice /system/systemd-coredump.
Jun 08 18:11:27 centos-9-stream-ovh-gra1-0029941684 systemd[1]: Started Process Core Dump (PID 38498/UID 0).
Jun 08 18:11:27 centos-9-stream-ovh-gra1-0029941684 systemd-coredump[38499]: Resource limits disable core dumping for process 38490 (beam.smp).
Jun 08 18:11:27 centos-9-stream-ovh-gra1-0029941684 systemd-coredump[38499]: Process 38490 (beam.smp) of user 985 dumped core.
Jun 08 18:11:27 centos-9-stream-ovh-gra1-0029941684 systemd[1]: rabbitmq-server.service: Main process exited, code=dumped, status=6/ABRT
Jun 08 18:11:27 centos-9-stream-ovh-gra1-0029941684 systemd[1]: rabbitmq-server.service: Failed with result 'core-dump'.
Jun 08 18:11:27 centos-9-stream-ovh-gra1-0029941684 systemd[1]: Failed to start RabbitMQ broker.
Jun 08 18:11:27 centos-9-stream-ovh-gra1-0029941684 systemd[1]: systemd-coredump: Deactivated successfully.
~~~

~~~
type=AVC msg=audit(1654711887.924:3177): avc:  denied  { write } for  pid=38490 comm="beam.smp" name="memfd:vmem" dev="tmpfs" ino=10 scontext=system_u:system_r:rabbitmq_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=file permissive=0
type=SYSCALL msg=audit(1654711887.924:3177): arch=c000003e syscall=77 success=no exit=-13 a0=10 a1=1000 a2=7f3c4e1aec80 a3=55f11a394210 items=0 ppid=1 pid=38490 auid=4294967295 uid=985 gid=985 euid=985 suid=985 fsuid=985 egid=985 sgid=985 fsgid=985 tty=(none) ses=4294967295 comm="beam.smp" exe="/usr/lib64/erlang/erts-12.1.5/bin/beam.smp" subj=system_u:system_r:rabbitmq_t:s0 key=(null)ARCH=x86_64 SYSCALL=ftruncate AUID="unset" UID="rabbitmq" GID="rabbitmq" EUID="rabbitmq" SUID="rabbitmq" FSUID="rabbitmq" EGID="rabbitmq" SGID="rabbitmq" FSGID="rabbitmq"
type=PROCTITLE msg=audit(1654711887.924:3177): proctitle=2F7573722F6C696236342F65726C616E672F657274732D31322E312E352F62696E2F6265616D2E736D70002D570077002D4D426173006167656666636266002D4D486173006167656666636266002D4D426C6D62637300353132002D4D486C6D62637300353132002D4D4D6D6373003330002D500031303438353736002D74
type=AVC msg=audit(1654711887.925:3178): avc:  denied  { execmem } for  pid=38490 comm="beam.smp" scontext=system_u:system_r:rabbitmq_t:s0 tcontext=system_u:system_r:rabbitmq_t:s0 tclass=process permissive=0
type=SYSCALL msg=audit(1654711887.925:3178): arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=20000 a2=7 a3=22 items=0 ppid=1 pid=38490 auid=4294967295 uid=985 gid=985 euid=985 suid=985 fsuid=985 egid=985 sgid=985 fsgid=985 tty=(none) ses=4294967295 comm="beam.smp" exe="/usr/lib64/erlang/erts-12.1.5/bin/beam.smp" subj=system_u:system_r:rabbitmq_t:s0 key=(null)ARCH=x86_64 SYSCALL=mmap AUID="unset" UID="rabbitmq" GID="rabbitmq" EUID="rabbitmq" SUID="rabbitmq" FSUID="rabbitmq" EGID="rabbitmq" SGID="rabbitmq" FSGID="rabbitmq"
~~~

I've moved this to selinux-policy because the policy rules for rabbitmq is implemented in that package instead of openstack-selinux.

I've submitted a PR to address denials for write/read/execute which I initially reported.
Interestingly we also find denials about execmem but I'd leave it now and address it separately if needed ...

To backport:
commit 944c765970794e8aae72f15ea3f630aa09234d14 (HEAD -> rawhide, upstream/rawhide)
Author: Takashi Kajinami <tkajinam>
Date:   Thu Jun 9 15:54:38 2022 +0900

    Allow rabbitmq to access its private memfd: objects

OK I also confirmed the denials mentioned in commet:18 is reproduced in our CI jobs.

type=AVC msg=audit(1654884684.383:4434): avc:  denied  { getattr } for  pid=40772 comm="10_dirty_io_sch" path="/run/systemd/notify" dev="tmpfs" ino=36 scontext=system_u:system_r:rabbitmq_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=sock_file permissive=1
type=AVC msg=audit(1654884684.383:4435): avc:  denied  { read } for  pid=40772 comm="10_dirty_io_sch" name="notify" dev="tmpfs" ino=36 scontext=system_u:system_r:rabbitmq_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=sock_file permissive=1


Will submit a fix for that as well.

(In reply to Takashi Kajinami from comment #19)
> OK I also confirmed the denials mentioned in commet:18 is reproduced in our
> CI jobs.
> 
> type=AVC msg=audit(1654884684.383:4434): avc:  denied  { getattr } for 
> pid=40772 comm="10_dirty_io_sch" path="/run/systemd/notify" dev="tmpfs"
> ino=36 scontext=system_u:system_r:rabbitmq_t:s0
> tcontext=system_u:object_r:init_var_run_t:s0 tclass=sock_file permissive=1
> type=AVC msg=audit(1654884684.383:4435): avc:  denied  { read } for 
> pid=40772 comm="10_dirty_io_sch" name="notify" dev="tmpfs" ino=36
> scontext=system_u:system_r:rabbitmq_t:s0
> tcontext=system_u:object_r:init_var_run_t:s0 tclass=sock_file permissive=1
> 
> 
> Will submit a fix for that as well.

I've submitted a fix for this.
 https://github.com/fedora-selinux/selinux-policy/pull/1231

Please let me know in case I should create a separate bug.

Hi Zdenek,

Could you please check comment:20 and the additional patch I proposed when you have time ?

So we need to allow rabbitmq_t to read init_var_run_t:sock_file.

In the second patch, we used init_stream_connect, but this internally uses stream_connect_pattern, which then uses write_sock_file_perms, which does not allow read.

IIUC there are a few options we have now.
 1) Update that stream_connect_pattern (and dgram_send_pattern ?) to allow read 
 2) Update init_stream_connect to allow read
 3) Introduce a new macro to additionally allow read

I feel like the 1 would be preferable but am concerned that it can affect multiple rules depending on it.


@Zdenek May I ask for your suggestion ?

I've just written a more generic solution:
https://github.com/fedora-selinux/selinux-policy/pull/1283

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 (selinux-policy 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-2022:8283