Created attachment 869558 [details]
aarch64_full_journal

Created attachment 869559 [details]
s390x_full_journal

The denials can be seen here:

https://openqa.suse.de/tests/12141777#step/health_check/56

Johannes, could you, please, analyse them and - most likely - provide policy fix?

(P1 until analysed)

I'll have a look

seems to be related to stats collection for some hw crypto on those archs. Don't think that this is serious. Checking this takes time as those archs are so very slow on my host ...

no occurring in emulation, probably since I don't have the proper hardware. I'll have a look at openssl and sshd

it is the crypto stats introduced with https://github.com/opencryptoki/libica/commit/a59af0ce9e8ecfeafcf10c589ff947f93fee8617

The whole idea seems fishy to me. There are functions that iterate over all entries that match the pattern. I try to get a test setup in which I can examine this closer

so this is triggered when openssl-ibmca is present. Then processes utilizing openssl (here sshd) will create this file.

This is not something we can fix in the policy. Depending on which process triggers the first usage of openssl the resulting file will have a file context based on the SELinux process context. Then other processes in their own contexts will try to access the file and fail. It's also not just limited to the type. The interactive program icastats can be called, which will create the file with a user security context, which will cause even more issues.

It's also quite an unfortunate choice for a security critical functionality to expose these stats (and consume them) globally. This looks very much like debug functionality which should be disabled in my view.

I also can create a shm segment for another UID and have the tooling operate on this, changing the UID of the shm segment to a UID of my choosing. Apart from corrupting the stats I couldn't find another way to exploit this, but I also didn't look this hard.

I've added the libica maintainer to discuss this. In my opinion this reporting functionality should be disabled.

Adding needinfo to make it more visible

As discussed offline with Jose Lausuch, I will try to add a whitelist for this bug to our test code and soft-fail it for now.

There is another error reported together:

Sep 15 17:26:17.629077 localhost.localdomain auditd[1737]: plugin /usr/sbin/sedispatch terminated unexpectedly

This can be seen on s390x and x86_64. Not sure whether it is SELinux related.

