I would like to reproduce the SELinux denials which appear when FreeRADIUS acts as DHCP server, DHCP client, VMPS server etc.
Is there an easy way how to do that?

I shall reproduce what I can. ETA: next week.

The priority here is to support FR acting as a DHCP server since this is a common situation that is being actively promoted. The remaining scenarios are less common for users of RHEL packages, as most of these users will be using more-recent upstream packages.

Part of the intent here is to reduce attrition for users of more recent upstream (and consequently current and future RHEL packages) going forward where these non-RADIUS protocols will be well used. Upstream prefer to work to improve the existing distro SELinux policy than to advise a package-specific policy at this time.

(In reply to Terry Burton from comment #2)
> I shall reproduce what I can. ETA: next week.
> 
> The priority here is to support FR acting as a DHCP server since this is a
> common situation that is being actively promoted. The remaining scenarios
> are less common for users of RHEL packages, as most of these users will be
> using more-recent upstream packages.
> 
> Part of the intent here is to reduce attrition for users of more recent
> upstream (and consequently current and future RHEL packages) going forward
> where these non-RADIUS protocols will be well used. Upstream prefer to work
> to improve the existing distro SELinux policy than to advise a
> package-specific policy at this time.

Terry,

Have you managed to find the scenarios to reproduce the known problems? Can you share them with us so that we can ensure the fix is complete?

Terry,

I've cherry-picked and modified the PRs to get them to RHEL 8 and there will be a build soon. The request to reproduce the problems and verify the features work as expected in the new build is still valid.

I managed to enable the VMPS feauture and the following SELinux denial appeared in enforcing mode:
----
type=PROCTITLE msg=audit(11/11/2021 04:28:31.452:325) : proctitle=/usr/sbin/radiusd -d /etc/raddb 
type=SYSCALL msg=audit(11/11/2021 04:28:31.452:325) : arch=x86_64 syscall=setsockopt success=no exit=EPERM(Operation not permitted) a0=0x10 a1=SOL_SOCKET a2=SO_BINDTODEVICE a3=0x7ffecf5e5130 items=0 ppid=6451 pid=6454 auid=unset uid=root gid=radiusd euid=root suid=root fsuid=root egid=radiusd sgid=radiusd fsgid=radiusd tty=(none) ses=unset comm=radiusd exe=/usr/sbin/radiusd subj=system_u:system_r:radiusd_t:s0 key=(null) 
type=AVC msg=audit(11/11/2021 04:28:31.452:325) : avc:  denied  { net_raw } for  pid=6454 comm=radiusd capability=net_raw  scontext=system_u:system_r:radiusd_t:s0 tcontext=system_u:system_r:radiusd_t:s0 tclass=capability permissive=0 
----

The following SELinux denial appeared in permissive mode:
----
type=PROCTITLE msg=audit(11/11/2021 04:29:52.013:329) : proctitle=/usr/sbin/radiusd -d /etc/raddb 
type=SYSCALL msg=audit(11/11/2021 04:29:52.013:329) : arch=x86_64 syscall=setsockopt success=yes exit=0 a0=0x10 a1=SOL_SOCKET a2=SO_BINDTODEVICE a3=0x7ffeead17b80 items=0 ppid=6488 pid=6490 auid=unset uid=root gid=radiusd euid=root suid=root fsuid=root egid=radiusd sgid=radiusd fsgid=radiusd tty=(none) ses=unset comm=radiusd exe=/usr/sbin/radiusd subj=system_u:system_r:radiusd_t:s0 key=(null) 
type=AVC msg=audit(11/11/2021 04:29:52.013:329) : avc:  denied  { net_raw } for  pid=6490 comm=radiusd capability=net_raw  scontext=system_u:system_r:radiusd_t:s0 tcontext=system_u:system_r:radiusd_t:s0 tclass=capability permissive=1 
----

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:1995

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days