Created attachment 1655908 [details] failures from journal after booting with selinux in permissive mode Description of problem: Updated kernel to 5.5.0-0.rc6.git3.1.fc32.x86_64. Upon next boot, machine would not fully boot into Gnome. Booted with SELinux in "permissive" mode and worked fine. I have attached the failures in a separate text file. Version-Release number of selected component (if applicable): 5.5.0-0.rc6.git3.1.fc32.x86_64 How reproducible: Steps to Reproduce: 1. Update kernel to that in updates-testing 2. Reboot with SELinux in "enforcing" mode Additional info: See attached text file.
*** Bug 1794961 has been marked as a duplicate of this bug. ***
*** Bug 1794959 has been marked as a duplicate of this bug. ***
*** Bug 1794958 has been marked as a duplicate of this bug. ***
FYI: we are trying to nail down the issue to find the root cause. Appreciate any additional details. Might be related to changes in glib2.
Hi All, It looks like issue was introduced between glib2-2.63.3-1.fc32 and glib2-2.63.4-1.fc32. Based on the change log here[1], there are some scheduling issues/PRs. On SELinux side we see that processes using glib2 require new access to modify scheduling information of another process. Could you please look on it and decide if it's issue in glib2 library? Example of SELinux denial: type=AVC msg=audit(1579980626.534:291): avc: denied { setsched } for pid=1166 comm="colord" scontext=system_u:system_r:colord_t:s0 tcontext=system_u:system_r:colord_t:s0 tclass=process permissive=0 Thanks, Lukas.
Forgot to add link to [1]. [1] https://github.com/GNOME/glib/commit/b413c50dcd8e7d64b1e208e975b82c759c7f7659
*** Bug 1796714 has been marked as a duplicate of this bug. ***
Similar problem has been detected: It happens everytime whenever I start fedora32. hashmarkername: setroubleshoot kernel: 5.5.0-0.rc6.git3.1.fc32.x86_64 package: selinux-policy-3.14.5-21.fc32.noarch reason: SELinux is preventing accounts-daemon from using the 'setsched' accesses on a process. type: libreport
(In reply to Lukas Vrabec from comment #5) > Hi All, > > It looks like issue was introduced between glib2-2.63.3-1.fc32 and > glib2-2.63.4-1.fc32. Based on the change log here[1], there are some > scheduling issues/PRs. On SELinux side we see that processes using glib2 > require new access to modify scheduling information of another process. > > Could you please look on it and decide if it's issue in glib2 library? > > Example of SELinux denial: > type=AVC msg=audit(1579980626.534:291): avc: denied { setsched } for > pid=1166 comm="colord" scontext=system_u:system_r:colord_t:s0 > tcontext=system_u:system_r:colord_t:s0 tclass=process permissive=0 > > Thanks, > Lukas. Also type=AVC msg=audit(1580550127.984:64): avc: denied { sys_nice } for pid=454 comm="accounts-daemon" capability=23 scontext=system_u:system_r:accountsd_t:s0 tcontext=system_u:system_r:accountsd_t:s0 tclass=capability permissive=1
*** Bug 1795345 has been marked as a duplicate of this bug. ***
*** Bug 1797412 has been marked as a duplicate of this bug. ***
*** Bug 1797411 has been marked as a duplicate of this bug. ***
This should obviously be proposed as a Beta blocker, as 'system doesn't boot' violates lots of criteria :)
*** Bug 1797414 has been marked as a duplicate of this bug. ***
This is a dupe of #1795034.
It would help fix this problem if linux_thread_proxy() in glib/gthread-posix.c called g_warning() instead of g_error() if SYS_sched_setattr failed. Right now the only way I can see for scheduler attributes to be passed in is from GThreadPool's shared_thread_scheduler_settings, and I don't think failure to set those is a fatal error...
*** Bug 1795034 has been marked as a duplicate of this bug. ***
(In reply to Lukas Vrabec from comment #5) > Hi All, > > It looks like issue was introduced between glib2-2.63.3-1.fc32 and > glib2-2.63.4-1.fc32. Based on the change log here[1], there are some > scheduling issues/PRs. On SELinux side we see that processes using glib2 > require new access to modify scheduling information of another process. > > Could you please look on it and decide if it's issue in glib2 library? > > Example of SELinux denial: > type=AVC msg=audit(1579980626.534:291): avc: denied { setsched } for > pid=1166 comm="colord" scontext=system_u:system_r:colord_t:s0 > tcontext=system_u:system_r:colord_t:s0 tclass=process permissive=0 > > Thanks, > Lukas. Seems to be libglib related. From https://gitlab.gnome.org/GNOME/glib.git commit 8aeca4fa647bfd0f35c4a86b1e6ca6e955519ca5 Author: Sebastian Dröge <sebastian> Date: Tue Dec 24 15:33:30 2019 +0200 GThreadPool - Don't inherit thread priorities when creating new threads By default (on POSIX) we would be inheriting thread priorities from the thread that pushed a new task on non-exclusive thread pools and causes a new thread to be created. This can cause any non-exclusive thread pool to accidentally contain threads of different priorities, or e.g. threads with real-time priority. To prevent this, custom handling for setting the scheduler settings for Linux and Windows is added and as a fallback for other platforms a new thread is added that is responsible for spawning threads for non-exclusive thread pools. Fixes https://gitlab.gnome.org/GNOME/glib/issues/1834
Discussed at 2020-02-03 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2020-02-03/f32-blocker-review.2020-02-03-17.13.html . Accepted as a Beta blocker as a violation of all requirements under https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_installed_system_boot_behavior .
Description of problem: Message appears on boot to default Gnome desktop. Version-Release number of selected component: selinux-policy-3.14.5-23.fc32.noarch Additional info: reporter: libreport-2.11.3 hashmarkername: setroubleshoot kernel: 5.5.0-0.rc6.git3.1.fc32.x86_64 type: libreport
*** Bug 1801117 has been marked as a duplicate of this bug. ***
*** Bug 1801131 has been marked as a duplicate of this bug. ***
*** Bug 1801132 has been marked as a duplicate of this bug. ***
I've commented in https://gitlab.gnome.org/GNOME/glib/issues/1834#note_707192 that this change is causing fallout in Fedora
OK, so here's a summary of some discussion with glib upstream. The fallback missing (and making glib crash when SYS_sched_setattr isn't available) was indeed an oversight. There's a pending MR upstream to fix the fallback to not crash. However, the question remains, what should we do in Fedora? Should we allow apps access to SYS_sched_setattr, or continue blocking it? Here's what Sebastian Dröge from upstream thinks on that matter: "That depends on your policies, I guess. Without allowing the syscall you'd have additional overhead (an additional thread that is used only for spawning threads for non-exclusive thread-pools), with allowing the syscall you allow configuring the scheduler settings. Do you have any other scheduler related syscalls allowed already? The only reason for not allowing this one that I could imagine would be that you don't want applications to configure real-time scheduling policies for themselves unless explicitly allowed for an application. But AFAIU doing so requires special permissions/capabilities for the process anyway?" I don't know our SELinux policies at all to answer any of this. Would be nice to be able to avoid the overhead of spawning an extra thread. lvrabec, what do you think? Would it be possible to relax our SELinux policies to allow SYS_sched_setattr for apps, or is it unwanted for some other reasons?
There are already many allow rules for "setsched". And that is the permission needed to allow SYS_sched_setattr.
I have strong doubts about the usefulness of making things like this fail and causing random application crashes. But of course, glib should handle the syscall failing.
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32.
needinfo'ing Zdenek for the policy questions. But, Kalev, can we at least backport the glib fix for now? I would dearly like us to *at least* have all the bugs in F32 that are fixable fixed right now, so we can find and concentrate on bugs that we don't have fixes for yet.
Done; I've backported it to glib2-2.63.5-3.fc32 Would be really nice to be able to relax the policies though if possible as there's a performance overhead of spawning a new thread in the fallback code path.
*** Bug 1802423 has been marked as a duplicate of this bug. ***
I was able to make rawhide 32 boot to runlevel 3 text login and fix some things. It boots now, without Plymouth (which I had to remove). And I can run Gnome, Openbox, jwm, basically anything other than LXDE. https://bugzilla.redhat.com/show_bug.cgi?id=1801071 Relevant log entries. Wed Feb 05 2020 upgraded to fedora 32, rebooted Wed Feb 05 2020 Selinux hosed accounts.daemon, colord, and ModemManager Wed Feb 05 2020 rebooted to runlevel 3 kernel boot parameter Wed Feb 05 2020 logged in as root, started hosed services manually, ran `journalctl -xe` Wed Feb 05 2020 fixed errors with selinux by following suggestions Wed Feb 05 2020 LXDE unable to log in. Went to a virtual terminal and restored default xorg conf. Nothing. Wed Feb 05 2020 Wonder if tpm2-abrmd should be allowed setsched access on processes labeled tabrmd_t by default
Similar problem has been detected: f31 > f32 upgrade hashmarkername: setroubleshoot kernel: 5.6.0-0.rc1.git0.1.fc32.x86_64 package: selinux-policy-3.14.5-24.fc32.noarch reason: SELinux is preventing accounts-daemon from using the 'setsched' accesses on a process. type: libreport
Similar problem has been detected: f31 > f32 upgrade hashmarkername: setroubleshoot kernel: 5.6.0-0.rc1.git0.1.fc32.x86_64 package: selinux-policy-3.14.5-24.fc32.noarch reason: SELinux is preventing accounts-daemon from using the 'sys_nice' capabilities. type: libreport
Similar problem has been detected: f31 > f32 upgrade hashmarkername: setroubleshoot kernel: 5.6.0-0.rc1.git0.1.fc32.x86_64 package: selinux-policy-3.14.5-24.fc32.noarch reason: SELinux is preventing ModemManager from using the 'setsched' accesses on a process. type: libreport
*** Bug 1803511 has been marked as a duplicate of this bug. ***
Hi All, What is current state of on the glib side? If we decide to allow it on policy side, it means to allow it to all processes on the system, which looks to me too strong, I would really appreciate if it could be handled on glib side without doing so generic allow rules in SELinux policy. Thanks, Lukas.
(In reply to Lukas Vrabec from comment #37) > Hi All, > > What is current state of on the glib side? If we decide to allow it on > policy side, it means to allow it to all processes on the system, which > looks to me too strong, I would really appreciate if it could be handled on > glib side without doing so generic allow rules in SELinux policy. > > Thanks, > Lukas. You would still get SElinux violations with the proposed change, but the daemons won't crash. Maybe glib2 should be built with HAVE_SYS_SCHED_GETATTR being undefined for Fedora only. That is: patch out these lines from meson.build if cc.has_header_symbol('sys/syscall.h', 'SYS_sched_getattr') glib_conf.set('HAVE_SYS_SCHED_GETATTR', 1) endif
Hi Villy, I can "dont audit" the SELinux denial, which means that SELinux won't report it as a denial and daemons will be still working. What do you think about this? Thanks, Lukas.
I'd like to resolve the performance issue I mentioned above and avoid going through the glib fallback code path that spawns an additional thread. If the denials are just hidden then we still hit the fallback code and that has a performance impact. Would it be possible to enable setsched for Workstation-only? I don't see setsched access as an attack vector on desktop machines.
(In reply to Kalev Lember from comment #40) > I'd like to resolve the performance issue I mentioned above and avoid going > through the glib fallback code path that spawns an additional thread. If the > denials are just hidden then we still hit the fallback code and that has a > performance impact. > As far as I can see, the programs running in a user session will have the setsched permission anyway. Is there any magic environ variable I can set, so I can see if the program takes the fallback path or not? The strace is not really helpful here. > Would it be possible to enable setsched for Workstation-only? I don't see > setsched access as an attack vector on desktop machines. You could probably check one of the environment variables. If you see any of the XDG_??? varables, it is higly likely the program is running in a user session. For the system deamons there are hardly any thread spawning going on so the performance impact would likely not matter that much. There is also this issue which seems related. type=AVC msg=audit(1580550127.984:64): avc: denied { sys_nice } for pid=454 comm="accounts-daemon" capability=23 scontext=system_u:system_r:accountsd_t:s0 tcontext=system_u:system_r:accountsd_t:s0 tclass=capability permissive=1 That only occurs if SElinux allows the setsched operation. Perhaps that is something generated inside the kernel itself as part of the setsched call.
Kalev: I'd think we could at least put a 'allow this' policy in a package and ship that package only in Workstation, or something like that. Lukas, could you explicitly answer the questions in comment #25, at least?
Since the fallback path was fixed this is no longer really a release blocker. I'll leave the bug open for the discussion of whether/how to relax the SELinux policy so we don't hit the fallback path at all, but I'm dropping the blocker metadata on the grounds this is 'resolved' as far as the blocker process goes.
(In reply to Kalev Lember from comment #25) > OK, so here's a summary of some discussion with glib upstream. The fallback > missing (and making glib crash when SYS_sched_setattr isn't available) was > indeed an oversight. There's a pending MR upstream to fix the fallback to > not crash. > > However, the question remains, what should we do in Fedora? Should we allow > apps access to SYS_sched_setattr, or continue blocking it? Here's what > Sebastian Dröge from upstream thinks on that matter: > > "That depends on your policies, I guess. Without allowing the syscall you'd > have additional overhead (an additional thread that is used only for > spawning threads for non-exclusive thread-pools), with allowing the syscall > you allow configuring the scheduler settings. > Do you have any other scheduler related syscalls allowed already? > The only reason for not allowing this one that I could imagine would be that > you don't want applications to configure real-time scheduling policies for > themselves unless explicitly allowed for an application. But AFAIU doing so > requires special permissions/capabilities for the process anyway?" > > I don't know our SELinux policies at all to answer any of this. Would be > nice to be able to avoid the overhead of spawning an extra thread. lvrabec, > what do you think? Would it be possible to relax our SELinux policies to > allow SYS_sched_setattr for apps, or is it unwanted for some other reasons? The main problem is that glib is library and we need to allow these two capabilities to all policies on system. So the rules will be too generic. With the allow rule all these actions will be allowed: CAP_SYS_NICE * Raise process nice value (nice(2), setpriority(2)) and change the nice value for arbi‐ trary processes; * set real-time scheduling policies for calling process, and set scheduling policies and priorities for arbitrary processes (sched_setscheduler(2), sched_setparam(2), sched_setattr(2)); * set CPU affinity for arbitrary processes (sched_setaffinity(2)); * set I/O scheduling class and priority for arbitrary processes (ioprio_set(2)); * apply migrate_pages(2) to arbitrary processes and allow processes to be migrated to arbitrary nodes; * apply move_pages(2) to arbitrary processes; * use the MPOL_MF_MOVE_ALL flag with mbind(2) and move_pages(2). Which I would like to avoid
I might suggest that the persistent failure with the nightly compose of 32 be resolved one way or the other ASAP. The failure is most dramatic and hugely corrosive to our most loyal user base. Word to the wise.
This bug has nothing to do with any compose failures, and is not affecting F32 in any visible way since the fallback path was fixed a week ago.
The symptoms are identical. And as this bug assumed so many similar bugs, you might want to reevalute.
(In reply to Villy Kruse from comment #41) > (In reply to Kalev Lember from comment #40) > > I'd like to resolve the performance issue I mentioned above and avoid going > > through the glib fallback code path that spawns an additional thread. If the > > denials are just hidden then we still hit the fallback code and that has a > > performance impact. > > > > As far as I can see, the programs running in a user session will have the > setsched permission anyway. > Is there any magic environ variable I can set, so I can see if the program > takes the fallback path or not? > The strace is not really helpful here. > > > Would it be possible to enable setsched for Workstation-only? I don't see > > setsched access as an attack vector on desktop machines. > > You could probably check one of the environment variables. If you see any > of the XDG_??? varables, it is higly likely the program is running in a user > session. > IIUC most of programs executed in user session runs as unconfined_t and thus are not affected. There is not reason to check XDG_??? variables > For the system deamons there are hardly any thread spawning going on so the > performance impact would likely not matter that much. > I got AVCs for two system daemons which call setsched pcscd and accounts-daemon. type=PROCTITLE msg=audit(02/20/2020 08:53:11.421:88) : proctitle=/usr/libexec/accounts-daemon type=SYSCALL msg=audit(02/20/2020 08:53:11.421:88) : arch=x86_64 syscall=sched_setattr success=no exit=EACCES(Permission denied) a0=0x4ab a1=0x55bac74bed90 a2=0x0 a3=0x7f6878ebea40 items=0 ppid=1 pid=1195 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=accounts-daemon exe=/usr/libexec/accounts-daemon subj=system_u:system_r:accountsd_t:s0 key=(null) type=AVC msg=audit(02/20/2020 08:53:11.421:88) : avc: denied { setsched } for pid=1195 comm=accounts-daemon scontext=system_u:system_r:accountsd_t:s0 tcontext=system_u:system_r:accountsd_t:s0 tclass=process permissive=0 type=AVC msg=audit(02/20/2020 08:53:11.421:88) : avc: denied { sys_nice } for pid=1195 comm=accounts-daemon capability=sys_nice scontext=system_u:system_r:accountsd_t:s0 tcontext=system_u:system_r:accountsd_t:s0 tclass=capability permissive=0 ---- type=PROCTITLE msg=audit(02/20/2020 08:53:14.597:126) : proctitle=/usr/sbin/pcscd --foreground --auto-exit type=SYSCALL msg=audit(02/20/2020 08:53:14.597:126) : arch=x86_64 syscall=sched_setattr success=no exit=EACCES(Permission denied) a0=0x55e a1=0x7fd5b400a400 a2=0x0 a3=0x7fd5b4000080 items=0 ppid=1 pid=1288 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=pcscd exe=/usr/sbin/pcscd subj=system_u:system_r:pcscd_t:s0 key=(null) type=AVC msg=audit(02/20/2020 08:53:14.597:126) : avc: denied { setsched } for pid=1288 comm=pcscd scontext=system_u:system_r:pcscd_t:s0 tcontext=system_u:system_r:pcscd_t:s0 tclass=process permissive=0 type=AVC msg=audit(02/20/2020 08:53:14.597:126) : avc: denied { sys_nice } for pid=1288 comm=pcscd capability=sys_nice scontext=system_u:system_r:pcscd_t:s0 tcontext=system_u:system_r:pcscd_t:s0 tclass=capability permissive=0 Sure it would be possible to add dontaudit SELinux rules. But some daemons might really need capability `sys_nice` in future and it is usually confusing to hit issue in enforcing mode (without AVC) and pass in permissive mode (again without AVC). Maybe there could be some way via env variables how to skip this feature for daemons. And all daemons which does not need such feature could set yet another env in systemd service file. (they will not generate AVC and will see sh$ systemctl cat accounts-daemon.service | grep Environment Environment=GVFS_DISABLE_FUSE=1 Environment=GIO_USE_VFS=local Environment=GVFS_REMOTE_VOLUME_MONITOR_IGNORE=1
(In reply to Lukas Slebodnik from comment #48) > (In reply to Villy Kruse from comment #41) > > (In reply to Kalev Lember from comment #40) > > > I'd like to resolve the performance issue I mentioned above and avoid going > > > through the glib fallback code path that spawns an additional thread. If the > > > denials are just hidden then we still hit the fallback code and that has a > > > performance impact. > > > > > > > As far as I can see, the programs running in a user session will have the > > setsched permission anyway. > > Is there any magic environ variable I can set, so I can see if the program > > takes the fallback path or not? > > The strace is not really helpful here. > > > > > Would it be possible to enable setsched for Workstation-only? I don't see > > > setsched access as an attack vector on desktop machines. > > > > You could probably check one of the environment variables. If you see any > > of the XDG_??? varables, it is higly likely the program is running in a user > > session. > > > > IIUC most of programs executed in user session runs as unconfined_t > and thus are not affected. There is not reason to check XDG_??? variables > No need to. That is just one way to determine if the program is running as a user program, thus unconfined_t. > > For the system deamons there are hardly any thread spawning going on so the > > performance impact would likely not matter that much. > > > > I got AVCs for two system daemons which call setsched > pcscd and accounts-daemon. > And also for boltd colord geoclue ModemManager tpm2-abrmd and possibly more, as reported by other users. > > Sure it would be possible to add dontaudit SELinux rules. > But some daemons might really need capability `sys_nice` in future and it is > usually confusing > to hit issue in enforcing mode (without AVC) and pass in permissive mode > (again without AVC). > Agree. Supposedly dontaudit can be temporarily disabled by "semodule -D". > Maybe there could be some way via env variables how to skip this feature for > daemons. > And all daemons which does not need such feature could set yet another env > in systemd service file. > (they will not generate AVC and will see > > sh$ systemctl cat accounts-daemon.service | grep Environment > Environment=GVFS_DISABLE_FUSE=1 > Environment=GIO_USE_VFS=local > Environment=GVFS_REMOTE_VOLUME_MONITOR_IGNORE=1 That is certainly possible. The various systemd service files just needs to set these variables as needed. From accounts-daemon.service [Service] Type=dbus BusName=org.freedesktop.Accounts ExecStart=/usr/libexec/accounts-daemon Environment=GVFS_DISABLE_FUSE=1 Environment=GIO_USE_VFS=local Environment=GVFS_REMOTE_VOLUME_MONITOR_IGNORE=1
Soo, what is the guidance, do we need to some changes in policy?
*** Bug 1805610 has been marked as a duplicate of this bug. ***
*** Bug 1805605 has been marked as a duplicate of this bug. ***
*** Bug 1805637 has been marked as a duplicate of this bug. ***
*** Bug 1805719 has been marked as a duplicate of this bug. ***
*** Bug 1806129 has been marked as a duplicate of this bug. ***
*** Bug 1806128 has been marked as a duplicate of this bug. ***
*** Bug 1806127 has been marked as a duplicate of this bug. ***
*** Bug 1806126 has been marked as a duplicate of this bug. ***
*** Bug 1806125 has been marked as a duplicate of this bug. ***
*** Bug 1806124 has been marked as a duplicate of this bug. ***
*** Bug 1806410 has been marked as a duplicate of this bug. ***
*** Bug 1806442 has been marked as a duplicate of this bug. ***
(In reply to Lukas Vrabec from comment #50) > Soo, what is the guidance, do we need to some changes in policy? I would rather prefer dontaudit than adding unnecesary capabilities but would be good to get a feedback from glib/desktop devs.
Also happens with `cockpit-ws` which definitely can run on non-workstation versions. We test on fedora-32-server. ``` audit: type=1400 audit(1582546912.933:276): avc: denied { setsched } for pid=15078 comm="cockpit-ws" scontext=system_u:system_r:cockpit_ws_t:s0 tcontext=system_u:system_r:cockpit_ws_t:s0 tclass=process permissive=0 ```
Similar problem has been detected: Attempting to boot to graphical logon screen. When it did not appear, went into terminal mode and ran startx hashmarkername: setroubleshoot kernel: 5.6.0-0.rc2.git0.1.fc32.x86_64 package: selinux-policy-3.14.5-28.fc32.noarch reason: SELinux is preventing colord from using the 'setsched' accesses on a process. type: libreport
(In reply to Lukas Slebodnik from comment #63) > (In reply to Lukas Vrabec from comment #50) > > Soo, what is the guidance, do we need to some changes in policy? > > I would rather prefer dontaudit than adding unnecesary capabilities but > would be good to get a feedback from glib/desktop devs. I don't understand the implications well enough, but let me find someone from glib/desktop side to answer this.
> I would rather prefer dontaudit than adding unnecesary capabilities but would be good to get a feedback from glib/desktop devs. What makes you think they are unnecessary ?
(In reply to Kalev Lember from comment #66) > (In reply to Lukas Slebodnik from comment #63) > > (In reply to Lukas Vrabec from comment #50) > > > Soo, what is the guidance, do we need to some changes in policy? > > > > I would rather prefer dontaudit than adding unnecesary capabilities but > > would be good to get a feedback from glib/desktop devs. > > I don't understand the implications well enough, but let me find someone > from glib/desktop side to answer this. The implications are as described in the commit message: If we can't suppress priority inheritance, we might end up with realtime threads in a threadpool, which is obviously not the intention. It will not do much harm, apart from the general harm of having more of the system run unnecessarily with realtime priorities. The intention here is not to elevate priorities, but to lower them.
> Maybe there could be some way via env variables how to skip this feature for daemons. > And all daemons which does not need such feature could set yet another env in systemd service file. > (they will not generate AVC and will see This would be a pretty awkward workaround for our inability to provide granular enough policy. All users of GLib want this 'feature' - it is never right to have threads with random priorities in the threadpool.
(In reply to Matthias Clasen from comment #68) > (In reply to Kalev Lember from comment #66) > > (In reply to Lukas Slebodnik from comment #63) > > > (In reply to Lukas Vrabec from comment #50) > > > > Soo, what is the guidance, do we need to some changes in policy? > > > > > > I would rather prefer dontaudit than adding unnecesary capabilities but > > > would be good to get a feedback from glib/desktop devs. > > > > I don't understand the implications well enough, but let me find someone > > from glib/desktop side to answer this. > > The implications are as described in the commit message: > > If we can't suppress priority inheritance, we might end up with realtime > threads in a threadpool, > which is obviously not the intention. It will not do much harm, apart from > the general harm > of having more of the system run unnecessarily with realtime priorities. > > The intention here is not to elevate priorities, but to lower them. I would say it is far from ideal design in glib. There should not be by default any realtime threads. and syscall setsched (which also needs capability SYS_NICE) should be used for raising process nice value/realtime priorities ... And not vice versa to decrease them due to wrong default. man capabilities says: CAP_SYS_NICE * Raise process nice value (nice(2), setpriority(2)) and change the nice value for arbitrary processes; * set real-time scheduling policies for calling process, and set scheduling policies and priorities for arbitrary processes (sched_setscheduler(2), sched_setparam(2), sched_setattr(2)); * set CPU affinity for arbitrary processes (sched_setaffin‐ ity(2)); * set I/O scheduling class and priority for arbitrary processes (ioprio_set(2)); * apply migrate_pages(2) to arbitrary processes and allow pro‐ cesses to be migrated to arbitrary nodes; * apply move_pages(2) to arbitrary processes; * use the MPOL_MF_MOVE_ALL flag with mbind(2) and move_pages(2).
(In reply to Matthias Clasen from comment #69) > > Maybe there could be some way via env variables how to skip this feature for daemons. > > And all daemons which does not need such feature could set yet another env in systemd service file. > > (they will not generate AVC and will see > > This would be a pretty awkward workaround for our inability to provide > granular enough policy. > > All users of GLib want this 'feature' - it is never right to have threads > with random priorities > in the threadpool. All users of GLib do not need realtime threads by default :-) I assume there is a use case for realtime threads in GLib but they should be opt-in and not default. And system services which really need them sdall be allowed to use CAP_SYS_NICE in SELinux policy.
This is not about glib creating realtime threads. This is about an app running with realtime (or otherwise elevated) priorities, and glib creating threads that inherit those priorities unless it uses setsched to prevent that.
(In reply to Matthias Clasen from comment #72) > This is not about glib creating realtime threads. This is about an app > running with realtime (or otherwise elevated) priorities, and glib creating > threads that inherit those priorities unless it uses setsched to prevent > that. That is correct. I just wonder if it is even possible for a program to get real-time priority without setattr permissions. We are not talking about user programs or gui programs such as Firefox or similar. They already have the setattr permission and don't have any problems with setattr. We are talking about system deamons which don't spawn threads other than the "gmain" and "gdbus" threads. As I can tell there are about 10 of these which don't have setattr permissions. The NetworkDaemon program already have the setattr permission, so that is why no SELinux violations was reported for this program. So I suggest to "allow" or -- if you are paranoid -- "dontaudit" the setattr for those programs mentioned in this bug report or the other reports marked a duplicates of this one. With "dontaudit" the programs will get yet another thread wich mostly have nothing to do, so that is not a big deal. Or with "allow" the prograns will run just the same way as before. Not doing any thing just result it more SELinux violation reports, which we don't need. There are plenty of other issues needing attention. I doubt that the glib team has any desire to change the library just to satisfy SELinux.
Okay, so I'll prepare patches do dontaudit this action for all system daemons.
commit deadfd15c2ae442cc0e204d315962f3aac88e9ba (HEAD -> rawhide, origin/rawhide) Author: Lukas Vrabec <lvrabec> Date: Fri Feb 28 17:02:37 2020 +0100 Dontaudit daemons to set and get scheduling policy/parameters Because of new change in glib library introduced here[1], all daemons using this library require setsched permission. This is too generic rule therefore it's dontuadited. Library call will fallback if the permission is not allowed so daemon will not crash. For more info please see rhbz#1795524 [1] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1325
We've repeatedly requested "allow" rather than "dontaudit". Doesn't it seem pretty bad if having selinux enabled causes half the processes on your system to use an extra long-running thread? That's *not* a good look for selinux.
(In reply to Michael Catanzaro from comment #76) > We've repeatedly requested "allow" rather than "dontaudit". Doesn't it seem > pretty bad if having selinux enabled causes half the processes on your > system to use an extra long-running thread? That's *not* a good look for > selinux. It is not nearly as bad as that. I would guestimate there are about 10 or so programs which are affected, and of these, the extra thread doesn't do anything at all. But you could count the number of affected programs on your own system.
Only 10? Doesn't this affect everything that uses GThreadPool...?
(In reply to Michael Catanzaro from comment #78) > Only 10? Doesn't this affect everything that uses GThreadPool...? Only those that don't already have permission for setsched. If you boot up Fedora 32 and then run as superuser audit2allow -b you would get an idea of how many there really are. It is known that these have issues. ModemManager accounts-daemon boltd colord geoclue pcscd tpm2-abrmd cockpit_ws_t
I think you're only looking at daemons. Basically every desktop application will also be affected, yes?
(In reply to Michael Catanzaro from comment #80) > I think you're only looking at daemons. Basically every desktop application > will also be affected, yes? No. They all have setsched permission. Don't take my word for it, but set up a Fedora 32 and run a Gnome session and see. You'll get quite a few SELinux issues from daemons and none at all from any of the Gnome programs.
OK... so now, do we understand why the desktop apps are allowed to use setsched, but the daemons aren't? I sure don't.
(In reply to Michael Catanzaro from comment #82) > OK... so now, do we understand why the desktop apps are allowed to use > setsched, but the daemons aren't? I sure don't. Take it to the mailing list https://www.redhat.com/mailman/listinfo/fedora-selinux-list . Maybe someome there knows.
Guys, There is no generic allow rule saying that all daemons can call sched_setattr and I don't like idea to allow it for all daemons. Lukas.
Similar problem has been detected: I just upgraded to Fedora 32 and I'm spammed with these SELinux alerts right after boot. hashmarkername: setroubleshoot kernel: 5.6.0-0.rc3.git0.1.fc32.x86_64 package: selinux-policy-3.14.5-28.fc32.noarch reason: SELinux is preventing geoclue from using the 'setsched' accesses on a process. type: libreport
I haven't read the whole discussion. But I get bothered by setroubleshoot popups every minute or so, by different daemons trying to use setsched. How do we fix the issue? Does every daemon need to be adjusted, or is there a different way? We need to resolve this fast, or most people will simply uninstall setroubleshoot and we'll lose important source of bug reports.
We don't have setroubleshoot installed by default since https://pagure.io/fedora-workstation/issue/24. Are you installing it manually?
kparal: as of #c75 it seems a dontaudit rule for this is committed to git, so whenever that makes a package build you should stop getting alerts...
(In reply to Adam Williamson from comment #88) > kparal: as of #c75 it seems a dontaudit rule for this is committed to git, > so whenever that makes a package build you should stop getting alerts... So why is this already closed? Let's close it after a fix gets into stable updates. (Speaking mainly to Lukas Vrabec) (In reply to Michael Catanzaro from comment #87) > We don't have setroubleshoot installed by default since > https://pagure.io/fedora-workstation/issue/24. Are you installing it > manually? Yes, and I recommend all QA to do so, so that we can detect issues and report them. Also people upgrading their Fedoras will still have it installed. Btw, it's somewhat unfortunate that SELinux notifications can't be disabled in gnome-control-center (there's no such app listed), so you either need to disable all notifications or uninstall the app, if you don't want to see the constant popup spam. That's why I say we should fix this fast.
*** Bug 1811099 has been marked as a duplicate of this bug. ***
kparal: good point. I interpreted comment 84 as this bug isn't a bug and won't be fixed, maybe that's wrong? And if so, my comment in the colord bug is wrong. https://bugzilla.redhat.com/show_bug.cgi?id=1801087#c6
*** Bug 1801087 has been marked as a duplicate of this bug. ***
Adam, Kamil, I've just marked bug #1801087 as a duplicate of this bug. It was filed against colord, but there's nothing to be changed in colord. That bug was AcceptedBlocker. If it's possible to transfer that status, you might want to reopen this one for blocker tracking purposes.
(In reply to Michael Catanzaro from comment #93) > Adam, Kamil, I've just marked bug #1801087 as a duplicate of this bug. It > was filed against colord, but there's nothing to be changed in colord. That > bug was AcceptedBlocker. If it's possible to transfer that status, you might > want to reopen this one for blocker tracking purposes. Actually, we shouldn't need to transfer the blocker status because the abort should already be fixed since glib 2.63.4.
Hey Lukas, can you please explain whether this bug is supposed to be fixed or won't be fixed? We're confused about the resolution. If it should be fixed, in which NVR? And if it's not stable yet (I still see the issues), why is this closed as currentrelease? Thanks.
FEDORA-2020-fe9ad43e72 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-fe9ad43e72
Hi Kamil, Issue is fixed here: https://github.com/fedora-selinux/selinux-policy/commit/deadfd15c2ae442cc0e204d315962f3aac88e9ba I updated fix version field in this BZ and yes, you're right I forgot to create bodhi update. I'm sorry for that. Here is the update: https://bodhi.fedoraproject.org/updates/FEDORA-2020-fe9ad43e72 To fix it ASAP on your system please install these packages: https://koji.fedoraproject.org/koji/buildinfo?buildID=1472099 Also feel free to add karma(if it's working for you) to bodhi update to speed up the process to put this version of package to stable updates. :) Thanks, Lukas.
I have upgraded to selinux-policy-3.14.5-29.fc32.noarch, rebooted, deleted all reports from setroubleshoot gui, rebooted again, and still I see this immediately after reboot: "SELinux is preventing geoclue from using the setsched access on a process." Is it something that got missed?
Hi Kamil, Could you please attach output of: # ausearch -m AVC -ts boot Thanks, Lukas.
(In reply to Kamil Páral from comment #98) > I have upgraded to selinux-policy-3.14.5-29.fc32.noarch, rebooted, deleted > all reports from setroubleshoot gui, rebooted again, and still I see this > immediately after reboot: > "SELinux is preventing geoclue from using the setsched access on a process." > > Is it something that got missed? Did you also upgrade selinux-policy-targeted? That is the module coutaining the new rules.
Created attachment 1668738 [details] ausearch output > Did you also upgrade selinux-policy-targeted? That is the module coutaining the new rules. Yes I did. ausearch output is attached.
(In reply to Kamil Páral from comment #101) > Created attachment 1668738 [details] > ausearch output > > > Did you also upgrade selinux-policy-targeted? That is the module coutaining the new rules. > > Yes I did. ausearch output is attached. The "geoclue_t" is not included in the "typeattributeset" called "daemon". In other words. All deamons gets the dontaudit rule set for the setsched call. geoclue is not considered a daemon in the current SELinux rules. Therefore you still get avc reports for that process. The SELinux rules has gotten so complicated so it can be very hard to get everything right. You also get "sys_nice" for accounts-daemon, unless you are in enforcing mode.
Discussed during the 2020-03-09 blocker review meeting: [0] The decision to classify this bug as an "AcceptedFreezeException" was made as it seems there is no criteria violation. We do not install the component that shows AVCs as desktop notifications any more, so that criterion is not violated even though AVCs are occurring. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-03-09/f32-blocker-review.2020-03-09-16.01.txt
Discussed during the 2020-03-09 blocker review meeting: [0] The decision to classify this bug as a "RejectedBlocker" was made as it seems there is no criteria violation. We do not install the component that shows AVCs as desktop notifications any more, so that criterion is not violated even though AVCs are occurring. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-03-09/f32-blocker-review.2020-03-09-16.01.txt
(In reply to Villy Kruse from comment #102) > In other words. All deamons gets the dontaudit rule set for the setsched > call. geoclue is not considered a daemon in the current SELinux rules. > Therefore you still get avc reports for that process. Lukas, should I report a separate bug for this?
Moving back to selinux-policy maintainer. Zdenek, Please create rule also for geoclue, and we most probably we need to do it for all application types. Thanks, Lukas.
(In reply to Lukas Vrabec from comment #106) > Moving back to selinux-policy maintainer. > > Zdenek, > Please create rule also for geoclue, and we most probably we need to do it > for all application types. > > Thanks, > Lukas. geoclue is started as a daemon geoclue runs as a daemon gepclue is a daemon Why shouldn't geoclue_t not be a type of daemon according toe SELinux?
I've submitted a PR to address the issue: https://github.com/fedora-selinux/selinux-policy-contrib/pull/216
selinux-policy-3.14.5-29.fc32 has been pushed to the Fedora 32 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-fe9ad43e72
commit c3d0d5d22440dab2a210fb141f79e27848a1161c (HEAD -> rawhide, origin/rawhide, origin/HEAD) Author: Zdenek Pytela <zpytela> Date: Tue Mar 10 14:24:12 2020 +0100 Add init_daemon_domain() for geoclue_t Create geoclue_t domain with init_daemon_domain() interface in addition to existing application_domain(). Resolves: rhbz#1795524
Similar problem has been detected: I just saw this warning in Gnome Shell after I started my laptop. This is an updated Fedora 32. hashmarkername: setroubleshoot kernel: 5.6.0-0.rc4.git0.1.fc32.x86_64 package: selinux-policy-3.14.5-29.fc32.noarch reason: SELinux is preventing geoclue from using the 'setsched' accesses on a process. type: libreport
Marcus, Your issue should be gone with selinux-policy-3.14.5-30.fc32.noarch.
(In reply to Zdenek Pytela from comment #112) > Your issue should be gone with selinux-policy-3.14.5-30.fc32.noarch. I can confirm this, I no longer see geoclue alerts.
Similar problem has been detected: F32 beta upgrade triggered this. hashmarkername: setroubleshoot kernel: 5.6.0-0.rc5.git0.2.fc32.x86_64 package: selinux-policy-3.14.5-28.fc32.noarch reason: SELinux is preventing geoclue from using the 'setsched' accesses on a process. type: libreport
FEDORA-2020-ca2d9dda2d has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-ca2d9dda2d
Similar problem has been detected: Errors appeared on first boot after Fedora 32 beta workstation netinst netinstall in QEMU KVM virtual Machine guest on Fedora 31 Workstation Host hashmarkername: setroubleshoot kernel: 5.6.0-0.rc5.git0.2.fc32.x86_64 package: selinux-policy-3.14.5-28.fc32.noarch reason: SELinux is preventing ModemManager from using the 'setsched' accesses on a process. type: libreport
Similar problem has been detected: Errors appeared on first boot after Fedora 32 beta workstation netinst netinstall in QEMU KVM virtual Machine guest on Fedora 31 Workstation Host hashmarkername: setroubleshoot kernel: 5.6.0-0.rc5.git0.2.fc32.x86_64 package: selinux-policy-3.14.5-28.fc32.noarch reason: SELinux is preventing colord from using the 'setsched' accesses on a process. type: libreport
Similar problem has been detected: Errors appeared on first boot after Fedora 32 beta workstation netinst netinstall in QEMU KVM virtual Machine guest on Fedora 31 Workstation Host hashmarkername: setroubleshoot kernel: 5.6.0-0.rc5.git0.2.fc32.x86_64 package: selinux-policy-3.14.5-28.fc32.noarch reason: SELinux is preventing geoclue from using the 'setsched' accesses on a process. type: libreport
selinux-policy-3.14.5-31.fc32 has been pushed to the Fedora 32 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-ca2d9dda2d
*** Bug 1815313 has been marked as a duplicate of this bug. ***
*** Bug 1815315 has been marked as a duplicate of this bug. ***
Similar problem has been detected: I opened a flatpak app (Phoenics PlayOnLinux). hashmarkername: setroubleshoot kernel: 5.6.0-0.rc5.git0.2.fc32.x86_64 package: selinux-policy-3.14.5-31.fc32.noarch reason: SELinux is preventing pcscd from using the 'sys_nice' capabilities. type: libreport
FEDORA-2020-ca2d9dda2d 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 install of Fedora 32 Cinnamon spin. No idea what causes this, but it is here after every boot. hashmarkername: setroubleshoot kernel: 5.6.0-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: It's been happening since upgrade to F32 (KDE spin), also with selinux-policy-3.14.5-32.fc32.noarch. hashmarkername: setroubleshoot kernel: 5.6.2-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: 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 pcscd 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. Perhaps after opening Gnome session or after starting Gajim. hashmarkername: setroubleshoot kernel: 5.6.2-301.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
(In reply to Nicolas Berrehouc from comment #127) > Similar problem has been detected: > > F31 -> F32 Beta upgrade with dnf system-upgrade and system up to date. > Perhaps after opening Gnome session or after starting Gajim. Does "dnf system-upgrade" do a relabel on completion of the process? Does the problem go away if you do a "touch /.autorelabel; reboot"
(In reply to Peter Robinson from comment #128) > (In reply to Nicolas Berrehouc from comment #127) > > Similar problem has been detected: > > > > F31 -> F32 Beta upgrade with dnf system-upgrade and system up to date. > > Perhaps after opening Gnome session or after starting Gajim. > > Does "dnf system-upgrade" do a relabel on completion of the process? Does > the problem go away if you do a "touch /.autorelabel; reboot" I do not think a relabel was done during system-upgrade. But a relabel was done after SELinux alerts and that's why I sent that report.
Similar problem has been detected: I literally JUST installed the OS and this was the first error I got upon loading the GUI hashmarkername: setroubleshoot kernel: 5.6.2-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
Reopening due to above comments. It looks different to me, but setroubleshoot is putting the comments here, so....
The dontaudit rule that was added is literally only for setsched, it seems: https://github.com/fedora-selinux/selinux-policy/commit/deadfd15c2ae442cc0e204d315962f3aac88e9ba I guess it should also be for sys_nice?
Indeed, no more AVC with selinux-policy-3.14.5-36.fc32.noarch.
(In reply to Nicolas Berrehouc from comment #133) > Indeed, no more AVC with selinux-policy-3.14.5-36.fc32.noarch. Weird, it seems not to be include in that build https://bodhi.fedoraproject.org/updates/FEDORA-2020-090cee7608 .
This bugzilla was open for the setsched permission reported. It was resolved by dontauditing since selinux-policy-3.14.5-29.fc32. The sys_nice permission is dontaudited in selinux-policy-3.14.5-35.fc32 which received negative karma due to some problems with containers usage, work to resolve it is in progress. If there is a need to discuss sys_nice further or report outstanding issues, please continue in https://bugzilla.redhat.com/show_bug.cgi?id=1811407 Closing this bugzilla again.
Similar problem has been detected: Just linked up my VPN connection to work hashmarkername: setroubleshoot kernel: 5.7.0-0.rc1.git0.1.1.fc33.x86_64 package: selinux-policy-3.14.6-11.fc33.noarch reason: SELinux is preventing nm-openconnect- from using the 'setsched' accesses on a process. type: libreport
Mikhail, Can you post the complete AVC denial? It should really be fixed with 3.14.6-6.fc33. ausearch -i -m avc,user_avc -ts today
Created attachment 1678937 [details] ausearch -i -m avc,user_avc -ts today > Can you post the complete AVC denial? Yes. > It should really be fixed with 3.14.6-6.fc33. # rpm -qa | grep selinux-policy selinux-policy-targeted-3.14.6-11.fc33.noarch selinux-policy-3.14.6-11.fc33.noarch
Thank you for your quick response: allow accountsd_t self:capability sys_nice; allow rngd_t self:netlink_kobject_uevent_socket { bind create getattr setopt }; allow rngd_t udev_var_run_t:file { getattr open read }; these will be resolved with policy 3.14.6-12 allow svirt_t lvm_control_t:chr_file { read write }; a new one, qemu has been updated recently, bz#1824019 allow vpnc_t self:process setsched; vpnc is not a daemon so this is not dontaudited atm, bz#1817528
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 pcscd from using the 'sys_nice' capabilities. type: libreport
Similar problem has been detected: SELinux error came up when I was trying to access my system settings. As far as I can tell, it should allow me access without producing this error. hashmarkername: setroubleshoot kernel: 5.6.6-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
Similar problem has been detected: after upgrade to fedora 32 and the restart the problem start occuring. hashmarkername: setroubleshoot kernel: 5.6.6-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
Similar problem has been detected: I just installed Fedora 32 Cinnamon this morning. I was attempting to access a bookmark when the notification occurred. hashmarkername: setroubleshoot kernel: 5.6.6-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
Similar problem has been detected: Error appears after bootup and login to cinnamon desktop. hashmarkername: setroubleshoot kernel: 5.6.6-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
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 pcscd from using the 'sys_nice' capabilities. type: libreport
Similar problem has been detected: Firs boot after F31->F32 update hashmarkername: setroubleshoot kernel: 5.6.6-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
zdenek: can you please build a non-broken F32 update and send it out, so we don't get floods of the sys_nice denial for F32 users? thanks...
Similar problem has been detected: Fedora 32 updated, then started receiving frequent SELinux errors. This occurred when opening web browser (Vivaldi). hashmarkername: setroubleshoot kernel: 5.6.6-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
Adam, I created a non-broken build (actualy the builds are never broken) today morning. https://koji.fedoraproject.org/koji/buildinfo?buildID=1499300
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 pcscd from using the 'sys_nice' capabilities. type: libreport
Zdenek: what I meant by "not broken" is "doesn't contain the bugs that caused the last two updates to get a large amount of negative feedback in Bodhi".
Similar problem has been detected: Al iniciar Firefox me salto el error. hashmarkername: setroubleshoot kernel: 5.6.6-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
Similar problem has been detected: Updated Fedora 31 to 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 pcscd from using the 'sys_nice' capabilities. type: libreport
Similar problem has been detected: Every time when I open Mozilla Firefox hashmarkername: setroubleshoot kernel: 5.6.7-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
Similar problem has been detected: upgraded form 31 to 32 and this happened. had no errors 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 pcscd from using the 'sys_nice' capabilities. type: libreport
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 pcscd from using the 'sys_nice' capabilities. type: libreport
(In reply to Zdenek Pytela from comment #149) > Adam, I created a non-broken build (actualy the builds are never broken) > today morning. > https://koji.fedoraproject.org/koji/buildinfo?buildID=1499300 Please push a valid bodhi update. Reopening.
I updated to selinux-policy{,-targeted}-3.14.5-37.fc32 out of updates-testing and this problem no longer occurs.
Had the same issue (accounts-daemon attempted sys_nice). Just performed the update (#158) and got locked out. Boots to graphic login screen but can no longer login. Screen flickers, returns to login screen. Switching to terminal does not help. Even root can not login. Remote accessing the box is not possible (smb, ssh) probably not started for the same reason.
johan: Try booting with enforcing=0 or, if that doesn't work, selinux=0 .
Nominating for the Fedora Prioritized Bugs process: https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/
since the not-yet-fixed sys_nice denials are getting detected and reported against this bug, I figure it makes more sense to update the summary and keep it open than try to direct everyone who hits one of these to the 'new' bug.
Similar problem has been detected: I just restarted the system... hashmarkername: setroubleshoot kernel: 5.6.7-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
Similar problem has been detected: Started firefox and instantly got this error message. 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
Similar problem has been detected: 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 pcscd from using the 'sys_nice' capabilities. type: libreport
Similar problem has been detected: just booting the system 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
Similar problem has been detected: I have no idea what coused this issue. I had updated from WS 31 to 32 and this occurred on the first reboot. 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
Similar problem has been detected: Susedio despues de actualizar Fedora 31 a 32 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
Similar problem has been detected: The problem then arises when I boot the computer and start Firefox. 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
Similar problem has been detected: This alert is logged at each boot on a laptop with an SD card reader after upgrading to Fedora 32. 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
Similar problem has been detected: This error message appears whenever I start Firefox. 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
Similar problem has been detected: 1. Start Firefox 2. SELinux Alert is generated. This is 100% reproducible on F32 x86_64. hashmarkername: setroubleshoot kernel: 5.6.7-300.fc32.x86_64 reason: SELinux is preventing pcscd from using the 'sys_nice' capabilities. type: libreport
Similar problem has been detected: I don't know about how this error occured. hashmarkername: setroubleshoot kernel: 5.6.7-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
Same here (BR language) SELinux está impedindo que o pcscd use um recurso do sys_nice. ***** Plugin catchall (confiança 100.) sugere ****************************** Se você acredita nisso pcscd deve ter o sys_nice capacidade por padrão. Entãovocê deve informar que este é um erro. Você pode gerar um módulo de política local para permitir este acesso. Faça permitir este acesso por agora executando: # ausearch -c 'pcscd'--raw | audit2allow -M my-pcscd # semodule -X 300 -i my-pcscd.pp Informação adicional: Contexto de origem system_u:system_r:pcscd_t:s0 Contexto de destino system_u:system_r:pcscd_t:s0 Objetos de destino Desconhecido [ capability ] Origem pcscd Caminho da origem pcscd Porta <Desconhecido> Máquina localhost.localdomain Pacotes RPM de origem Pacotes RPM de destino 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 habilitado True Tipo de política targeted Modo reforçado Enforcing Nome da máquina localhost.localdomain Plataforma Linux localhost.localdomain 5.6.8-300.fc32.x86_64 #1 SMP Wed Apr 29 19:01:34 UTC 2020 x86_64 x86_64 Contador de alertas 5 Visto pela primeira vez em 2020-05-04 10:48:55 -03 Visto pela última vez em 2020-05-05 10:33:06 -03 ID local 88e65b86-361a-43e5-8d34-d2d65d604859 Mensagens de auditoria não processadas type=AVC msg=audit(1588685586.878:259): avc: denied { sys_nice } for pid=2799 comm="pcscd" capability=23 scontext=system_u:system_r:pcscd_t:s0 tcontext=system_u:system_r:pcscd_t:s0 tclass=capability permissive=0 Hash: pcscd,pcscd_t,pcscd_t,capability,sys_nice
Similar problem has been detected: I opened firefox when the alert appeared. 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
Similar problem has been detected: I just freshly installed Fedora 32 from the network installer (Everything), and upgraded then several SELinux warnings pop up 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
Oh, I remembered, I started Firefox before this warning pops up
Similar problem has been detected: I dont know how this issue was happen. 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
Similar problem has been detected: Clean Fedora Xfce 32 live iso event_log: 2020-05-06-12:22:00> fatal: HTTP POST to URL 'https://bugzilla.redhat.com/xmlrpc.cgi' failed. libcurl failed even to execute the HTTP transaction, explaining: Could not resolve host: bugzilla.redhat.com 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
Resolved with latest selinux-policy package update. *** This bug has been marked as a duplicate of bug 1811407 ***
Removing the prioritized bug flag and moving it to bug 1811407 as agreed in today's 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 (email notification for this comment disabled since the bug is already closed)
Bug #1811407 is a different issue.
Similar problem has been detected: on Live USB startup 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: After Fedora instllation first "dnf upgrade" done. 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: Au démarrage de la session. 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