There seems to be a generic rule in place:

unconfined_dontaudit_rw_pipes(domain)

introduced with this, quite a large patch:

commit 3eaa99394500c2267bfd85722ebde18ae44636bd
Author: Dan Walsh <dwalsh>
Date:   Thu Aug 26 09:41:21 2010 -0400

    UPdate for f14 policy

The sd_notify_barrier() exists since April 2020.  I do not think that is limited to unconfined_t but exists for every domain.  E.g. basically sd_notify_barrier() does (https://github.com/systemd/systemd/blob/0a67dd8310065a35a2fba2229b89ea0ab3e651fe/src/libsystemd/sd-daemon/sd-daemon.c#L555)
 
| pipe(pipe_fd);
| sendmsg("/run/systemd/notify", { SCM_RIGHTS, fds=[pipe_fd[1]] }

With current SELinux rules, this SCM_RIGHTS field is dropped in systemd's recvmsg() and MSG_CTRUNC flags are set

The systemd-notify program is confined by SELinux:

# ls -Z `which systemd-notify`
system_u:object_r:systemd_notify_exec_t:s0 /usr/bin/systemd-notify
#

To run the systemd-notify program in its SELinux domain, we need runcon:

# NOTIFY_SOCKET=/run/systemd/notify runcon system_u:system_r:initrc_t:s0 bash -c 'systemd-notify --ready'

because there is no transition from unconfined_t (root is unconfined user):

# sesearch -t systemd_notify_exec_t -T
type_transition cluster_t systemd_notify_exec_t:process systemd_notify_t;
type_transition condor_startd_t systemd_notify_exec_t:process systemd_notify_t;
type_transition glusterd_t systemd_notify_exec_t:process systemd_notify_t;
type_transition init_t systemd_notify_exec_t:process systemd_notify_t;
type_transition initrc_t systemd_notify_exec_t:process systemd_notify_t;
type_transition kdumpctl_t systemd_notify_exec_t:process systemd_notify_t;
type_transition openshift_initrc_t systemd_notify_exec_t:process systemd_notify_t;
type_transition piranha_pulse_t systemd_notify_exec_t:process systemd_notify_t;
#

When executed in enforcing mode, it triggers another SELinux denial, but it does not hang:
----
type=PROCTITLE msg=audit(12/02/2020 12:32:26.047:523) : proctitle=systemd-notify --ready 
type=PATH msg=audit(12/02/2020 12:32:26.047:523) : item=0 name=/run/systemd/notify inode=31 dev=00:1a mode=socket,777 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:init_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(12/02/2020 12:32:26.047:523) : cwd=/root 
type=SOCKADDR msg=audit(12/02/2020 12:32:26.047:523) : saddr={ saddr_fam=local path=/run/systemd/notify } 
type=SYSCALL msg=audit(12/02/2020 12:32:26.047:523) : arch=x86_64 syscall=sendmsg success=no exit=EACCES(Permission denied) a0=0x3 a1=0x7ffe1f2ea350 a2=MSG_NOSIGNAL a3=0x7ffe1f2ea2d4 items=1 ppid=932 pid=12809 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=3 comm=systemd-notify exe=/usr/bin/systemd-notify subj=system_u:system_r:systemd_notify_t:s0 key=(null) 
type=AVC msg=audit(12/02/2020 12:32:26.047:523) : avc:  denied  { sendto } for  pid=12809 comm=systemd-notify path=/run/systemd/notify scontext=system_u:system_r:systemd_notify_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=unix_dgram_socket permissive=0 
----

When executed in permissive mode, it complains about "Failed to invoke barrier: Connection timed out" and triggers following SELinux denials:
----
type=PROCTITLE msg=audit(12/02/2020 12:35:50.555:542) : proctitle=systemd-notify --ready 
type=PATH msg=audit(12/02/2020 12:35:50.555:542) : item=1 name=/lib64/ld-linux-x86-64.so.2 inode=137506 dev=fc:01 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=PATH msg=audit(12/02/2020 12:35:50.555:542) : item=0 name=/usr/bin/systemd-notify inode=147407 dev=fc:01 mode=file,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:systemd_notify_exec_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(12/02/2020 12:35:50.555:542) : cwd=/root 
type=EXECVE msg=audit(12/02/2020 12:35:50.555:542) : argc=2 a0=systemd-notify a1=--ready 
type=SYSCALL msg=audit(12/02/2020 12:35:50.555:542) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x55b23d6795e0 a1=0x55b23d677ae0 a2=0x55b23d676ca0 a3=0x8 items=2 ppid=932 pid=12823 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=3 comm=systemd-notify exe=/usr/bin/systemd-notify subj=system_u:system_r:systemd_notify_t:s0 key=(null) 
type=AVC msg=audit(12/02/2020 12:35:50.555:542) : avc:  denied  { append } for  pid=12823 comm=systemd-notify path=/dev/pts/0 dev="devpts" ino=3 scontext=system_u:system_r:systemd_notify_t:s0 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file permissive=1 
type=AVC msg=audit(12/02/2020 12:35:50.555:542) : avc:  denied  { read write } for  pid=12823 comm=systemd-notify path=/dev/pts/0 dev="devpts" ino=3 scontext=system_u:system_r:systemd_notify_t:s0 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file permissive=1 
----
type=PROCTITLE msg=audit(12/02/2020 12:35:50.563:543) : proctitle=systemd-notify --ready 
type=SYSCALL msg=audit(12/02/2020 12:35:50.563:543) : arch=x86_64 syscall=setsockopt success=yes exit=0 a0=0x3 a1=SOL_SOCKET a2=SO_SNDBUFFORCE a3=0x7ffe0db8dfc4 items=0 ppid=932 pid=12823 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=3 comm=systemd-notify exe=/usr/bin/systemd-notify subj=system_u:system_r:systemd_notify_t:s0 key=(null) 
type=AVC msg=audit(12/02/2020 12:35:50.563:543) : avc:  denied  { net_admin } for  pid=12823 comm=systemd-notify capability=net_admin  scontext=system_u:system_r:systemd_notify_t:s0 tcontext=system_u:system_r:systemd_notify_t:s0 tclass=capability permissive=1 
----
type=PROCTITLE msg=audit(12/02/2020 12:35:50.564:544) : proctitle=systemd-notify --ready 
type=PATH msg=audit(12/02/2020 12:35:50.564:544) : item=0 name=/run/systemd/notify inode=31 dev=00:1a mode=socket,777 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:init_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(12/02/2020 12:35:50.564:544) : cwd=/root 
type=SOCKADDR msg=audit(12/02/2020 12:35:50.564:544) : saddr={ saddr_fam=local path=/run/systemd/notify } 
type=SYSCALL msg=audit(12/02/2020 12:35:50.564:544) : arch=x86_64 syscall=sendmsg success=yes exit=7 a0=0x3 a1=0x7ffe0db8e040 a2=MSG_NOSIGNAL a3=0x7ffe0db8dfc4 items=1 ppid=932 pid=12823 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=3 comm=systemd-notify exe=/usr/bin/systemd-notify subj=system_u:system_r:systemd_notify_t:s0 key=(null) 
type=AVC msg=audit(12/02/2020 12:35:50.564:544) : avc:  denied  { sendto } for  pid=12823 comm=systemd-notify path=/run/systemd/notify scontext=system_u:system_r:systemd_notify_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=unix_dgram_socket permissive=1 
----

Of course, dontaudit rules were removed before.

Let me know, if this issue should be filed in a separate BZ.

systemd-notify is a program which can be used e.g. in shell scripts.

But daemons can call the https://www.freedesktop.org/software/systemd/man/sd_notify.html API functions directly and the pipes will be created with their domain type.

So I think there should be a rule so that when a domain type can use the notify functions (can access /run/systemd/notify), init_t must be allowed to write in their fifos.  Perhaps there exists already some systemd interface which can be extended in this way?

Test coverage for this bug exists in a form of PR:
 * https://src.fedoraproject.org/tests/selinux/pull-request/146

The PR waits for review.

This permission needs to be allowed for init and for user domains, probably the login_userdomain attribute.

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.