Description of problem: Ran dnf upgrade SELinux is preventing tlp from 'getattr' accesses on the file /usr/bin/systemctl. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that tlp should be allowed getattr access on the systemctl 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 'tlp' --raw | audit2allow -M my-tlp # semodule -X 300 -i my-tlp.pp Additional Information: Source Context system_u:system_r:tlp_t:s0-s0:c0.c1023 Target Context system_u:object_r:systemd_systemctl_exec_t:s0 Target Objects /usr/bin/systemctl [ file ] Source tlp Source Path tlp Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages systemd-249.4-1.fc35.x86_64 systemd-249.4-2.fc35.x86_64 SELinux Policy RPM selinux-policy-targeted-35.1-1.fc35.noarch Local Policy RPM selinux-policy-targeted-35.1-1.fc35.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.14.10-300.fc35.x86_64 #1 SMP Thu Oct 7 20:48:44 UTC 2021 x86_64 x86_64 Alert Count 1 First Seen 2021-10-12 22:56:38 CEST Last Seen 2021-10-12 22:56:38 CEST Local ID efcd2139-27c2-4b5a-82b0-85f507335c40 Raw Audit Messages type=AVC msg=audit(1634072198.251:707): avc: denied { getattr } for pid=10647 comm="tlp" path="/usr/bin/systemctl" dev="nvme0n1p3" ino=3065887 scontext=system_u:system_r:tlp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_systemctl_exec_t:s0 tclass=file permissive=0 Hash: tlp,tlp_t,systemd_systemctl_exec_t,file,getattr Version-Release number of selected component: selinux-policy-targeted-35.1-1.fc35.noarch Additional info: component: selinux-policy reporter: libreport-2.15.2 hashmarkername: setroubleshoot kernel: 5.14.10-300.fc35.x86_64 type: libreport
Similar problem has been detected: Updated TLP hashmarkername: setroubleshoot kernel: 5.13.19-200.fc35.x86_64 package: selinux-policy-targeted-35.3-1.20211019git94970fc.fc35.noarch reason: SELinux is preventing tlp from 'getattr' accesses on the file /usr/bin/systemctl. type: libreport
Similar problem has been detected: dnf upgrade hashmarkername: setroubleshoot kernel: 5.13.19-200.fc35.x86_64 package: selinux-policy-targeted-35.3-1.20211019git94970fc.fc35.noarch reason: SELinux is preventing tlp from 'getattr' accesses on the file /usr/bin/systemctl. type: libreport
Similar problem has been detected: Laptop lid closed and opened again, suspend mode enabled when laptop lid is closed. Charging cable disconnected. Wifi reconnects to eduroam Maybe tlp does something in order to save power hashmarkername: setroubleshoot kernel: 5.14.14-300.fc35.x86_64 package: selinux-policy-targeted-35.3-1.20211019git94970fc.fc35.noarch reason: SELinux is preventing tlp from 'getattr' accesses on the Datei /usr/bin/systemctl. type: libreport
I've submitted a Fedora PR to address the issue as described: https://github.com/fedora-selinux/selinux-policy/pull/932 Could you please check if this set is sufficient? # cat local_tlp_systemctl.cil (allow tlp_t systemd_systemctl_exec_t (file (getattr open map read execute ioctl lock execute_no_trans))) # semodule -i local_tlp_systemctl.cil <reproduce the issue> # semodule -d local_tlp_systemctl # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today
@zdenek@zpytela This seems to be far not enough unfortunately. I'm getting 4 new alerts.
Created attachment 1839418 [details] ausearch output
Further information: For me this SELinux alter bonanza starts after updating the tlp package from version tlp-1.3.1-5.fc35.noarch to tlp-1.4.0-2.fc35.noarch. Something in the 1.4.0 version in combination with SELinux seems to be seriously broken. I reverted the TLP update again and added a versionlock for tlp-1.3.1-5.fc35.noarch
Similar problem has been detected: After upgrading to Fedora 35, these alerts come up when waking from sleep, unplugging laptop AC adapter, or plugging in laptop AC adapter. hashmarkername: setroubleshoot kernel: 5.14.14-300.fc35.x86_64 package: selinux-policy-targeted-35.3-1.20211019git94970fc.fc35.noarch reason: SELinux is preventing tlp from 'getattr' accesses on the file /usr/bin/systemctl. type: libreport
Similar problem has been detected: This denial pops up randomly on my system with tlp running. I believe tlp you have access to systemctl. hashmarkername: setroubleshoot kernel: 5.14.10-300.fc35.x86_64 package: selinux-policy-targeted-35.3-1.20211019git94970fc.fc35.noarch reason: SELinux is preventing tlp from 'getattr' accesses on the file /usr/bin/systemctl. type: libreport
@
Thank you for the data, I've updated the PR accordingly. The tabrmd_t type is not in selinux-policy, so it needs to be addressed in a different component. I'd appreciate more information with full auditing enabled: 1) Open the /etc/audit/rules.d/audit.rules file in an editor. 2) Remove the following line if it exists: -a task,never 3) Add the following line to the end of the file: -w /etc/shadow -p w 4) Restart the audit daemon: # service auditd restart 5) Re-run your scenario. 6) Collect AVC denials: # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today You can try to install the test package version: https://github.com/fedora-selinux/selinux-policy/pull/932 Show all checks -> build-rpm -> Details -> Artifacts -> rpms
*** Bug 2018664 has been marked as a duplicate of this bug. ***
FEDORA-2021-64eb16151d has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-64eb16151d
FEDORA-2021-64eb16151d has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-64eb16151d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-64eb16151d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
@zpytela The patch seems to a fixed most of the issues. Thanks :) However when I perform the suggested changes regarding the /etc/audit/rules.d/audit.rules, I can see those after a reboot: type=USER_AVC msg=audit(05/11/21 09:11:55.958:294) : pid=1076 uid=dbus auid=unset ses=unset subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:tabrmd_t:s0 tclass=dbus permissive=0 exe=/usr/bin/dbus-broker sauid=dbus hostname=? addr=? terminal=?' ---- type=USER_AVC msg=audit(05/11/21 09:11:55.959:295) : pid=1076 uid=dbus auid=unset ses=unset subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:tabrmd_t:s0 tclass=dbus permissive=0 exe=/usr/bin/dbus-broker sauid=dbus hostname=? addr=? terminal=?' ---- type=USER_AVC msg=audit(05/11/21 09:11:55.987:296) : pid=1076 uid=dbus auid=unset ses=unset subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:tabrmd_t:s0 tclass=dbus permissive=0 exe=/usr/bin/dbus-broker sauid=dbus hostname=? addr=? terminal=?' ---- type=USER_AVC msg=audit(05/11/21 09:11:55.987:297) : pid=1076 uid=dbus auid=unset ses=unset subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:tabrmd_t:s0 tclass=dbus permissive=0 exe=/usr/bin/dbus-broker sauid=dbus hostname=? addr=? terminal=?' ---- type=USER_AVC msg=audit(05/11/21 09:11:56.867:302) : pid=1076 uid=dbus auid=unset ses=unset subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for scontext=system_u:system_r:tlp_t:s0 tcontext=system_u:system_r:NetworkManager_t:s0 tclass=dbus permissive=0 exe=/usr/bin/dbus-broker sauid=dbus hostname=? addr=? terminal=?' ---- type=USER_AVC msg=audit(05/11/21 09:11:56.868:303) : pid=1076 uid=dbus auid=unset ses=unset subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for scontext=system_u:system_r:tlp_t:s0 tcontext=system_u:system_r:NetworkManager_t:s0 tclass=dbus permissive=0 exe=/usr/bin/dbus-broker sauid=dbus hostname=? addr=? terminal=?'
The dbus communication should be allowed: https://github.com/fedora-selinux/selinux-policy/pull/936 For tabrmd_t see #c11.
FEDORA-2021-64eb16151d has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
*** Bug 1990038 has been marked as a duplicate of this bug. ***
*** Bug 2013453 has been marked as a duplicate of this bug. ***
*** Bug 2013451 has been marked as a duplicate of this bug. ***
*** Bug 2013449 has been marked as a duplicate of this bug. ***
*** Bug 2013443 has been marked as a duplicate of this bug. ***
*** Bug 2013444 has been marked as a duplicate of this bug. ***
*** Bug 2013445 has been marked as a duplicate of this bug. ***
*** Bug 2013447 has been marked as a duplicate of this bug. ***