Bug 2105038
| Summary: | SELinux prevents the stalld process from using the getsched syscall | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Zdenek Pytela <zpytela> |
| Component: | selinux-policy | Assignee: | Nikola Knazekova <nknazeko> |
| Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9.1 | CC: | bhu, cyin, daolivei, jkacur, lleshchi, lvrabec, mmalik, mstowell, nknazeko, shichen, ssekidde, williams |
| Target Milestone: | rc | Keywords: | AutoVerified, Triaged |
| Target Release: | 9.1 | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-11-15 11:13:54 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Zdenek Pytela
2022-07-07 18:22:55 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()? 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()? Hi John - perhaps you could also review comment #6? BZ is still pending input. TIA 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. (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 I think this is related to this https://bugzilla.redhat.com/show_bug.cgi?id=2112366 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 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
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 The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days |