Hi,

Thank you for reporting the issue. Was the denial triggered directly after undocking? In the setroubleshoot alert we see "2020-04-26 00:01:01 GMT".

While systemd and various its service already have access to efivarfs, this denial was triggered by logrotate. Do you by any change know which service, executing systemctl, it was?

These steps can get more of auditing:

1) Open /etc/audit/rules.d/audit.rules file in an editor.
2) Remove following line if it exists:
-a task,never
3) Add following line at the end of the file:
-w /etc/shadow -p w
4) Restart the audit daemon:
  # service auditd restart
5) Re-run your scenario or wait until it happens again
6) Collect audit denials:
  # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

(In reply to Zdenek Pytela from comment #1)
> Was the denial triggered directly after undocking?
It happened a few seconds after. I unplugged the dock, carried the laptop with me into the next room, had a seat and that's when I noticed the SELinux Troubleshooter.

> Do you by any change know which service, executing systemctl, it was?
I'm afraid not.

> 5) Re-run your scenario or wait until it happens again
Will do. It hasn't happened since but I'll inspect the audit denials as soon as it does and send them your way.

For me, this happened right after wake from sleep and login to the GUI.

Similar problem has been detected:

Occurred spontaneously when systemd logrotate service ran.

hashmarkername: setroubleshoot
kernel:         5.6.10-300.fc32.x86_64
package:        selinux-policy-targeted-3.14.5-38.fc32.noarch
reason:         SELinux is preventing systemctl from 'read' accesses on the file SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c.
type:           libreport

Similar problem has been detected:

Everytime after booting the system (the system was upgraded to F32 from F31 few days/weeks ago

hashmarkername: setroubleshoot
kernel:         5.6.10-300.fc32.x86_64
package:        selinux-policy-targeted-3.14.5-38.fc32.noarch
reason:         SELinux is preventing systemctl from 'read' accesses on the file SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c.
type:           libreport

(In reply to Zdenek Pytela from comment #1)

> These steps can get more of auditing:
> 
> 1) Open /etc/audit/rules.d/audit.rules file in an editor.
> 2) Remove following line if it exists:
> -a task,never
> 3) Add following line at the end of the file:
> -w /etc/shadow -p w
> 4) Restart the audit daemon:
>   # service auditd restart
> 5) Re-run your scenario or wait until it happens again
> 6) Collect audit denials:
>   # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

Here is the my result after following your steps and rebooting the whole system:

---
type=AVC msg=audit(05/10/2020 00:01:01.601:660) : avc:  denied  { read } for  pid=20654 comm=systemctl name=SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c dev="efivarfs" ino=1221 scontext=system_u:system_r:logrotate_t:s0 tcontext=system_u:object_r:efivarfs_t:s0 tclass=file permissive=0 
---

I don't see any extra information from the original report!

Here are the changes i did to the audit.rules file to verify what i did:
---
#-a task,never
-w /etc/shadow -p w
---

Similar problem has been detected:

Running VMware Workstation 15.5.2 for Linux

hashmarkername: setroubleshoot
kernel:         5.6.12-300.fc32.x86_64
package:        selinux-policy-targeted-3.14.5-38.fc32.noarch
reason:         SELinux is preventing systemctl from 'read' accesses on the file SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c.
type:           libreport

Similar problem has been detected:

SELinux alert appears sometimes after wake up from suspend

hashmarkername: setroubleshoot
kernel:         5.6.12-300.fc32.x86_64
package:        selinux-policy-targeted-3.14.5-38.fc32.noarch
reason:         SELinux is preventing systemctl from 'read' accesses on the Datei SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c.
type:           libreport

Also here after each reboot, it's a desktop PC, no dock/undock, Cinnamon F32, upgraded from F31 (and other versions before).

SELinux is preventing systemctl from read access on the file SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that systemctl should be allowed read access on the SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'systemctl' --raw | audit2allow -M my-systemctl
# semodule -X 300 -i my-systemctl.pp

Additional Information:
Source Context                system_u:system_r:logrotate_t:s0
Target Context                system_u:object_r:efivarfs_t:s0
Target Objects                SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c [
                              file ]
Source                        systemctl
Source Path                   systemctl
Port                          <Unknown>
Host                          xxx
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-3.14.5-38.fc32.noarch
Local Policy RPM              selinux-policy-targeted-3.14.5-38.fc32.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     xxx
Platform                      Linux xxx 5.6.12-300.fc32.x86_64 #1 SMP Mon May
                              11 16:47:13 UTC 2020 x86_64 x86_64
Alert Count                   1
First Seen                    2020-05-17 08:31:42 CEST
Last Seen                     2020-05-17 08:31:42 CEST
Local ID                      71b0b10e-bbd7-4a17-b55e-91139162655d

Raw Audit Messages
type=AVC msg=audit(1589697102.21:142): avc:  denied  { read } for  pid=1042 comm="systemctl" name="SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c" dev="efivarfs" ino=1143 scontext=system_u:system_r:logrotate_t:s0 tcontext=system_u:object_r:efivarfs_t:s0 tclass=file permissive=0


Hash: systemctl,logrotate_t,efivarfs_t,file,read

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

Thank you all for you cooperation, this bug will be resolved with the fix for bz#1824196.

*** This bug has been marked as a duplicate of bug 1824196 ***

# ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today
----
type=PROCTITLE msg=audit(05/19/2020 00:01:02.472:577) : proctitle=/usr/bin/systemctl --quiet is-active psacct.service 
type=PATH msg=audit(05/19/2020 00:01:02.472:577) : item=0 name=/sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c inode=15548 dev=00:1c mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:efivarfs_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(05/19/2020 00:01:02.472:577) : cwd=/ 
type=SYSCALL msg=audit(05/19/2020 00:01:02.472:577) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=0xffffff9c a1=0x5632c2c7fe40 a2=O_RDONLY|O_NOCTTY|O_CLOEXEC a3=0x0 items=1 ppid=10059 pid=10060 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemctl exe=/usr/bin/systemctl subj=system_u:system_r:logrotate_t:s0 key=(null) 
type=AVC msg=audit(05/19/2020 00:01:02.472:577) : avc:  denied  { read } for  pid=10060 comm=systemctl name=SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c dev="efivarfs" ino=15548 scontext=system_u:system_r:logrotate_t:s0 tcontext=system_u:object_r:efivarfs_t:s0 tclass=file permissive=0