(In reply to Wayne Chen from comment #11)
> There is another error reported together:
> 
> Sep 15 17:26:17.629077 localhost.localdomain auditd[1737]: plugin
> /usr/sbin/sedispatch terminated unexpectedly
> 
> This can be seen on s390x and x86_64. Not sure whether it is SELinux related.

It has been tracked via bug https://bugzilla.suse.com/show_bug.cgi?id=1215377

And I have added a PR to soft-fail it https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/17792

Hello IBM,

Could you please review the attachments (s390x), and provide a feedback?

Thanks in advance.

*** Bug 1215426 has been marked as a duplicate of this bug. ***

(In reply to Nikolay Gueorguiev from comment #13)
> Hello IBM,
> 
> Could you please review the attachments (s390x), and provide a feedback?
> 
> Thanks in advance.

Hi Nikolay,

I'll mirror the bug to IBM and we'll take a look.

------- Comment From ifranzki@de.ibm.com 2023-09-19 08:31 EDT-------
@Christian: Didn't we have similar such cases already, and how have they been resolved back then?

------- Comment From Christian.Rund@de.ibm.com 2023-09-20 12:09 EDT-------
(In reply to comment #8)
> @Christian: Didn't we have similar such cases already, and how have they
> been resolved back then?
@Ingo: If I understand the current situation correctly I assume you are referring to the following commit to contribute to solve the reported problem. Otherwise I have not seen any fixes happened for SELinux rules
https://github.com/opencryptoki/libica/commit/cd5b2b75554875111bf375b555ebd3b185cff1a0

Regarding the setroubleshoot tool message: "failed to retrieve rpm info for path '/dev/shm/icastats_0':" in this context 'setroubleshoot' will not succeed to retrieve rpm information for the icastats shared memory segment as it is not directly owned by an RPM package:

# rpm -qf /dev/shm/icastats_0
file /dev/shm/icastats_0 is not owned by any package

In addition on one of our SLES test systems which happens to be a SLES15 SP3 system I installed the 'selinux-tools' package and checked that SELinux is not in use at all. We are using a default setup and do _not_ explicitly disable SELinux:
# getenforce
Disabled

I failed enabling SELinux by running 'setenforce Enforcing' or 'setenforce 1' when trying to investigate more on my end:
# setenforce Enforcing
setenforce: SELinux is disabled

The installed selinux releated packages on our test system were the ones listed below by zypper, and I am not aware of a missing package:
# zypper search selinux
Loading repository data...
Reading installed packages...

S  | Name                            | Summary                                           | Type
---+---------------------------------+---------------------------------------------------+--------
| libselinux-bindings-debugsource | Debug sources for package libselinux-bindings     | package
| libselinux-debugsource          | Debug sources for package libselinux              | package
| libselinux-devel                | Development files for the SELinux runtime library | package
i  | libselinux1                     | SELinux runtime library                           | package
| libselinux1-debuginfo           | Debug information for package libselinux1         | package
i+ | python3-selinux                 | Python bindings for the SELinux runtime library   | package
| python3-selinux-debuginfo       | Debug information for package python3-selinux     | package
i+ | selinux-tools                   | SELinux command-line utilities                    | package
| selinux-tools-debuginfo         | Debug information for package selinux-tools       | package

------- Comment From ifranzki@de.ibm.com 2023-09-21 02:18 EDT-------
@Christian: I was referring to similar cases where SE Linux caused the open of the statistics shm to fail. If I remember correctly, we back then requested to add SE Linux rules to cover that. Can you remember such cases ?

In any case, if libica fails to open the statistics shm, this should not cause any trouble. Libica is still fully functioning, it just won't record any statistics for that run.

So if its impossible (for whatever reason) to add proper SE Linux rules to allow the applications that use libica to open the shm, then this open failure can simply be ignored.

------- Comment From Christian.Rund@de.ibm.com 2023-09-21 05:07 EDT-------
(In reply to comment #11)
> @Christian: I was referring to similar cases where SE Linux caused the open
> of the statistics shm to fail. If I remember correctly, we back then
> requested to add SE Linux rules to cover that. Can you remember such cases ?
As I up to now I did not succeed to enable SELinux into 'Enforcing' mode I cannot ensure whether the necessary rules are in place or not.
What do we need to do do set the 'Enforcing' mode successfully up and running?

it's enough to have it in permissive mode to see the problem. If you need general guidance on how to install SELinux:
https://documentation.suse.com/sles/15-SP4/html/SLES-all/cha-selinux.html

I would not only concentrate on the SELinux issue here. I find it in general worrisome that a a crypto components collects stats like this (possible side channel?) in production. See my other concerns in comment 8.

The main problem for SELinux is that this shm segment will be created by the first process that uses openssl. Let's say there's a daemon that has an init script. If this init script invokes something that uses openssl then the shm will be created with a type that derives from the type used in the init script, which is likely incompatible with the type used for the daemon.

The whole design is an issue for SELinux. And since I have concerns about this being enabled by default at all I would like to see this put behind some debug flag.

------- Comment From ifranzki@de.ibm.com 2023-09-25 10:52 EDT-------
> I find it in general worrisome that a a crypto components collects stats like this (possible side channel?)

Please note that the statistics are counted per user. There are separate shms per user. A user's shm can only be accessed by that user (and root). So I don't really see how that would be a security risk. A single user can only see its own statistics, which is nothing that he wouldn't be able to know already anyway.

> I would like to see this put behind some debug flag

I disagree. Please note that having good crypto usage statistics is essential in order to find out which crypto algos and key sizes a workload uses. Clients typically don't just know that, they need statistics to find that out.
Especially with the move to post-quantum crypto algorithms, it is absolutely essential to be able to find out which algos and key sizes are currently used.

I'm not opposed to the functionality in general and agree that it is useful. I just don't think that this should be enabled permanently for all use cases, no matter if they need the information or not.

As to the risks: Currently every user can create this and populate it with faked data. This is then parsed by root when looking at all stats. Are you sure your parser is robust enough to handle malicious input?

But that's not really the main issue here. The problem is that due to the design it's next to impossible to get this properly handled in SELinux. The context of the shm depends on which process is started first that uses openssl. 

/dev/shm on my test system
-rw-------.  1 root root  system_u:object_r:tmpfs_t:s0        3.6K Sep 28 09:09 icastats_0
-rw-------.  1 sles users unconfined_u:object_r:user_tmp_t:s0 3.6K Sep 28 09:09 icastats_1000

The first one was created by a daemon that runs as root. The second one was created by a user that runs as unconfined and invoked openssl manually. As you can see the first three fields of the security context differ. Depending on how operations are ordered, which policy is used and how it is configured there are many ways how this can play out. Sometimes it will work, sometimes not.

I ATM don't see a reasonable way how to this could be handled on the policy side.

------- Comment From ifranzki@de.ibm.com 2023-09-28 05:33 EDT-------
So how did you handle this all the recent years ? The libica statistics are not new, they exist since long time. Also the IBMCA engine exists quite long, and with it it was all the time possible that any application that uses OpenSSL creates libica statistics shms. The IBMCA provider is just another flavor of an OpenSSL plugin, but not new in terms of libica statistics. So why is this a problem just now ?

Because we didn't use SELinux until now. This is a problem on any system that has SELinux enabled. As we used AppArmor this wasn't a problem for us until now

------- Comment From Christian.Rund@de.ibm.com 2023-10-18 10:42 EDT-------
(In reply to comment #17)
> Because we didn't use SELinux until now. This is a problem on any system
> that has SELinux enabled. As we used AppArmor this wasn't a problem for us
> until now
Hello Johannes,
there are distributions implementing SELinux which already support the libica statistics counting and providing the necessary rule set to satisfy the scheme as you showed above, especially using 'system_u' for the root user and 'unconfined_u' for non-root users.

/dev/shm on my test system
-rw-------.  1 root root  system_u:object_r:tmpfs_t:s0        3.6K Sep 28 09:09 icastats_0
-rw-------.  1 sles users unconfined_u:object_r:user_tmp_t:s0 3.6K Sep 28 09:09 icastats_1000

Hello,

can you please share which distributions support this so I can check their policy how they do that? I fail to see how to solve that in general (apart from fixing single use cases) and would be interested how they do that

*** Bug 1215909 has been marked as a duplicate of this bug. ***

------- Comment From Christian.Rund@de.ibm.com 2023-10-27 09:03 EDT-------
(In reply to comment #22)
> Hello,
>
> can you please share which distributions support this so I can check their
> policy how they do that? I fail to see how to solve that in general (apart
> from fixing single use cases) and would be interested how they do that
Hi Johannes,
you might want to check the most recent Fedora for this purpose.
Thanks,
Christian

sorry for the delayed response. Our s390x was moved and I didn't have access to a machine to work on this, then we had hackweek.

So the Fedora policy has as static mapping rule
/dev/shm/icastats_0     --      gen_context(system_u:object_r:ica_tmpfs_t,s0)
and some interfaces that allow working with ica_tmpfs_t.

We have the same rules. This only handles the special case for UID 0 and the daemons
- apache
- firewalld
- gssproxy
- sssd
- networkmanager
- ssh

So if any other daemon is started first and uses crypto (and for every UID!=0) this breaks. 

We can fix this for this case, but the general problem still stays that this concept is at odds with how SELinux works and will break in the future again (and is broken for every non-root user permanently unless it works by accident).

I'll will submit a fix, but I highly recommend to hide this behavior behind some debug flag

The ica module wasn't active. I'll create an update that will fix this. But as said this will only fix the common case, it's not a full solution

SUSE-RU-2023:4604-1: An update that has one fix can now be installed.

Category: recommended (moderate)
Bug References: 1215405
Sources used:
SUSE Linux Enterprise Micro for Rancher 5.4 (src): selinux-policy-20230511+git5.54d165ea-150400.4.18.1
SUSE Linux Enterprise Micro 5.4 (src): selinux-policy-20230511+git5.54d165ea-150400.4.18.1
openSUSE Leap Micro 5.4 (src): selinux-policy-20230511+git5.54d165ea-150400.4.18.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

SUSE-RU-2023:4603-1: An update that has one fix can now be installed.

Category: recommended (moderate)
Bug References: 1215405
Sources used:
SUSE Linux Enterprise Micro 5.5 (src): selinux-policy-20230511+git9.1b35a6ab-150500.3.6.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

The updates fix the problem, but the openQA test is to unspecific and matches other AVCs. I'll sent a PR to fix this

Created attachment 874540 [details]
sl micro 6.0 journal

Hi, even though https://build.suse.de/request/show/322950 was accepted. 
We still see this error in s390x architecture only for SL Micro 6.0.

@Johannes according to log from Jose, the ica module doesn't work at all. There is a new openssl-3-3.1.4-5.6.s390x.rpm and new openssl-ibmca-2.4.1-1.1.s390x.rpm. Is it possible that directories changed and rules are broken again?

@Johannes Segitz
As requested. 

https://openqa.suse.de/tests/14165208#step/journal_check/11

List of denials:

> type=AVC msg=audit(1714374319.869:166): avc:  denied  { read write } for  pid=2644 comm="firewalld" name="icastats_0" dev="tmpfs" ino=3 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:ica_tmpfs_t:s0 tclass=file permissive=0
> type=AVC msg=audit(1714374319.869:167): avc:  denied  { read write } for  pid=2644 comm="firewalld" name="icastats_0" dev="tmpfs" ino=3 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:ica_tmpfs_t:s0 tclass=file permissive=0
> type=AVC msg=audit(1714374319.869:168): avc:  denied  { read } for  pid=2644 comm="firewalld" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374319.869:169): avc:  denied  { read } for  pid=2644 comm="firewalld" name="hwrng" dev="devtmpfs" ino=118 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374319.869:170): avc:  denied  { read } for  pid=2644 comm="firewalld" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374319.869:171): avc:  denied  { read } for  pid=2644 comm="firewalld" name="hwrng" dev="devtmpfs" ino=118 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374319.869:172): avc:  denied  { read } for  pid=2644 comm="firewalld" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374319.869:173): avc:  denied  { read } for  pid=2644 comm="firewalld" name="hwrng" dev="devtmpfs" ino=118 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374319.869:174): avc:  denied  { read } for  pid=2644 comm="firewalld" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374319.869:175): avc:  denied  { read } for  pid=2644 comm="firewalld" name="hwrng" dev="devtmpfs" ino=118 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374320.839:195): avc:  denied  { read write } for  pid=2710 comm="firewalld" name="icastats_0" dev="tmpfs" ino=3 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:ica_tmpfs_t:s0 tclass=file permissive=0
> type=AVC msg=audit(1714374320.839:196): avc:  denied  { read write } for  pid=2710 comm="firewalld" name="icastats_0" dev="tmpfs" ino=3 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:ica_tmpfs_t:s0 tclass=file permissive=0
> type=AVC msg=audit(1714374320.839:197): avc:  denied  { read } for  pid=2710 comm="firewalld" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374320.839:198): avc:  denied  { read } for  pid=2710 comm="firewalld" name="hwrng" dev="devtmpfs" ino=118 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374320.839:199): avc:  denied  { read } for  pid=2710 comm="firewalld" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374320.839:200): avc:  denied  { read } for  pid=2710 comm="firewalld" name="hwrng" dev="devtmpfs" ino=118 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374320.839:201): avc:  denied  { read } for  pid=2710 comm="firewalld" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374320.839:202): avc:  denied  { read } for  pid=2710 comm="firewalld" name="hwrng" dev="devtmpfs" ino=118 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374320.839:203): avc:  denied  { read } for  pid=2710 comm="firewalld" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374320.839:204): avc:  denied  { read } for  pid=2710 comm="firewalld" name="hwrng" dev="devtmpfs" ino=118 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374321.319:209): avc:  denied  { read } for  pid=2735 comm="setroubleshootd" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374321.319:210): avc:  denied  { read } for  pid=2735 comm="setroubleshootd" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374321.319:211): avc:  denied  { read } for  pid=2735 comm="setroubleshootd" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374321.319:212): avc:  denied  { read } for  pid=2735 comm="setroubleshootd" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374321.319:213): avc:  denied  { read write } for  pid=2735 comm="setroubleshootd" name="z90crypt" dev="devtmpfs" ino=119 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:object_r:crypt_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374377.019:289): avc:  denied  { read write } for  pid=2983 comm="firewalld" name="icastats_0" dev="tmpfs" ino=3 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:ica_tmpfs_t:s0 tclass=file permissive=0
> type=AVC msg=audit(1714374377.019:290): avc:  denied  { read write } for  pid=2983 comm="firewalld" name="icastats_0" dev="tmpfs" ino=3 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:ica_tmpfs_t:s0 tclass=file permissive=0
> type=AVC msg=audit(1714374377.029:291): avc:  denied  { read } for  pid=2983 comm="firewalld" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374377.029:292): avc:  denied  { read } for  pid=2983 comm="firewalld" name="hwrng" dev="devtmpfs" ino=118 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374377.029:293): avc:  denied  { read } for  pid=2983 comm="firewalld" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374377.029:294): avc:  denied  { read } for  pid=2983 comm="firewalld" name="hwrng" dev="devtmpfs" ino=118 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374377.029:295): avc:  denied  { read } for  pid=2983 comm="firewalld" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374377.029:296): avc:  denied  { read } for  pid=2983 comm="firewalld" name="hwrng" dev="devtmpfs" ino=118 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374377.029:297): avc:  denied  { read } for  pid=2983 comm="firewalld" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374377.029:298): avc:  denied  { read } for  pid=2983 comm="firewalld" name="hwrng" dev="devtmpfs" ino=118 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374378.049:305): avc:  denied  { read write } for  pid=3015 comm="firewalld" name="icastats_0" dev="tmpfs" ino=3 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:ica_tmpfs_t:s0 tclass=file permissive=0
> type=AVC msg=audit(1714374378.049:306): avc:  denied  { read write } for  pid=3015 comm="firewalld" name="icastats_0" dev="tmpfs" ino=3 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:ica_tmpfs_t:s0 tclass=file permissive=0
> type=AVC msg=audit(1714374378.049:307): avc:  denied  { read } for  pid=3015 comm="firewalld" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374378.049:308): avc:  denied  { read } for  pid=3015 comm="firewalld" name="hwrng" dev="devtmpfs" ino=118 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374378.049:309): avc:  denied  { read } for  pid=3015 comm="firewalld" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374378.049:310): avc:  denied  { read } for  pid=3015 comm="firewalld" name="hwrng" dev="devtmpfs" ino=118 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374378.049:311): avc:  denied  { read } for  pid=3015 comm="firewalld" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374378.049:312): avc:  denied  { read } for  pid=3015 comm="firewalld" name="hwrng" dev="devtmpfs" ino=118 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374378.059:313): avc:  denied  { read } for  pid=3015 comm="firewalld" name="prandom" dev="devtmpfs" ino=263 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0
> type=AVC msg=audit(1714374378.059:314): avc:  denied  { read } for  pid=3015 comm="firewalld" name="hwrng" dev="devtmpfs" ino=118 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file permissive=0

