Commit to backport:
commit 56f9ffa1f88d756549c98da37684a2c836cb4103
Author: Patrik Koncity <pkoncity>
Date:   Tue Dec 21 12:02:10 2021 +0100

    Label new utility of NetworkManager nm-priv-helper

Thomas,

nm-priv-helper calls sched_setattr() requesting the setsched SELinux permission which currently is not allowed in RHEL 9, but the service does not fail:
----
type=PROCTITLE msg=audit(05/05/2022 07:42:49.698:317) : proctitle=/usr/libexec/nm-priv-helper 
type=SYSCALL msg=audit(05/05/2022 07:42:49.698:317) : arch=x86_64 syscall=sched_setattr success=yes exit=0 a0=0x11f7 a1=0x560ec44a4750 a2=0x0 a3=0x560ec44a4660 items=0 ppid=1 pid=4599 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=nm-priv-helper exe=/usr/libexec/nm-priv-helper subj=system_u:system_r:NetworkManager_priv_helper_t:s0 key=(null) 
type=AVC msg=audit(05/05/2022 07:42:49.698:317) : avc:  denied  { setsched } for  pid=4599 comm=nm-priv-helper scontext=system_u:system_r:NetworkManager_priv_helper_t:s0 tcontext=system_u:system_r:NetworkManager_priv_helper_t:s0 tclass=process permissive=1 
----

Is it required to be allowed?

it seems glib is doing that, when starting threads:

https://gitlab.gnome.org/GNOME/glib/-/tree/c8ea8cafd144b3ad0d5d169ceefe55d6ab0a590b/glib/gthread-posix.c#L1227
https://gitlab.gnome.org/GNOME/glib/-/tree/c8ea8cafd144b3ad0d5d169ceefe55d6ab0a590b/glib/gthread-posix.c#L1260

It seems, glib accepts that the call fails since:
https://gitlab.gnome.org/GNOME/glib/-/commit/965061797d74847d2e2d1237bb7a63328608e28c

However, it does log a g_critical(), which is a pretty bad thing to do (because for testing we want to run our software with `G_DEBUG=fatal-critical` environment to catch bugs).


under which circumstances do you see this behavior exactly? Which NM + glib version (is it RHEL9?)


Can we allow this permission? It seems quite limiting to restrict this, when glib likes to use it for their thread-pool. Or should we downgrade the glib g_critical() instead?

(In reply to Thomas Haller from comment #11)
> it seems glib is doing that, when starting threads:
> 
> https://gitlab.gnome.org/GNOME/glib/-/tree/
> c8ea8cafd144b3ad0d5d169ceefe55d6ab0a590b/glib/gthread-posix.c#L1227
> https://gitlab.gnome.org/GNOME/glib/-/tree/
> c8ea8cafd144b3ad0d5d169ceefe55d6ab0a590b/glib/gthread-posix.c#L1260
> 
> It seems, glib accepts that the call fails since:
> https://gitlab.gnome.org/GNOME/glib/-/commit/
> 965061797d74847d2e2d1237bb7a63328608e28c
> 
> However, it does log a g_critical(), which is a pretty bad thing to do
> (because for testing we want to run our software with
> `G_DEBUG=fatal-critical` environment to catch bugs).
> 
> 
> under which circumstances do you see this behavior exactly? Which NM + glib
> version (is it RHEL9?)
It should be a default RHEL 9.1.

> 
> Can we allow this permission? It seems quite limiting to restrict this, when
> glib likes to use it for their thread-pool. Or should we downgrade the glib
> g_critical() instead?
We can allow it if there is a justification for that. My question was if it is needed or if we can dontaudit (silence) it since there was no failure reported, just the AVC. No need to make changes in other software if a bug was not found.

> > Can we allow this permission? It seems quite limiting to restrict this, when
> > glib likes to use it for their thread-pool. Or should we downgrade the glib
> > g_critical() instead?
> We can allow it if there is a justification for that. My question was if it
> is needed or if we can dontaudit (silence) it since there was no failure
> reported, just the AVC. No need to make changes in other software if a bug
> was not found.

This was also a discussed topic on Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1795524#c25

I think the same resolution should apply to RHEL...

From that bug, I got the impression that dontaudit was used. However, I tested both NetworkManager+nm-priv-helper on Fedora 36, and (unless I made a mistake in testing) it seems they can call SYS_sched_setattr. I don't understand why, did that change in the meantime? In any case, a failure to call SYS_sched_setattr causes glib to use a fallback path, which wastes one thread for the thread pool. Avoiding that extra thread might be more important than to restrict the usage. Maybe NetworkManager+nm-priv-helper should be allowed to use sched_setattr.

There is a general rule:

dontaudit daemon self:process { setsched };

but also an explicit

allow NetworkManager_priv_helper_t self:process setsched;

which takes precedence, see also #c17. The rules are the same in Fedora and RHEL 9.
Usually, selinux-policy should be as strict as possible, but also allow any reasonable/justified permission even in cases there is a fallback call which does not require it.

IIUC setsched is allowed to NetworkManager+nm-priv-helper (on RHEL+Fedora).

That seems right and desirable to me, because -- although on the one hand we want to drop as much privs a possible -- these are long-running processes, and it would seem wasteful to require an additional thread.

Sounds good. Thanks Zdenek!!

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