Description of problem: Don't know why this happened. SELinux is preventing zebra from 'setattr' accesses 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 Additional Information: Source Context system_u:system_r:frr_t:s0 Target Context system_u:object_r:tmp_t:s0 Target Objects frr [ dir ] Source zebra Source Path zebra Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-37.14-1.fc37.noarch Local Policy RPM frr-selinux-8.4-1.fc37.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 6.0.9-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Nov 16 17:36:22 UTC 2022 x86_64 x86_64 Alert Count 6 First Seen 2022-11-22 08:59:33 EST Last Seen 2022-11-26 13:41:06 EST Local ID e5ca7401-684f-4f11-9598-6b2aa593fc95 Raw Audit Messages type=AVC msg=audit(1669488066.945:200): avc: denied { setattr } for pid=1296 comm="staticd" name="frr" dev="dm-0" ino=224402 scontext=system_u:system_r:frr_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=0 Hash: zebra,frr_t,tmp_t,dir,setattr Version-Release number of selected component: selinux-policy-targeted-37.14-1.fc37.noarch Additional info: component: frr reporter: libreport-2.17.4 hashmarkername: setroubleshoot kernel: 6.0.9-300.fc37.x86_64 type: libreport
Hi Brian, do you know when this happened? The fact that frr_t was trying to access tmp_t might suggest that this happened during a system upgrade from f36 to f37. In f37, the frr-selinux sub-package was added and any file in /var/tmp/frr that would have tmp_t needs to be relabeled to frr_tmp_t. This should be done in the %pre scriptlet for selinux sub-package. If you could provide any more info about how frr was run, or at what occasion this happened, that would help tremendously. Same goes for bug #2149299. Thanks and regards, Michal
It could have happened during an upgrade. I did upgrade just recently -- in the same general time window.
I am going to keep this one open for a while for anyone who would hit this just like you did. I really think this is the case with upgrade as described in comment #1. I don't think there is much more that I can do than has already been done unless I would add the capability for frr to operate on any tmp_t file, which I don't want. Everything under tmp for frr is now frr_tmp_t after the upgrade: type frr_tmp_t; files_tmp_file(frr_tmp_t) ... manage_dirs_pattern(frr_t, frr_tmp_t, frr_tmp_t) <-- includes setattr for the frr tmp dir and files inside it.
Closing this one. This is most likely a one time hit during an upgrade from frr that does not include a targeted selinux policy to the one that does. Explained in comment #1 and comment #3. Feel free to reopen should you feel that the assessment is not correct.