I have the necessary change staged in
https://build.suse.de/package/show/home:jsegitz:branches:SUSE:ALP:Source:Standard:1.0/selinux-policy
but I struggle to test this ATM as the VM hangs upon reboot (unrelated problem). I'll give it another try on Thursday

Fix submitted in https://build.suse.de/request/show/328359

(In reply to Johannes Segitz from comment #43)
> Fix submitted in https://build.suse.de/request/show/328359

Hello Johannes, https://build.suse.de/request/show/328359, seems it is declined.

Is there any new fix ready?

I can still hit the issue on s390x like:

https://openqa.suse.de/tests/14364761#step/journal_check/12

The request was moved to SUSE:SLFO:Main by Giacomo: see https://build.suse.de/request/show/330545

@Richard: 
the image you are testing with is built with selinux-policy package version 20230511+git9.e8d4b4115-150500.1.1, which does not contain the fix yet. the fixed package version is 20230511+git15.bdc96df2-150500.3.15.1 (please note the "+git15")

you can either ask for a rebuild of the image with the policy version to prevent this denial again or fix the test case:

instead of `ausearch -m avc -r` use `ausearch -m avc -r -ts boot` in your test case
(probably here https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/consoletest.pm#L74)

so this is fixed for 5.5 i just tested it manually with the VM from the linked openQA test

ah, wait you also see issues in on 5.5? i will have a look since johannes is on vacation