Bug 2126040

Description of problem:

With the new SELinux policy added recently for FRR in RHEL8, there is a problem when zebra wants to write dynamically learned routes to the kernel routing table. This is a big deal since this makes FRR rather problematic to use. I should have seen this when testing the new SELinux policy but this only becomes visible with multiple hosts that are exchanging routes and our multihost tests are currently not working.

Also the new AVC describing the problem are not visible unless you instruct auditd to log 'donotaudit' rules.


Version-Release number of selected component (if applicable):
frr-7.5.1-3.el8


How reproducible:
Run FRR in two instances and see any exchange of routing information.


Steps to Reproduce:
1. Make sure that donotaudit AVCs are logged as well:
# semodule -DB

2. Install frr on two routers, enable any routing daemon(in this case I am using RIP):
# vtysh -c "conf t" -c "router rip" -c "network 10.0.x.x/xx"
# vtysh -c "sh run"
...
router rip
 network 10.0.x.x/xx
...
# vtysh -c "sh ip rip status"
Routing Protocol is "rip"
  Sending updates every 30 seconds with +/-50%, next due in 4 seconds
  Timeout after 180 seconds, garbage collect after 120 seconds
  Outgoing update filter list for all interface is not set
  Incoming update filter list for all interface is not set
  Default redistribution metric is 1
  Redistributing:
  Default version control: send version 2, receive any version 
    Interface        Send  Recv   Key-chain
    eth0             2     1 2    
  Routing for Networks:
    10.0.x.x/xx
  Routing Information Sources:
    Gateway          BadPackets BadRoutes  Distance Last Update
  Distance: (default is 120)

Do the same on the second router as well.

3. Add an interface on one router that will be the routing information sent from one router to the other:
# ip link add dev dummy1 type dummy
# ip add add 192.168.10.1/24 dev dummy1
# ip link set dummy1 up
# ip a
...
3: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 32:48:b0:e4:e6:c3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.1/24 scope global dummy1
       valid_lft forever preferred_lft forever
    inet6 fe80::3048:b0ff:fee4:e6c3/64 scope link 
       valid_lft forever preferred_lft forever

4. Add the newly added interface to the rip protocol:
# vtysh -c "conf t" -c "router rip" -c "network 192.168.10.0/24"
# vtysh -c "sh ip rip status"
Routing Protocol is "rip"
  Sending updates every 30 seconds with +/-50%, next due in 30 seconds
  Timeout after 180 seconds, garbage collect after 120 seconds
  Outgoing update filter list for all interface is not set
  Incoming update filter list for all interface is not set
  Default redistribution metric is 1
  Redistributing:
  Default version control: send version 2, receive any version 
    Interface        Send  Recv   Key-chain
    dummy1           2     1 2    
    eth0             2     1 2    
  Routing for Networks:
    10.0.x.x/xx
    192.168.10.0/24
  Routing Information Sources:
    Gateway          BadPackets BadRoutes  Distance Last Update
  Distance: (default is 120)


Actual results:
The routing information about the 192.168.10.0/24 network is propagated to the second router but it is not possible for zebra to write the route to the kernel routing table:
# vtysh -c "sh ip route"
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup

K>* 0.0.0.0/0 [0/100] via 10.0.139.254, eth0, src 10.0.139.166, 00:17:27
C>* 10.0.136.0/22 is directly connected, eth0, 00:17:27
K>* 169.254.169.254/32 [0/100] via 10.0.136.13, eth0, src 10.0.139.166, 00:17:27
R>r 192.168.10.0/24 [120/2] via 10.0.138.0, eth0, weight 1, 00:01:13  <--- rejected

# ip route | grep '192\.168\.10'
<empty>

# ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today
...
type=PROCTITLE msg=audit(09/12/2022 04:12:38.753:424) : proctitle=/usr/libexec/frr/zebra -d -F traditional -A 127.0.0.1 -s 90000000 
type=SOCKADDR msg=audit(09/12/2022 04:12:38.753:424) : saddr={ saddr_fam=netlink nlnk-fam=16 nlnk-pid=0 } 
type=SYSCALL msg=audit(09/12/2022 04:12:38.753:424) : arch=x86_64 syscall=sendmsg success=yes exit=60 a0=0x10 a1=0x7f96a453b770 a2=0x0 a3=0x55ef55ecce6c items=0 ppid=1 pid=7099 auid=unset uid=frr gid=frr euid=frr suid=frr fsuid=frr egid=frr sgid=frr fsgid=frr tty=(none) ses=unset comm=zebra_dplane exe=/usr/libexec/frr/zebra subj=system_u:system_r:frr_t:s0 key=(null) 
type=AVC msg=audit(09/12/2022 04:12:38.753:424) : avc:  denied  { net_admin } for  pid=7099 comm=zebra_dplane capability=net_admin  scontext=system_u:system_r:frr_t:s0 tcontext=system_u:system_r:frr_t:s0 tclass=capability permissive=0 
...

This is the one AVC that is telling us what is happening, there are other AVCs about watchfrr with a similar meaning. The important part is that frr_t needs the net_admin capability to make this work.


Expected results:
# vtysh -c "sh ip route"
...
R>* 192.168.10.0/24 [120/2] via 10.0.138.0, eth0, weight 1, 00:00:01 <--- not rejected
# ip route
...
192.168.10.0/24 via 10.0.138.0 dev eth0 proto rip metric 20  <--- route added to the routing table
#

# ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today
<no matches> <--- at least no matches for zebra or any other daemon from frr