Thread creation privilege for realtime group.

[dev_submerge.ch]

Summary

With the mac_priority(4) realtime policy active, users and processes in the realtime group may promote existing threads and processes to realtime scheduling priority. Extend the privileges granted to PRIV_SCHED_SETPOLICY which allows explicit creation of new realtime threads.

One use case of this is when the pthread scheduling policy is set to SCHED_RR or SCHED_FIFO via pthread_attr_setschedpolicy(...) before calling pthread_create(...). I ran into this when testing audio software with realtime threads, particularly audio/ardour6.

Test Plan

Tested on FreeBSD 14.0-CURRENT:

• Unprivileged users can not create realtime threads.
• root can create realtime threads.
• With mac_priority loaded, users in the realtime group can create realtime threads.

[kib]

I do not think this is right. Basically, you make SETPOLICY redundant with RTPRIO.

If anything, you might consider either allowing also SETPOLICY in mac_realtime by the same knob, or adding one more knob in the mac. I think reusing the knob is enough.

[dev_submerge.ch]

In D33393#755402, @kib wrote:

I do not think this is right. Basically, you make SETPOLICY redundant with RTPRIO.

I agree. But in its current state, SETPOLICY is redundant, from a security point of view. This is the only place this privilege is checked.

A process that has the RTPRIO privilege can

• promote itself as process to realtime and then create a thread, or
• create a thread and then promote it to realtime.

The only difference I see is technical, without SETPOLICY it's not possible to explicitly request realtime at thread creation time.

If anything, you might consider either allowing also SETPOLICY in mac_realtime by the same knob, or adding one more knob in the mac. I think reusing the knob is enough.

I did consider that, I actually use a modified mac_priority module with SETPOLICY for local testing here on 13.0-RELEASE.

But it convolutes SETPOLICY and RTPRIO even more, because then you cannot use SETPOLICY for anything else without giving the realtime group the privilege for that too.

Maybe the question is, do we still need SETPOLICY here? Or what is it meant for, do you have an idea?

[kib]

In D33393#755468, @dev_submerge.ch wrote:

In D33393#755402, @kib wrote:

I do not think this is right. Basically, you make SETPOLICY redundant with RTPRIO.

I agree. But in its current state, SETPOLICY is redundant, from a security point of view. This is the only place this privilege is checked.

A process that has the RTPRIO privilege can

• promote itself as process to realtime and then create a thread, or
• create a thread and then promote it to realtime.

The only difference I see is technical, without SETPOLICY it's not possible to explicitly request realtime at thread creation time.

If anything, you might consider either allowing also SETPOLICY in mac_realtime by the same knob, or adding one more knob in the mac. I think reusing the knob is enough.

I did consider that, I actually use a modified mac_priority module with SETPOLICY for local testing here on 13.0-RELEASE.

But it convolutes SETPOLICY and RTPRIO even more, because then you cannot use SETPOLICY for anything else without giving the realtime group the privilege for that too.

Maybe the question is, do we still need SETPOLICY here? Or what is it meant for, do you have an idea?

SETPOLICY is used only there, to allow thread to set scheduling policy on the new thread.

I do not see why not reuse the same knob in mac_priority to allow both SCHED_RTPRIO and SCHED_SETPOLICY. It still allows other mac modules to exercise SETPOLICY in a way they find it suitable. The note about 'you cannot use SETPOLICY for anything else without giving the realtime group the privilege for that too' is only valid for mac_priority, not in general. And there it seems to be fine.

[dev_submerge.ch]

In D33393#755615, @kib wrote:

...

SETPOLICY is used only there, to allow thread to set scheduling policy on the new thread.

It just seems strange to me to have two different privileges for effectively the same thing: Creating a new realtime thread.

• Set realtime policy at creation time -> needs SCHED_SETPOLICY
• Set realtime policy after creating the thread -> needs SCHED_RTPRIO

As seen with audio/jack, ported software will use both methods interchangeably. Granting one privilege without the other doesn't make much sense. And from a security risk perspective they are equivalent.

I do not see why not reuse the same knob in mac_priority to allow both SCHED_RTPRIO and SCHED_SETPOLICY. It still allows other mac modules to exercise SETPOLICY in a way they find it suitable. The note about 'you cannot use SETPOLICY for anything else without giving the realtime group the privilege for that too' is only valid for mac_priority, not in general. And there it seems to be fine.

That's ok with me. I don't see much harm in that, apart from confusing newcomers like me :-)
I will add a revised patch tomorrow, thanks for your time.

[dev_submerge.ch]

As suggested, add PRIV_SCHED_SETPOLICY to the kernel privileges granted by the mac_priority realtime policy, instead of including PRIV_SCHED_RTPRIO in the thread creation checks.