Bug 1787038

Summary: SELinux is preventing systemd from using the 'setsched' accesses on a process.
Product: [Fedora] Fedora Reporter: Andre Costa <andcosta>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 31CC: dwalsh, lvrabec, mgrepl, msekleta, plautrba, zpytela
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:9a98407eecb48fa7206ff789066087f43684add8ab8b03a2961679008393de06;VARIANT_ID=workstation;
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-31 10:52:33 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 Andre Costa 2019-12-30 14:18:07 UTC
Description of problem:
Everytime I tried to start a VM either using virsh start <domain> or using VMM gui tool.
Also working with podman starting containers using local directories for volume binds.
SELinux is preventing systemd from using the 'setsched' accesses on a process.

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

If you believe that systemd should be allowed setsched access on processes labeled virtd_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 'systemd' --raw | audit2allow -M my-systemd
# semodule -X 300 -i my-systemd.pp

Additional Information:
Source Context                system_u:system_r:init_t:s0
Target Context                system_u:system_r:virtd_t:s0-s0:c0.c1023
Target Objects                Unknown [ process ]
Source                        systemd
Source Path                   systemd
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
Policy RPM                    <Unknown>
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 5.3.16-300.fc31.x86_64 #1 SMP Fri
                              Dec 13 17:59:04 UTC 2019 x86_64 x86_64
Alert Count                   3
First Seen                    2019-12-30 14:53:23 CET
Last Seen                     2019-12-30 15:05:45 CET
Local ID                      cf2a5796-2ea6-4f7b-be19-fd6f2336e002

Raw Audit Messages
type=AVC msg=audit(1577714745.43:1142): avc:  denied  { setsched } for  pid=1 comm="systemd" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:virtd_t:s0-s0:c0.c1023 tclass=process permissive=0


Hash: systemd,init_t,virtd_t,process,setsched


Additional info:
component:      selinux-policy
reporter:       libreport-2.11.3
hashmarkername: setroubleshoot
kernel:         5.3.16-300.fc31.x86_64
type:           libreport

Potential duplicate: bug 1777422

Comment 1 Lukas Vrabec 2020-01-10 16:26:48 UTC
Hi Michal, 

Is this expected? Could systemd modify scheduling of another processes? 

Thanks,
Lukas.

Comment 2 Fedora Admin XMLRPC Client 2020-01-23 16:24:23 UTC
This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

Comment 3 Michal Sekletar 2020-02-05 11:40:38 UTC
(In reply to Lukas Vrabec from comment #1)
> Hi Michal, 
> 
> Is this expected? Could systemd modify scheduling of another processes? 

I don't think this is about setting scheduling. My guess is that AVC was caused by changing CPU set cgroup settings as that also seems to call security_task_setscheduler() which in turn calls LSM setsched hook. Cgroup settings can be changed at runtime by systemd.

> 
> Thanks,
> Lukas.

Comment 4 Zdenek Pytela 2020-02-05 17:26:06 UTC
Andre,

Apart from the denial, do you also see any problem with the vms or containers?

Comment 5 Zdenek Pytela 2020-03-31 10:52:33 UTC
I've just checked the issue was addressed when resolving bz#1778088.

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