Description of problem: Sep 05 13:35:55 foo.home.annexia.org setroubleshoot[1390]: SELinux is preventing zebra from setattr access on the directory frr. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that zebra should be allowed setattr access on the frr directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'zebra' --raw | audit2allow -M my-zebra # semodule -X 300 -i my-zebra.pp time->Mon Sep 5 13:35:49 2022 type=AVC msg=audit(1662381349.136:204): avc: denied { setattr } for pid=1293 comm="zebra" name="frr" dev="dm-1" ino=245708993 scontext=system_u:system_r:frr_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=0 ---- time->Mon Sep 5 13:35:49 2022 type=AVC msg=audit(1662381349.370:206): avc: denied { setattr } for pid=1318 comm="ripd" name="frr" dev="dm-1" ino=245708993 scontext=system_u:system_r:frr_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=0 ---- time->Mon Sep 5 13:35:49 2022 type=AVC msg=audit(1662381349.397:207): avc: denied { setattr } for pid=1323 comm="staticd" name="frr" dev="dm-1" ino=245708993 scontext=system_u:system_r:frr_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=0 audit2allow: #============= frr_t ============== allow frr_t tmp_t:dir setattr; Version-Release number of selected component (if applicable): frr-8.2.2-10.fc37.x86_64 selinux-policy-37.8-1.fc37.noarch How reproducible: 100% Steps to Reproduce: 1. Try to start frr.
Reassigning to frr.
Hi Richard, is frr-selinux package installed as well? # rpm -qa | grep frr I cannot reproduce the AVC in a fresh Fedora 37 instance: # sed -i 's/=no/=yes/' /etc/frr/daemons # systemctl start frr # systemctl status frr ● frr.service - FRRouting Loaded: loaded (/usr/lib/systemd/system/frr.service; disabled; preset: disabled) Active: active (running) since Tue 2022-09-06 10:57:52 EDT; 7s ago Docs: https://frrouting.readthedocs.io/en/latest/setup.html Process: 1757 ExecStart=/usr/libexec/frr/frrinit.sh start (code=exited, status=0/SUCCESS) Main PID: 1762 (watchfrr) Status: "FRR Operational" Tasks: 41 (limit: 2329) Memory: 60.4M CPU: 516ms CGroup: /system.slice/frr.service ├─1762 /usr/libexec/frr/watchfrr -d -F traditional zebra bgpd ripd ripngd ospfd ospf6d isisd pimd nhrpd e… ├─1828 /usr/libexec/frr/zebra -d -F traditional -A 127.0.0.1 -s 90000000 ├─1833 /usr/libexec/frr/bgpd -d -F traditional -A 127.0.0.1 ├─1840 /usr/libexec/frr/ripd -d -F traditional -A 127.0.0.1 ├─1843 /usr/libexec/frr/ripngd -d -F traditional -A ::1 ├─1846 /usr/libexec/frr/ospfd -d -F traditional -A 127.0.0.1 ├─1849 /usr/libexec/frr/ospf6d -d -F traditional -A ::1 ├─1852 /usr/libexec/frr/isisd -d -F traditional -A 127.0.0.1 ├─1855 /usr/libexec/frr/pimd -d -F traditional -A 127.0.0.1 ├─1864 /usr/libexec/frr/nhrpd -d -F traditional -A 127.0.0.1 ├─1869 /usr/libexec/frr/eigrpd -d -F traditional -A 127.0.0.1 ├─1872 /usr/libexec/frr/pbrd -d -F traditional -A 127.0.0.1 ├─1875 /usr/libexec/frr/staticd -d -F traditional -A 127.0.0.1 ├─1878 /usr/libexec/frr/bfdd -d -F traditional -A 127.0.0.1 ├─1881 /usr/libexec/frr/fabricd -d -F traditional -A 127.0.0.1 ├─1884 /usr/libexec/frr/vrrpd -d -F traditional -A 127.0.0.1 └─1888 /usr/libexec/frr/pathd -d -F traditional -A 127.0.0.1 Sep 06 10:57:52 ci-vm-10-0-139-61.hosted.upshift.rdu2.redhat.com watchfrr[1762]: [QDG3Y-BY5TN] eigrpd state -> up …eded Sep 06 10:57:52 ci-vm-10-0-139-61.hosted.upshift.rdu2.redhat.com watchfrr[1762]: [QDG3Y-BY5TN] pbrd state -> up : …eded Sep 06 10:57:52 ci-vm-10-0-139-61.hosted.upshift.rdu2.redhat.com watchfrr[1762]: [QDG3Y-BY5TN] staticd state -> up…eded Sep 06 10:57:52 ci-vm-10-0-139-61.hosted.upshift.rdu2.redhat.com watchfrr[1762]: [QDG3Y-BY5TN] bfdd state -> up : …eded Sep 06 10:57:52 ci-vm-10-0-139-61.hosted.upshift.rdu2.redhat.com watchfrr[1762]: [QDG3Y-BY5TN] fabricd state -> up…eded Sep 06 10:57:52 ci-vm-10-0-139-61.hosted.upshift.rdu2.redhat.com watchfrr[1762]: [QDG3Y-BY5TN] vrrpd state -> up :…eded Sep 06 10:57:52 ci-vm-10-0-139-61.hosted.upshift.rdu2.redhat.com watchfrr[1762]: [QDG3Y-BY5TN] pathd state -> up :…eded Sep 06 10:57:52 ci-vm-10-0-139-61.hosted.upshift.rdu2.redhat.com watchfrr[1762]: [KWE5Q-QNGFC] all daemons up, doi…tify Sep 06 10:57:52 ci-vm-10-0-139-61.hosted.upshift.rdu2.redhat.com frrinit.sh[1757]: Started watchfrr Sep 06 10:57:52 ci-vm-10-0-139-61.hosted.upshift.rdu2.redhat.com systemd[1]: Started frr.service - FRRouting. # grep setattr /var/log/audit/audit.log # ausearch -c 'zebra' --raw | audit2allow Nothing to do Regards, Michal
It is: frr-selinux-8.2.2-10.fc37.noarch frr-8.2.2-10.fc37.x86_64 Anyhow this is an upgraded Fedora so I guess if it works in Fedora 37 fresh install that's OK.
Hi Richard, just testing an upgrade process, the AVC might come from a short period of time when the new frr is already installed but original frr files still have old labels. I think I might add these lines to the spec that I used in RHEL: %{_sbindir}/restorecon -R /var/tmp/frr &> /dev/null %{_sbindir}/restorecon -R /var/run/frr &> /dev/null I have these in %post_selinux and I think the reasoning was similar. I did not test an actual upgrade with this, just an update of the package but I remember seeing similar AVCs. I'll keep this open and try the upgrade myself. Regards, Michal
The first command did relabel something, the second one didn't. It's a plausible explanation: # restorecon -Rv /var/tmp/frr Relabeled /var/tmp/frr from system_u:object_r:tmp_t:s0 to system_u:object_r:frr_tmp_t:s0 # restorecon -Rv /var/run/frr
Just did an upgrade with the restorecon in place and no setattr anymore. Without it there are setattr errors for every daemon enabled. I am going to release the fix now.
This should do it: https://koji.fedoraproject.org/koji/taskinfo?taskID=91732214 Thanks Richard. Closing the bug now. If you see any more of these AVCs, let me know.
Adding a build for F37, since the selinux policy is there as well: https://koji.fedoraproject.org/koji/taskinfo?taskID=91732608
FEDORA-2022-688b2782e9 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-688b2782e9
FEDORA-2022-688b2782e9 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-688b2782e9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-688b2782e9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-1b7925467c has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-1b7925467c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-1b7925467c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-9f5d5b6e3a has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-9f5d5b6e3a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-9f5d5b6e3a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-9f5d5b6e3a has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.