Bug 1795524 - SELinux denials for 'setsched' and 'sys_nice' for various glib-based processes (force glib down a fallback path with performance implications)
Summary: SELinux denials for 'setsched' and 'sys_nice' for various glib-based processe...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 32
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
: 1794958 1794959 1794961 1795034 1795345 1796714 1797411 1797412 1797414 1801087 1801117 1801131 1801132 1802423 1803511 1805605 1805610 1805637 1805719 1806124 1806125 1806126 1806127 1806128 1806129 1806410 1806442 1811099 1815313 1815315 (view as bug list)
Depends On:
Blocks: IoT
TreeView+ depends on / blocked
 
Reported: 2020-01-28 08:32 UTC by Geoffrey Marr
Modified: 2020-10-12 13:04 UTC (History)
125 users (show)

Fixed In Version: selinux-policy-3.14.5-31.fc32
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-06 13:13:57 UTC
Type: Bug


Attachments (Terms of Use)
failures from journal after booting with selinux in permissive mode (2.50 KB, text/plain)
2020-01-28 08:32 UTC, Geoffrey Marr
no flags Details
ausearch output (54.94 KB, text/plain)
2020-03-09 18:49 UTC, Kamil Páral
no flags Details
ausearch -i -m avc,user_avc -ts today (5.10 KB, text/plain)
2020-04-15 07:14 UTC, Mikhail
no flags Details

Description Geoffrey Marr 2020-01-28 08:32:11 UTC
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.

Comment 1 Lukas Vrabec 2020-01-28 08:47:45 UTC
*** Bug 1794961 has been marked as a duplicate of this bug. ***

Comment 2 Lukas Vrabec 2020-01-28 08:48:01 UTC
*** Bug 1794959 has been marked as a duplicate of this bug. ***

Comment 3 Lukas Vrabec 2020-01-28 08:53:33 UTC
*** Bug 1794958 has been marked as a duplicate of this bug. ***

Comment 4 Zdenek Pytela 2020-01-29 12:04:42 UTC
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.

Comment 5 Lukas Vrabec 2020-01-29 12:50:57 UTC
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.

Comment 6 Lukas Vrabec 2020-01-29 12:52:07 UTC
Forgot to add link to [1]. 

[1] https://github.com/GNOME/glib/commit/b413c50dcd8e7d64b1e208e975b82c759c7f7659

Comment 7 Lukas Vrabec 2020-01-31 06:38:52 UTC
*** Bug 1796714 has been marked as a duplicate of this bug. ***

Comment 8 Villy Kruse 2020-02-01 09:38:11 UTC
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

