RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2105038 - SELinux prevents the stalld process from using the getsched syscall
Summary: SELinux prevents the stalld process from using the getsched syscall
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: selinux-policy
Version: 9.1
Hardware: Unspecified
OS: Linux
medium
medium
Target Milestone: rc
: 9.1
Assignee: Nikola Knazekova
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-07-07 18:22 UTC by Zdenek Pytela
Modified: 2023-09-18 04:41 UTC (History)
12 users (show)

Fixed In Version: selinux-policy-34.1.41-1.el9
Doc Type: Bug Fix
Doc Text:
Cause: Missing policy rules in stalld. Stalld needs to have full access to sched_getattr() or sched_setattr() to any type of "program" (daemon, kernel threads, user commands... etc) Consequence: SELinux is preventing stalld to getsched unconfined_t Fix: Allow stalld get and set scheduling policy of all domains. Result: No AVC
Clone Of:
Environment:
Last Closed: 2022-11-15 11:13:54 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 2096776 1 None None None 2023-10-24 13:47:13 UTC
Red Hat Issue Tracker RHELPLAN-127255 0 None None None 2022-07-07 18:31:49 UTC
Red Hat Product Errata RHBA-2022:8283 0 None None None 2022-11-15 11:14:02 UTC

Description Zdenek Pytela 2022-07-07 18:22:55 UTC 
This bug was initially created as a copy of Bug #2096776

I am copying this bug because: 
Retest stalld with selinux-policy-34.1.37-1.el9.noarch, seems the "getsched" SELinux denial reproduced occasionally. 

Description of problem:
Job: https://beaker.engineering.redhat.com/recipes/12238724#tasks
log: https://beaker-archive.host.prod.eng.bos.redhat.com/beaker-logs/2022/07/67841/6784142/12238724/146988417/685536033/avc.log

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      33
selinux-policy-34.1.37-1.el9.noarch

Version-Release number of selected component (if applicable):
selinux-policy-34.1.37-1.el9

How reproducible:
 * occasionally

Actual results (enforcing mode):
----
type=PROCTITLE msg=audit(07/05/2022 14:16:11.905:93) : proctitle=/usr/bin/stalld --systemd -p 1000000000 -r 20000 -d 3 -t 30 --foreground --pidfile /run/stalld.pid
type=AVC msg=audit(07/05/2022 14:16:11.905:93) : avc:  denied  { getsched } for  pid=5252 comm=stalld scontext=system_u:system_r:stalld_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0
type=SYSCALL msg=audit(07/05/2022 14:16:11.905:93) : arch=x86_64 syscall=sched_getattr success=no exit=EACCES(Permission denied) a0=0x15e1 a1=0x7ffd9da847d0 a2=0x30 a3=0x0 items=0 ppid=1 pid=5252 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=stalld exe=/usr/bin/stalld subj=system_u:system_r:stalld_t:s0 key=(null)
----

Expected results:
 * no SELinux denials

Additional info:
And here is the stalld test job with "setenforce 0", no other SELinux denials
https://beaker.engineering.redhat.com/jobs/6787577
Comment 1 Zdenek Pytela 2022-07-07 18:38:20 UTC 
Clark,

The stalld service is SELinux confined in RHEL 9.1. So far, we found it requires the sys_nice capability, the setsched permission for self, and setsched and getsched for kernel threads all of which were allowed.

As reported in this bz, the service seems to request getsched on some process with the unconfined_t type which probably means a common process started from a commandline.
Is this reasonable and should it be allowed? What could possibly be other types of processes/services stalld can request sched_getattr() or sched_setattr()?
Comment 6 Zdenek Pytela 2022-07-26 14:51:53 UTC 
Daniel,

Do you happen to know the answer?

The stalld service is SELinux confined in RHEL 9.1. So far, we found it requires the sys_nice capability, the setsched permission for self, and setsched and getsched for kernel threads all of which were allowed.

As reported in this bz, the service seems to request getsched on some process with the unconfined_t type which probably means a common process started from a commandline.
Is this reasonable and should it be allowed? What could possibly be other types of processes/services stalld can request sched_getattr() or sched_setattr()?
Comment 7 Mike Stowell 2022-08-01 14:45:27 UTC 
Hi John - perhaps you could also review comment #6?  BZ is still pending input.  TIA
Comment 8 Zdenek Pytela 2022-08-05 18:53:37 UTC 
We need to understand the underlying problem first before addressing.
Retargeting to 9.2, but there still is some room to have it resolved in 9.1 as soon as the issue is clear.
Comment 9 John Kacur 2022-08-05 19:57:34 UTC 
(In reply to Mike Stowell from comment #7)
> Hi John - perhaps you could also review comment #6?  BZ is still pending
> input.  TIA

We're investigating
Comment 10 John Kacur 2022-08-09 15:31:01 UTC 
I think this is related to this https://bugzilla.redhat.com/show_bug.cgi?id=2112366
Comment 11 Daniel Bristot de Oliveira 2022-08-23 07:09:36 UTC 
Hi

I agree with John in comment #10.

Stalld needs to have full access to sched_getattr() or sched_setattr() to any type of "program" (daemon, kernel threads, user commands... etc).

-- Daniel
Comment 12 Nikola Knazekova 2022-08-25 11:36:58 UTC 
commit 1f82ca40a101681620a8f85a164f8f27c662eea3
Author: Nikola Knazekova <nknazeko>
Date:   Tue Aug 23 17:46:53 2022 +0200

    Allow stalld get and set scheduling policy of all domains.
    
    Stalld needs to have full access to sched_getattr() or sched_setattr()
    to any type of "program" (daemon, kernel threads, user commands... etc),
    which includes common process started from a commandline with unconfined_t type.
    
    Fixed: bz#2105038
Comment 24 errata-xmlrpc 2022-11-15 11:13:54 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:8283
Comment 25 Red Hat Bugzilla 2023-09-18 04:41:23 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days
Note You need to log in before you can comment on or make changes to this bug.