SElinux write denied on every firewall restart - how to resolve?

Installing and Using OpenWrt
1

On every firewall /etc/init.d/firewall/restart in log these two lines show up..
I dont understand what dir or path fw3 cannot wirte to? How to diagnose further?

Mon May 30 03:43:40 2022 kern.notice kernel: [140498.393493] audit: type=1400 audit(1653871420.456:85): avc: denied { write } for pid=12437 comm="fw3" name="net" dev="proc" ino=1208818 scontext=u:r:sys.subj tcontext=u:r:sys.subj tclass=dir permissive=0

Mon May 30 03:43:40 2022 kern.notice kernel: [140498.408088] audit: type=1400 audit(1653871420.468:86): avc: denied { write } for pid=12437 comm="fw3" name="net" dev="proc" ino=1208818 scontext=u:r:sys.subj tcontext=u:r:sys.subj tclass=dir permissive=0

2

Since selinux is not enabled by default in OpenWrt...a policy needed (which I surmise is the issue), etc., don't you think more information is needed to assist you?

To better assist, please provide more details on your setup.

@jow or another developer might know what directory is being written to.

3

This is likely fw3's attempt to write /proc/net/nf_conntrack - check that this is allowed by your selinux policy.

4

Hello,

The avc denial gives you information to interpret the event:

A process with pid 12537 and name fw3 associated with context u:r:sys.subj was attempting to write a directory located at inode 1208818 with name net associated with context u:r:sys.subj on device proc. The attempt was blocked.

e.g. fw3 was trying to write to directory /proc/net which is something that it should not be allowed to do.

I can imagine that this event raises questions and to be able to understand what happens one needs a bit of context but:

The issue here is that fw3 is not associated with the context it is supposed to be associated with. This event would have been suppressed if it was. The event is harmless but its not suppressed because it indicates something is wrong nonetheless.

My question to you is: what target is this? Is this a QEMU image?
Because it seems that your image file system may be unlabeled. If this is a QEMU system then you should be ble able to address this issue by running restorecon -RF / and rebooting the system. This procedure should associate labels with inodes on the filesystems which should cause fw3 (and other entities) to become associated with their expected contexts.