Fully up2date Fedora 32 workstation install (default gnome3 desktop, etc.), with selinux-policy manually updated to: selinux-policy-3.14.5-29.fc32.noarch Everything seems to work without any issues while in enforcing mode, which is much better then a while ago. Thank you for all your work on this. Upon checking /var/log/audit/audit.log I've found that there is still one AVC being logged: type=AVC msg=audit(1583668489.573:145): avc: denied { sys_nice } for pid=1299 comm="accounts-daemon" capability=23 scontext=system_u:system_r:accountsd_t:s0 tcontext=system_u:system_r:accountsd_t:s0 tclass=capability permissive=0
Raymond, accounts-daemon requests sys_nice capability: Is it correct and expected?
Hans, Apart from the denial, do you also see some functionality issues?
(In reply to Zdenek Pytela from comment #2) > Apart from the denial, do you also see some functionality issues? No everything is working fine AFAICT.
Kalev, We seem to have multiple instances of this bz for different domains (services) in Rawhide and F32. Can we, along with resolution of bz#1795524, dontaudit the sys_nice capability permission requests as well? Services as such look working.
Hi Zdenek, My position about this is still the same: Instead of dontaudit and denying, I think these daemons should all be allowed to change their capability permissions.
*** Bug 1815312 has been marked as a duplicate of this bug. ***
Similar problem has been detected: It's been happening since upgrade to F32 (KDE Spin) after every boot-up. hashmarkername: setroubleshoot kernel: 5.6.2-300.fc32.x86_64 package: selinux-policy-3.14.5-32.fc32.noarch reason: SELinux is preventing accounts-daemon from using the 'sys_nice' capabilities. type: libreport
Similar problem has been detected: Rebooted after updates. hashmarkername: setroubleshoot kernel: 5.6.2-300.fc32.x86_64 package: selinux-policy-3.14.5-32.fc32.noarch reason: SELinux is preventing accounts-daemon from using the 'sys_nice' capabilities. type: libreport
Similar problem has been detected: F31 -> F32 Beta upgrade with dnf system-upgrade and system up to date. Relabel was done after SELinux alerts but still present. hashmarkername: setroubleshoot kernel: 5.6.2-301.fc32.x86_64 package: selinux-policy-3.14.5-32.fc32.noarch reason: SELinux is preventing accounts-daemon from using the 'sys_nice' capabilities. type: libreport
*** Bug 1815314 has been marked as a duplicate of this bug. ***
*** Bug 1814142 has been marked as a duplicate of this bug. ***
*** Bug 1816787 has been marked as a duplicate of this bug. ***
*** Bug 1812165 has been marked as a duplicate of this bug. ***
I've submitted a Fedora PR to address the issue: https://github.com/fedora-selinux/selinux-policy/pull/345
commit ad1d35503f55f535401daa0a59913aa559c38d44 (HEAD -> rawhide, origin/rawhide) Author: Zdenek Pytela <zpytela> Date: Thu Apr 9 15:11:31 2020 +0200 Introduce daemons_dontaudit_scheduling boolean Introduce daemons_dontaudit_scheduling boolean to dontaudit daemons the setsched process permission and sys_nice capability which are requested to modify various scheduling information. With a change introduced to glib2 [1], all daemons using this library start to require the setsched permission and sys_nice capability. As allowing them to all daemons is too generic, dontauditing is used instead, but still can be allowed for particular domain types. With later glib2 updates, library call fallbacks to different code path if the permission is not allowed so a daemon does not crash. For more info, see the discussion in rhbz#1795524. [1] https://gitlab.gnome.org/GNOME/glib/issues/1834 With this update, the previous dontaudit setsched rule was moved to a tunable block and a dontaudit sys_nice rule was added. The boolean is enabled by default meaning the denied permissions will be dontaudited. After turning it off, the denials start to be audited. Resolves: rhbz#1811407
Kalev, Thank you for your response. I read over the bz#1795524 discussion again and finally suggested to dontaudit the sys_nice permission as well, this time controlled by a new boolean, together with the already dontaudited setsched. We needed to take some action now; if there is a need for further clarifications, please let us know.
*** Bug 1818759 has been marked as a duplicate of this bug. ***
Similar problem has been detected: Booted and launched KDE. Started after upgrading from F31 to F32. hashmarkername: setroubleshoot kernel: 5.6.4-300.fc32.x86_64 package: selinux-policy-3.14.5-32.fc32.noarch reason: SELinux is preventing accounts-daemon from using the 'sys_nice' capabilities. type: libreport
Unfortunately, there was some reports about pcscd too but those got closed being duplicates, and then the ticket got closed. but also the referenced bug report as it was NOT regarding sys_nice Raw-Audit-Meldungen type=AVC msg=audit(1587540033.756:290): avc: denied { sys_nice } for pid=5742 comm="pcscd" capability=23 scontext=system_u:system_r:pcscd_t:s0 tcontext=system_u:system_r:pcscd_t:s0 tclass=capability permissive=0 see https://bugzilla.redhat.com/show_bug.cgi?id=1802423
The sys_nice permission will be dontaudited for all daemons in the next F32 package release. In rawhide it already is in place.
I also get an AVC for this the first time I issue "sudo firewall-cmd --reload". type=AVC msg=audit(1587810753.802:372): avc: denied { sys_nice } for pid=691 comm="firewalld" capability=23 scontext=system_u:system_r:firewalld_t:s0 tcontext=system_u:system_r:firewalld_t:s0 tclass=capability permissive=0 And this one for pcscd type=AVC msg=audit(1587810808.611:381): avc: denied { sys_nice } for pid=3099 comm="pcscd" capability=23 scontext=system_u:system_r:pcscd_t:s0 tcontext=system_u:system_r:pcscd_t:s0 tclass=capability permissive=0
And, FWIW, I misread comment 20. :-( Sorry for the noise.
Similar problem has been detected: Popped up after logging in. hashmarkername: setroubleshoot kernel: 5.6.6-300.fc32.x86_64 package: selinux-policy-3.14.5-32.fc32.noarch reason: SELinux is preventing accounts-daemon from using the 'sys_nice' capabilities. type: libreport
Dominik, The sys_nice permission will be dontaudited for all daemons in the next F32 package release. In rawhide it already is in place.
*** Bug 1828048 has been marked as a duplicate of this bug. ***
Similar problem has been detected: just boot after upgrade hashmarkername: setroubleshoot kernel: 5.6.6-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-32.fc32.noarch reason: SELinux is preventing accounts-daemon from using the 'sys_nice' capabilities. type: libreport
FEDORA-2020-3ffe9fdf42 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-3ffe9fdf42
Tested, and +Karma given.
Similar problem has been detected: I have upgradet to Fedora 32 and logedin as usual. hashmarkername: setroubleshoot kernel: 5.6.7-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-32.fc32.noarch reason: SELinux is preventing accounts-daemon from using the 'sys_nice' capabilities. type: libreport
Similar problem has been detected: Run an (updated from f31) f32 install in virt-manager. hashmarkername: setroubleshoot kernel: 5.6.7-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-32.fc32.noarch reason: SELinux is preventing spice-vdagentd from using the 'sys_nice' capabilities. type: libreport
FEDORA-2020-3ffe9fdf42 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-3ffe9fdf42` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-3ffe9fdf42 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Similar problem has been detected: This happened on the first boot after upgrading Fedora 31 to 32. hashmarkername: setroubleshoot kernel: 5.6.6-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-32.fc32.noarch reason: SELinux is preventing accounts-daemon from using the 'sys_nice' capabilities. type: libreport
Warning : Applying https://bodhi.fedoraproject.org/updates/FEDORA-2020-3ffe9fdf42 brakes the system ! Installation of the packages hangs - I had to perform a "hard shutdown" by pressing the power button.
Christian, Could you please share more details? At which phase the update hangs, what is the last message, what customizations were made to your system. rpm -qa "*selinux*" semanage export
(In reply to Zdenek Pytela from comment #34) > Christian, > > Could you please share more details? At which phase the update hangs, what > is the last message, what customizations were made to your system. > > rpm -qa "*selinux*" > semanage export Hi Zdenek, No customizations from my side, standard f32 setup, I ran dnf upgrade --enablerepo=updates-testing. At the point where the three selinux packages updates scripts were running, it got stuck forever. Ctrl+C didn't work, I had to poweroff the machine (crazy loud fan noise) by using the power button. I restored a clonezilla system backup image from yesterday - and upgraded with --exclude=selinux* Regards, Christian
(In reply to Zdenek Pytela from comment #34) > Christian, > > Could you please share more details? At which phase the update hangs, what > is the last message, what customizations were made to your system. > > rpm -qa "*selinux*" > semanage export Additional information - currently installed : selinux-policy.noarch 3.14.5-32.fc32 selinux-policy-minimum.noarch 3.14.5-32.fc32 selinux-policy-targeted.noarch 3.14.5-32.fc32 Everything works as expected - except for this message after every reboot -> SELinux is preventing accounts-daemon from using the 'sys_nice' capabilities.
Christian, It likely means the update hasn't finished successfully so a previous package version is installed. The AVC denials will be gone once you succeed in updating to selinux-policy-3.14.5-37.fc32.noarch or newer.
(In reply to Zdenek Pytela from comment #37) > Christian, > > It likely means the update hasn't finished successfully so a previous > package version is installed. The AVC denials will be gone once you succeed > in updating to selinux-policy-3.14.5-37.fc32.noarch or newer. Seems you misunderstood Zdenek, or I didn't explain it good enough. This is what CURRENTLY is installed AFTER I restored the backup. :) The updates BREAK the system, and are NOT getting installed at all.
> No customizations from my side, standard f32 setup, I ran dnf upgrade > --enablerepo=updates-testing. > At the point where the three selinux packages updates scripts were running, > it got stuck forever. > Ctrl+C didn't work, I had to poweroff the machine (crazy loud fan noise) by > using the power button. > I restored a clonezilla system backup image from yesterday - and upgraded > with --exclude=selinux* The update will call "restorecon" and will run for quite some time. If you interrupted it, you probably caused the breakage.
*** Bug 1829892 has been marked as a duplicate of this bug. ***
(In reply to Ed Greshko from comment #39) > > > No customizations from my side, standard f32 setup, I ran dnf upgrade > > --enablerepo=updates-testing. > > At the point where the three selinux packages updates scripts were running, > > it got stuck forever. > > Ctrl+C didn't work, I had to poweroff the machine (crazy loud fan noise) by > > using the power button. > > I restored a clonezilla system backup image from yesterday - and upgraded > > with --exclude=selinux* > > The update will call "restorecon" and will run for quite some time. If you > interrupted it, you probably > caused the breakage. Don't think so, Ed ... I'm using Fedora/CentOS/RHEL since years - I let it run for about five minutes. That thingie ran ... and ran ... and ran ... and heated up my hardware. Finally I had to stop that ...
(In reply to Christian Labisch from comment #41) > Don't think so, Ed ... I'm using Fedora/CentOS/RHEL since years - I let it > run for about five minutes. > That thingie ran ... and ran ... and ran ... and heated up my hardware. > Finally I had to stop that ... OK. FWIW, it ran for more than 5 minutes on my HW which did prompt me to check to see what was taking so long. Unless you know what it was doing it is pretty hard to determine what went wrong. Possible to run again since you have a restore ability?
Similar problem has been detected: Upgraded from 31 to 32 and this showed up. There were no issues prior to upgrade hashmarkername: setroubleshoot kernel: 5.6.7-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-32.fc32.noarch reason: SELinux is preventing accounts-daemon from using the 'sys_nice' capabilities. type: libreport
(In reply to Ed Greshko from comment #42) > (In reply to Christian Labisch from comment #41) > > > Don't think so, Ed ... I'm using Fedora/CentOS/RHEL since years - I let it > > run for about five minutes. > > That thingie ran ... and ran ... and ran ... and heated up my hardware. > > Finally I had to stop that ... > > OK. FWIW, it ran for more than 5 minutes on my HW which did prompt me to > check to see what was taking so long. Unless you know what it was doing > it is pretty hard to determine what went wrong. > > Possible to run again since you have a restore ability? Okay Ed, as I tend to never exclude possible faults on my side, I followed your suggestion and tried it again. This is what happened : After about 10 (!!!) minutes the scripts indeed did finish, and I rebooted the system. A SELinux alert popped up and suggested to run touch /.autorelabel and reboot the system, which is what I did. Alert was SELinux is preventing (m-helper) from execute access on the file /usr/libexec/flatpak-system-helper. Now, guess what happened ? I was not able to login any more ... please believe me - those packages are BROKEN. Glad I created a new clonezilla system backup image before ... cc @Zdenek : Please do not push it to stable !
> Glad I created a new clonezilla system backup image before ... cc @Zdenek : > Please do not push it to stable ! Interesting. I ran the upgrade on another system with much older HW. time dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-3ffe9fdf42 and real 43m32.234s user 39m19.987s sys 2m0.615s I received no notice of a need to relabel. And everything works fine. I will try to relabel a VM later today even if it doesn't prompt for a relabel. egreshko@acer ~]$ ls -Z /usr/libexec/flatpak-system-helper system_u:object_r:flatpak_helper_exec_t:s0 /usr/libexec/flatpak-system-helper Note: It isn't a question of belief. Just the elimination of other possibilities. I wouldn't have suggested running it again had you not had a way to restore.
Similar problem has been detected: Reloading firewall from Options menu in firewall-config GUI hashmarkername: setroubleshoot kernel: 5.6.7-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-32.fc32.noarch reason: SELinux is preventing firewalld from using the 'sys_nice' capabilities. type: libreport
FWIW, I updated 1 bare-metal systems and 3 VM's. They have a mixture of desktops. I then issued "fixfiles onboot". All systems relabeled in between 3 and 8 minutes and booted to the login screen.
Similar problem has been detected: after upgrade F29>32 hashmarkername: setroubleshoot kernel: 5.6.7-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-32.fc32.noarch reason: SELinux is preventing accounts-daemon from using the 'sys_nice' capabilities. type: libreport
Similar problem has been detected: After unlocking the display, I got a few SELinux notifications, including this one and the one reported in bug #1811407 Maybe related to bug #1811407 hashmarkername: setroubleshoot kernel: 5.6.7-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-32.fc32.noarch reason: SELinux is preventing dnssec-trigger- from using the 'sys_nice' capabilities. type: libreport
Similar problem has been detected: Just upgraded from Fedora 30 to Fedora 32. This alert was shown on a reboot. I've done "fixfiles -F onboot; reboot" but it did not fix this problem. hashmarkername: setroubleshoot kernel: 5.6.8-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-32.fc32.noarch reason: SELinux is preventing accounts-daemon from using the 'sys_nice' capabilities. type: libreport
Version 3.14.5-37 will cause the system to become unusable. DO NOT UPDATE! See https://bugzilla.redhat.com/show_bug.cgi?id=1830029#c2.
Updated from the command line from Fedora MATE 31 to Fedora MATE 32. Hit this bug as well after boot: SELinux is preventing accounts-daemon from using the sys_nice capability. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that accounts-daemon should have the sys_nice capability 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 'accounts-daemon' --raw | audit2allow -M my-accountsdaemon # semodule -X 300 -i my-accountsdaemon.pp Additional Information: Source Context system_u:system_r:accountsd_t:s0 Target Context system_u:system_r:accountsd_t:s0 Target Objects Unknown [ capability ] Source accounts-daemon Source Path accounts-daemon Port <Unknown> Host mythal Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-3.14.5-32.fc32.noarch Local Policy RPM selinux-policy-targeted-3.14.5-32.fc32.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name mythal Platform Linux mythal 5.6.8-300.fc32.x86_64 #1 SMP Wed Apr 29 19:01:34 UTC 2020 x86_64 x86_64 Alert Count 2 First Seen 2020-05-03 01:07:28 BST Last Seen 2020-05-03 10:03:47 BST Local ID efb7453b-1243-4375-ab7d-cf2a88040a6d Raw Audit Messages type=AVC msg=audit(1588496627.497:149): avc: denied { sys_nice } for pid=1053 comm="accounts-daemon" capability=23 scontext=system_u:system_r:accountsd_t:s0 tcontext=system_u:system_r:accountsd_t:s0 tclass=capability permissive=0 Hash: accounts-daemon,accountsd_t,accountsd_t,capability,sys_nice
*** Bug 1830796 has been marked as a duplicate of this bug. ***
Similar problem has been detected: Like others, I upgraded to F32, updated everything to what was in updates-testing and ran a relabel. hashmarkername: setroubleshoot kernel: 5.6.8-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-32.fc32.noarch reason: SELinux is preventing accounts-daemon from using the 'sys_nice' capabilities. type: libreport
FEDORA-2020-a6cd8de2ed has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-a6cd8de2ed
Although the scripts needed more than five minutes to complete, no error was reported. After rebooting the system, no SELinux alerts appeared, it seems this version is okay.
Similar problem has been detected: Happens when updating to testing hashmarkername: setroubleshoot kernel: 5.6.8-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-32.fc32.noarch reason: SELinux is preventing firewalld from using the 'sys_nice' capabilities. type: libreport
FEDORA-2020-a6cd8de2ed has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
Similar problem has been detected: Clean Fedora Xfce 32 live iso hashmarkername: setroubleshoot kernel: 5.6.6-300.fc32.x86_64 package: selinux-policy-3.14.5-32.fc32.noarch reason: SELinux is preventing accounts-daemon from using the 'sys_nice' capabilities. type: libreport
*** Bug 1795524 has been marked as a duplicate of this bug. ***
*** Bug 1831327 has been marked as a duplicate of this bug. ***
Similar problem has been detected: Happens when I start Firefox for the first time after starting the PC. hashmarkername: setroubleshoot kernel: 5.6.8-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-32.fc32.noarch reason: SELinux is preventing pcscd from using the 'sys_nice' capabilities. type: libreport
Moving the fedora_prioritized_bug? flag from bug 1795524 in case this bug gets reopened as agreed in today's Fedora Prioritized Bugs meeting: https://meetbot.fedoraproject.org/fedora-meeting/2020-05-06/fedora_prioritized_bugs_and_issues.2020-05-06-15.00.log.html#l-42 (disabling email on this comment since the bug is already closed)
Similar problem has been detected: Happening after upgrade to Fedora 32 from 31 hashmarkername: setroubleshoot kernel: 5.6.8-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-32.fc32.noarch reason: SELinux is preventing /usr/bin/python3.8 from using the 'sys_nice' capabilities. type: libreport
Similar problem has been detected: Happening after upgrade to Fedora 32 from 31 hashmarkername: setroubleshoot kernel: 5.6.8-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-32.fc32.noarch reason: SELinux is preventing /usr/sbin/pcscd from using the 'sys_nice' capabilities. type: libreport
Had the same problem on Fedora MATE 32 post upgrade. Got resolved by upddated to selinux-policy-3.14.5-38.fc32. Update script took several minutes to complete.
Similar problem has been detected: Its happen during the test run the pop up come up that this daemon try to connect the aforesaid issue, (sys_nice' capabilities) hashmarkername: setroubleshoot kernel: 5.6.6-300.fc32.x86_64 package: selinux-policy-3.14.5-32.fc32.noarch reason: SELinux is preventing pcscd from using the 'sys_nice' capabilities. type: libreport
Similar problem has been detected: Clean install of Fedora 32 Cinnamon. Error appears right after cinnamon session start. hashmarkername: setroubleshoot kernel: 5.6.6-300.fc32.x86_64 package: selinux-policy-3.14.5-32.fc32.noarch reason: SELinux is preventing pcscd from using the 'sys_nice' capabilities. type: libreport
With the selinux-policy-3.14.5-36 and newer all AVCs like this are dontaudited. If you run into some similar ones, please file a new bugzilla. The current package version is 3.14.5-40.
*** Bug 1829513 has been marked as a duplicate of this bug. ***