Bug 1794961

Summary: SELinux is preventing colord from using the 'setsched' accesses on a process.
Product: [Fedora] Fedora Reporter: Matt Fagnani <matt.fagnani>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dwalsh, grepl.miroslav, lvrabec, mikhail.v.gavrilov, plautrba, vmojzis, youssef.m.sourani, zpytela
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:02c5045e927e704a12791f6cd7640a02dbe91058dece3820825b00742698acb3;
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-01-28 08:47:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Matt Fagnani 2020-01-25 20:29:49 UTC
Description of problem:
I ran sudo dnf upgrade --refresh on the Rawhide KDE Plasma spin on 2020-1-25. The upgrade included about ~300 rpms including glib2-2.63.4-1.fc32.x86_64, gcc-10.0.1-0.5.fc32.x86_64, sssd-2.2.2-5.fc32.x86_64, annobin-9.01-2.fc32.x86_64, binutils-2.33.1-12.fc32.x86_64, colord-1.4.4-3.fc32.x86_64, elfutils-0.178-8.fc32.x86_64. I rebooted. The plymouth output showed lines like 
Failed to start ModemManager 
Failed to start Accounts Service

The journal and audit logs had denials of ModemManager using setsched on a process with modemmanager_t possibly itself repeated many times. ModemManager restarted and was sent the trap signal. ModemManager crashed 9 times in total.

There were also denials of accounts-daemon using setsched and sysnice followed by accounts-daemon getting the trap signal and crashing once.
colord was denied setsched and crashed with the trap signal also. So the denials might be due to a change in a package that ModemManager, accounts-daemon, and colord were all using. glib2-2.63.4-1.fc32.x86_64 is in the traces of the crashing threads of each of them so glib might be involved. I'll submit the other denials and crashes separately and put the links here. The same denials and crashes happened on 2 consecutive boots.
SELinux is preventing colord from using the 'setsched' accesses on a process.

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

If you believe that colord should be allowed setsched access on processes labeled colord_t by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'colord' --raw | audit2allow -M my-colord
# semodule -X 300 -i my-colord.pp

Additional Information:
Source Context                system_u:system_r:colord_t:s0
Target Context                system_u:system_r:colord_t:s0
Target Objects                Unknown [ process ]
Source                        colord
Source Path                   colord
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.14.5-20.fc32.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 5.5.0-0.rc6.git3.1.fc32.x86_64 #1
                              SMP Fri Jan 17 18:29:51 UTC 2020 x86_64 x86_64
Alert Count                   1
First Seen                    2020-01-25 14:30:26 EST
Last Seen                     2020-01-25 14:30:26 EST
Local ID                      9aec0013-38cf-4938-be1b-f1493ba2ee39

Raw Audit Messages
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


Hash: colord,colord_t,colord_t,process,setsched

Version-Release number of selected component:
selinux-policy-3.14.5-20.fc32.noarch

Additional info:
component:      selinux-policy
reporter:       libreport-2.11.3
hashmarkername: setroubleshoot
kernel:         5.5.0-0.rc6.git3.1.fc32.x86_64
type:           libreport

Comment 1 Matt Fagnani 2020-01-26 06:56:37 UTC
I downgraded to glib2-2.63.3-1.fc32 from koji. No denials or crashes involving ModemManager, accounts-daemon, colord happened on the next 2 boots with glib2-2.63.3-1. I upgraded to glib2-2.63.4-1.fc32, and the denials and crashes started again on the next boot.

The accounts-daemon and colord crashes also had the error "Failed to set scheduler settings: Permission denied" in g_logv at ../glib/gmessages.c:1350 in glib2-2.63.4-1. The error message seems to start from frame 4 in linux_pthread_proxy at ../glib/gthread-posix.c:1238 in all the crashes which I reported in more detail at https://bugzilla.redhat.com/show_bug.cgi?id=1794964 This section appears to have been added in the commit 8aeca4fa "GThreadPool - Don't inherit thread priorities when creating new threads" included in glib 2.63.4 at https://gitlab.gnome.org/GNOME/glib/commit/8aeca4fa647bfd0f35c4a86b1e6ca6e955519ca5#note_686823

I ran setroubleshoot GUI's suggestions to allow the accesses
sudo ausearch -c 'ModemManager' --raw | audit2allow -M my-ModemManager
sudo semodule -X 300 -i my-ModemManager.pp
sudo ausearch -c 'accounts-daemon' --raw | audit2allow -M my-accountsdaemon
sudo semodule -X 300 -i my-accountsdaemon.pp
sudo ausearch -c 'colord' --raw | audit2allow -M my-colord
sudo semodule -X 300 -i my-colord.pp

No denials or crashes happened when booting after running those commands which added the following rules in the local policy modules.
allow modemmanager_t self:process setsched;
allow accountsd_t self:capability sys_nice;
allow accountsd_t self:process setsched;
allow colord_t self:process setsched;

I reported the accounts-daemon and ModemManager denials in more detail at https://bugzilla.redhat.com/show_bug.cgi?id=1794959 and https://bugzilla.redhat.com/show_bug.cgi?id=1794958

Comment 2 Mikhail 2020-01-26 15:02:33 UTC
Similar problem has been detected:

happens when I start virtual machine or build package in mock

hashmarkername: setroubleshoot
kernel:         5.5.0-0.rc7.git0.2.fc32.x86_64
package:        selinux-policy-3.14.5-20.fc32.noarch
reason:         SELinux is preventing colord from using the 'setsched' accesses on a process.
type:           libreport

Comment 3 Lukas Vrabec 2020-01-28 08:47:45 UTC

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