Comment 9 Villy Kruse 2020-02-01 09:47:30 UTC
(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

Comment 10 Lukas Vrabec 2020-02-02 09:51:34 UTC
*** Bug 1795345 has been marked as a duplicate of this bug. ***

Comment 11 Zdenek Pytela 2020-02-03 08:58:04 UTC
*** Bug 1797412 has been marked as a duplicate of this bug. ***

Comment 12 Zdenek Pytela 2020-02-03 08:58:39 UTC
*** Bug 1797411 has been marked as a duplicate of this bug. ***

Comment 13 Adam Williamson 2020-02-03 18:05:16 UTC
This should obviously be proposed as a Beta blocker, as 'system doesn't boot' violates lots of criteria :)

Comment 14 Lukas Vrabec 2020-02-04 09:38:44 UTC
*** Bug 1797414 has been marked as a duplicate of this bug. ***

Comment 15 Elliot Lee 2020-02-04 23:11:31 UTC
This is a dupe of #1795034.

Comment 16 Elliot Lee 2020-02-05 00:20:04 UTC
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...

Comment 17 Zdenek Pytela 2020-02-05 16:10:08 UTC
*** Bug 1795034 has been marked as a duplicate of this bug. ***

Comment 18 Villy Kruse 2020-02-06 07:57:28 UTC
(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@centricular.com>
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

Comment 19 Adam Williamson 2020-02-06 21:48:07 UTC
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 .

Comment 20 Henry Kroll 2020-02-08 05:12:17 UTC
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

Comment 21 Zdenek Pytela 2020-02-10 11:16:43 UTC
*** Bug 1801117 has been marked as a duplicate of this bug. ***

Comment 22 Zdenek Pytela 2020-02-10 11:16:55 UTC
*** Bug 1801131 has been marked as a duplicate of this bug. ***

Comment 23 Zdenek Pytela 2020-02-10 11:17:15 UTC
*** Bug 1801132 has been marked as a duplicate of this bug. ***

Comment 24 Kalev Lember 2020-02-10 12:14:55 UTC
I've commented in https://gitlab.gnome.org/GNOME/glib/issues/1834#note_707192 that this change is causing fallout in Fedora

Comment 25 Kalev Lember 2020-02-11 07:48:32 UTC
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?

Comment 26 Villy Kruse 2020-02-11 09:27:38 UTC
There are already many allow rules for "setsched".  And that is the permission needed to allow SYS_sched_setattr.

Comment 27 Matthias Clasen 2020-02-11 14:03:26 UTC
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.

Comment 28 Ben Cotton 2020-02-11 16:30:48 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

Comment 29 Adam Williamson 2020-02-12 18:29:35 UTC
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.

Comment 30 Kalev Lember 2020-02-12 19:53:55 UTC
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.

Comment 31 Zdenek Pytela 2020-02-13 06:59:58 UTC
*** Bug 1802423 has been marked as a duplicate of this bug. ***

Comment 32 Henry Kroll 2020-02-13 09:10:29 UTC
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

Comment 33 Mai Ling 2020-02-13 19:34:12 UTC
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

Comment 34 Mai Ling 2020-02-13 19:35:03 UTC
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

Comment 35 Mai Ling 2020-02-13 19:35:40 UTC
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

Comment 36 Lukas Vrabec 2020-02-16 21:16:28 UTC
*** Bug 1803511 has been marked as a duplicate of this bug. ***

Comment 37 Lukas Vrabec 2020-02-16 21:20:14 UTC
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.

Comment 38 Villy Kruse 2020-02-17 06:45:16 UTC
(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

Comment 39 Lukas Vrabec 2020-02-17 10:58:26 UTC
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.

Comment 40 Kalev Lember 2020-02-17 12:14:10 UTC
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.

Comment 41 Villy Kruse 2020-02-17 14:47:48 UTC
(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.

Comment 42 Adam Williamson 2020-02-17 16:00:44 UTC
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?

Comment 43 Adam Williamson 2020-02-17 17:59:31 UTC
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.

Comment 44 Lukas Vrabec 2020-02-17 18:32:01 UTC
(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

Comment 45 brian connolly 2020-02-20 00:12:20 UTC
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.

Comment 46 Adam Williamson 2020-02-20 00:14:29 UTC
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.

Comment 47 brian connolly 2020-02-20 00:30:34 UTC
The symptoms are identical.  And as this bug assumed so many similar bugs, you might want to reevalute.

Comment 48 Lukas Slebodnik 2020-02-20 10:15:01 UTC
(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

Comment 49 Villy Kruse 2020-02-20 12:44:24 UTC
(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

Comment 50 Lukas Vrabec 2020-02-20 12:51:42 UTC
Soo, what is the guidance, do we need to some changes in policy?

Comment 51 Lukas Vrabec 2020-02-21 08:17:06 UTC
*** Bug 1805610 has been marked as a duplicate of this bug. ***

Comment 52 Lukas Vrabec 2020-02-21 08:17:13 UTC
*** Bug 1805605 has been marked as a duplicate of this bug. ***

Comment 53 Lukas Vrabec 2020-02-21 09:32:59 UTC
*** Bug 1805637 has been marked as a duplicate of this bug. ***

Comment 54 Lukas Vrabec 2020-02-21 16:01:43 UTC
*** Bug 1805719 has been marked as a duplicate of this bug. ***

Comment 55 Lukas Vrabec 2020-02-22 15:57:35 UTC
*** Bug 1806129 has been marked as a duplicate of this bug. ***

Comment 56 Lukas Vrabec 2020-02-22 15:57:40 UTC
*** Bug 1806128 has been marked as a duplicate of this bug. ***

Comment 57 Lukas Vrabec 2020-02-22 15:57:46 UTC
*** Bug 1806127 has been marked as a duplicate of this bug. ***

Comment 58 Lukas Vrabec 2020-02-22 15:57:53 UTC
*** Bug 1806126 has been marked as a duplicate of this bug. ***

Comment 59 Lukas Vrabec 2020-02-22 15:57:58 UTC
*** Bug 1806125 has been marked as a duplicate of this bug. ***

Comment 60 Lukas Vrabec 2020-02-22 15:58:03 UTC
*** Bug 1806124 has been marked as a duplicate of this bug. ***

Comment 61 Lukas Vrabec 2020-02-24 08:50:55 UTC
*** Bug 1806410 has been marked as a duplicate of this bug. ***

Comment 62 Lukas Vrabec 2020-02-24 09:18:37 UTC
*** Bug 1806442 has been marked as a duplicate of this bug. ***

Comment 63 Lukas Slebodnik 2020-02-24 09:39:39 UTC
(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.

Comment 64 Matej Marušák 2020-02-24 17:35:10 UTC
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
```

Comment 65 Leslie Satenstein 2020-02-25 00:56:25 UTC
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

Comment 66 Kalev Lember 2020-02-26 10:11:58 UTC
(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.

Comment 67 Matthias Clasen 2020-02-26 14:36:39 UTC
> 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 ?

Comment 68 Matthias Clasen 2020-02-26 15:14:45 UTC
(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.

Comment 69 Matthias Clasen 2020-02-26 15:24:42 UTC
> 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.

Comment 70 Lukas Slebodnik 2020-02-27 09:44:15 UTC
(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).

Comment 71 Lukas Slebodnik 2020-02-27 09:48:41 UTC
(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.

Comment 72 Matthias Clasen 2020-02-27 13:25:21 UTC
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.

Comment 73 Villy Kruse 2020-02-27 14:17:57 UTC
(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.

Comment 74 Lukas Vrabec 2020-02-28 15:56:06 UTC
Okay, so I'll prepare patches do dontaudit this action for all system daemons.

Comment 75 Lukas Vrabec 2020-02-28 16:10:10 UTC
commit deadfd15c2ae442cc0e204d315962f3aac88e9ba (HEAD -> rawhide, origin/rawhide)
Author: Lukas Vrabec <lvrabec@redhat.com>
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

Comment 76 Michael Catanzaro 2020-03-01 18:09:37 UTC
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.

Comment 77 Villy Kruse 2020-03-01 19:17:22 UTC
(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.

Comment 78 Michael Catanzaro 2020-03-02 16:07:04 UTC
Only 10? Doesn't this affect everything that uses GThreadPool...?

Comment 79 Villy Kruse 2020-03-02 17:34:01 UTC
(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

Comment 80 Michael Catanzaro 2020-03-02 17:54:53 UTC
I think you're only looking at daemons. Basically every desktop application will also be affected, yes?

Comment 81 Villy Kruse 2020-03-02 21:27:26 UTC
(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.

Comment 82 Michael Catanzaro 2020-03-02 23:09:12 UTC
OK... so now, do we understand why the desktop apps are allowed to use setsched, but the daemons aren't? I sure don't.

Comment 83 Villy Kruse 2020-03-03 05:56:41 UTC
(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.

Comment 84 Lukas Vrabec 2020-03-03 16:06:02 UTC
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.

Comment 85 Kamil Páral 2020-03-05 14:34:28 UTC
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

Comment 86 Kamil Páral 2020-03-05 14:57:02 UTC
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.

Comment 87 Michael Catanzaro 2020-03-05 18:16:11 UTC
We don't have setroubleshoot installed by default since https://pagure.io/fedora-workstation/issue/24. Are you installing it manually?

Comment 88 Adam Williamson 2020-03-05 20:45:04 UTC
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...

Comment 89 Kamil Páral 2020-03-06 09:42:23 UTC
(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.

Comment 90 Zdenek Pytela 2020-03-06 16:22:54 UTC
*** Bug 1811099 has been marked as a duplicate of this bug. ***

Comment 91 Chris Murphy 2020-03-06 18:17:24 UTC
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

Comment 92 Michael Catanzaro 2020-03-06 18:54:12 UTC
*** Bug 1801087 has been marked as a duplicate of this bug. ***

Comment 93 Michael Catanzaro 2020-03-06 18:56:16 UTC
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.

Comment 94 Michael Catanzaro 2020-03-06 18:58:05 UTC
(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.

Comment 95 Kamil Páral 2020-03-09 15:03:49 UTC
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.

Comment 96 Fedora Update System 2020-03-09 15:17:29 UTC
FEDORA-2020-fe9ad43e72 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-fe9ad43e72

Comment 97 Lukas Vrabec 2020-03-09 15:21:10 UTC
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.

Comment 98 Kamil Páral 2020-03-09 15:55:00 UTC
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?

Comment 99 Lukas Vrabec 2020-03-09 15:59:45 UTC
Hi Kamil, 

Could you please attach output of:

# ausearch -m AVC -ts boot 

Thanks,
Lukas.

Comment 100 Villy Kruse 2020-03-09 16:41:16 UTC
(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.

Comment 101 Kamil Páral 2020-03-09 18:49:07 UTC
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.

Comment 102 Villy Kruse 2020-03-09 19:38:33 UTC
(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.

Comment 103 Geoffrey Marr 2020-03-10 01:07:46 UTC
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

Comment 104 Geoffrey Marr 2020-03-10 01:09:12 UTC
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

Comment 105 Kamil Páral 2020-03-10 11:17:39 UTC
(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?

Comment 106 Lukas Vrabec 2020-03-10 11:43:56 UTC
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.

Comment 107 Villy Kruse 2020-03-10 12:27:57 UTC
(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?

Comment 108 Zdenek Pytela 2020-03-10 13:29:28 UTC
I've submitted a PR to address the issue:

https://github.com/fedora-selinux/selinux-policy-contrib/pull/216

Comment 109 Fedora Update System 2020-03-10 18:06:13 UTC
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

Comment 110 Lukas Vrabec 2020-03-12 15:16:45 UTC
commit c3d0d5d22440dab2a210fb141f79e27848a1161c (HEAD -> rawhide, origin/rawhide, origin/HEAD)
Author: Zdenek Pytela <zpytela@redhat.com>
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

Comment 111 Marcus Husar 2020-03-16 08:13:21 UTC
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

Comment 112 Zdenek Pytela 2020-03-16 12:48:10 UTC
Marcus,

Your issue should be gone with selinux-policy-3.14.5-30.fc32.noarch.

Comment 113 Kamil Páral 2020-03-17 13:37:56 UTC
(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.

Comment 114 Berend De Schouwer 2020-03-19 10:33:38 UTC
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

Comment 115 Fedora Update System 2020-03-19 11:19:31 UTC
FEDORA-2020-ca2d9dda2d has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-ca2d9dda2d

Comment 116 Angie 2020-03-20 00:42:27 UTC
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

Comment 117 Angie 2020-03-20 00:45:30 UTC
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

Comment 118 Angie 2020-03-20 00:46:03 UTC
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

Comment 119 Fedora Update System 2020-03-20 01:58:48 UTC
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

Comment 120 Zdenek Pytela 2020-03-20 07:26:18 UTC
*** Bug 1815313 has been marked as a duplicate of this bug. ***

Comment 121 Zdenek Pytela 2020-03-20 07:26:39 UTC
*** Bug 1815315 has been marked as a duplicate of this bug. ***

Comment 122 Martijn Kruiten 2020-03-20 08:50:53 UTC
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

Comment 123 Fedora Update System 2020-03-24 20:39:55 UTC
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.

Comment 124 Jared Busch 2020-04-04 04:10:36 UTC
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

Comment 125 ozeszty 2020-04-06 10:54:47 UTC
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

Comment 126 Tomas Toth 2020-04-06 12:02:48 UTC
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

Comment 127 Nicolas Berrehouc 2020-04-09 04:40:49 UTC
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

Comment 128 Peter Robinson 2020-04-09 08:30:14 UTC
(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"

Comment 129 Nicolas Berrehouc 2020-04-09 09:44:32 UTC
(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.

Comment 130 Rob Minick 2020-04-10 12:35:08 UTC
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

Comment 131 Michael Catanzaro 2020-04-10 20:46:18 UTC
Reopening due to above comments. It looks different to me, but setroubleshoot is putting the comments here, so....

Comment 132 Adam Williamson 2020-04-13 14:51:05 UTC
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?

Comment 133 Nicolas Berrehouc 2020-04-13 16:25:51 UTC
Indeed, no more AVC with selinux-policy-3.14.5-36.fc32.noarch.

Comment 134 Nicolas Berrehouc 2020-04-13 16:38:27 UTC
(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 .

Comment 135 Zdenek Pytela 2020-04-13 17:39:24 UTC
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.

Comment 136 Mikhail 2020-04-15 05:12:14 UTC
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

Comment 137 Zdenek Pytela 2020-04-15 07:07:46 UTC
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

Comment 138 Mikhail 2020-04-15 07:14:28 UTC
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

Comment 139 Zdenek Pytela 2020-04-15 07:20:28 UTC
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

Comment 140 Michael DePaulo 2020-04-15 14:11:02 UTC
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

Comment 141 mitchell.ota 2020-04-28 15:06:31 UTC
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

Comment 142 lessfoobar 2020-04-28 17:15:24 UTC
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

Comment 143 mister_t_stauss 2020-04-28 17:25:28 UTC
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

Comment 144 Eric Wick 2020-04-28 17:29:52 UTC
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

Comment 145 Bjoern Engels 2020-04-28 19:26:12 UTC
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

Comment 146 Milan Kerslager 2020-04-28 20:25:03 UTC
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

Comment 147 Adam Williamson 2020-04-28 23:45:38 UTC
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...

Comment 148 mitchell.ota 2020-04-29 00:43:05 UTC
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

Comment 149 Zdenek Pytela 2020-04-29 09:10:45 UTC
Adam, I created a non-broken build (actualy the builds are never broken) today morning.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1499300

Comment 150 Simon 2020-04-29 11:20:01 UTC
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

Comment 151 Adam Williamson 2020-04-29 14:55:52 UTC
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".

Comment 152 Kevin Camacena 2020-04-29 20:36:36 UTC
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

Comment 153 Кощеев 2020-04-30 06:56:06 UTC
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

Comment 154 Felipe Balotim 2020-04-30 13:34:13 UTC
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

Comment 155 Jared Busch 2020-04-30 15:55:57 UTC
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

Comment 156 Raphael Groner 2020-05-01 10:53:18 UTC
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

Comment 157 Raphael Groner 2020-05-01 10:56:24 UTC
(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.

Comment 158 Michael Hampton 2020-05-01 11:15:16 UTC
I updated to selinux-policy{,-targeted}-3.14.5-37.fc32 out of updates-testing and this problem no longer occurs.

Comment 159 johan 2020-05-01 13:48:30 UTC
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.

Comment 160 Adam Williamson 2020-05-01 17:14:23 UTC
johan: Try booting with enforcing=0 or, if that doesn't work, selinux=0 .

Comment 161 Ben Cotton 2020-05-01 18:01:49 UTC
Nominating for the Fedora Prioritized Bugs process:
https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/

Comment 162 Adam Williamson 2020-05-01 18:20:39 UTC
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.

Comment 163 Felipe 2020-05-01 18:29:48 UTC
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

Comment 164 Masoud 2020-05-03 07:30:03 UTC
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

Comment 165 Robert J. Devlin 2020-05-03 13:23:02 UTC
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

Comment 166 Ger van Dijck 2020-05-03 16:31:07 UTC
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

Comment 167 Jim 2020-05-03 22:27:42 UTC
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

Comment 168 Roberto Gonzalez 2020-05-04 08:00:50 UTC
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

Comment 169 fedora 2020-05-04 14:29:59 UTC
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

Comment 170 thedatum+bz 2020-05-04 21:59:41 UTC
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

Comment 171 fedora 2020-05-05 07:13:55 UTC
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

Comment 172 Prarit Bhargava 2020-05-05 10:05:41 UTC
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

Comment 173 Grzegorz 2020-05-05 13:19:33 UTC
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

Comment 174 Luiz Carlos Querido 2020-05-05 14:09:40 UTC
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

Comment 175 Jonathon Poppleton 2020-05-06 01:47:53 UTC
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

Comment 176 david.hu.2035 2020-05-06 02:56:28 UTC
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

Comment 177 david.hu.2035 2020-05-06 02:58:20 UTC
Oh, I remembered, I started Firefox before this warning pops up

Comment 178 Grzegorz 2020-05-06 10:39:12 UTC
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

Comment 179 Doaxan 2020-05-06 12:28:58 UTC
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

Comment 180 Zdenek Pytela 2020-05-06 13:13:57 UTC
Resolved with latest selinux-policy package update.

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

Comment 181 Ben Cotton 2020-05-06 18:48:04 UTC
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)

Comment 182 Michael Catanzaro 2020-05-30 18:43:56 UTC
Bug #1811407 is a different issue.

Comment 183 Rui Maia 2020-07-15 17:29:50 UTC
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

Comment 184 cc4948540@gmail.com 2020-07-23 00:14:47 UTC
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

Comment 185 gubouillon 2020-10-12 13:04:19 UTC
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


Note You need to log in before you can comment on or make changes to this bug.