In Rocky 8, I have “dns=dnsmasq” in my NetworkManager config, and dnsmasq is working as a name server, but every time it forwards a request to the upstream name server I get an SELinux alert:
SELinux is preventing /usr/sbin/dnsmasq from create access on the socket labeled dnsmasq_t.
I’ve relabeled the whole filesystem to no avail. Yes, everything seems to be working, but I’m flooding the journal with these messages. I do know how to create an ALLOW or DONTAUDIT rule to allow/hide this, but I don’t know what that socket would be for, and I shouldnt have to be doing either of those.
Maybe this will help:
I have not seen that happen, but the alerts are stored in /var/log/audit/ and
audit2allow do show event and generate policy from log, respectively.
It’s interesting to see all the types and contexts from the policy, but it doesn’t really help with what dnsmasq might be wanting to do with that socket and whether that AVC is due to a bug in dnsmasq, a bug in the policy, or something wrong in my setup.
Thanks for the response. I’m still digging.
Thanks, but as I said, I do know how to create the ALLOW or DONTAUDIT rule if one of those is the appropriate route to take.
When NM starts dnsmasq, it will pass DNS servers (from DHCP) via DBus to dnsmasq.
Does DBus involve sockets? (As you said, the policy should be correct out of the box.)
The AVC denial does not happen at startup. It happens repeatedly during operation whenever dnsmasq needs to forward a query upstream.
Web searches for this problem don’t yield anything useful. Any search for “dnsmasq + socket” just gets a bunch of hits for dnsmasq failing to open a socket on port 53. It’s doing that just fine and handling incoming requests on that port.
I’ve seen a few issues similar to these, not only with dnsmasq but with bind also. A quick google has shown bug reports opened on Red Hat Bugzilla or CentOS Bugzilla. It would probably be best to report it on Red Hat Bugzilla with your full output from the alerts/logs that you have.
The alternative of course, would be to allow/ignore by creating your own policies to allow it through - of which you know how to do anyway. It could always be something that was missed originally, hence suggesting opening the bug report.
Would you please post the search terms you used, or perhaps some specific links, because I’m not finding anything related on Google or on either of the Bugzilla sites.
Just searched for the line you posted:
SELinux is preventing /usr/sbin/dnsmasq from create access on the socket labeled dnsmasq_t
whilst not completely similar to your error, there were similarities due to failures because of selinux issues, be it with bind, or dnsmasq for other contexts. I believe the dnsmasq one was related to /etc/hosts on CentOS and that bug was from 2017. The Red Hat one was for bind with some selinux contexts.
The main thing being, that opening a bug for it could see the issue resolved by it being placed in the selinux contexts installed and configured when dnsmasq is installed for example. That way, saving you have to use semanage, audit2allow, etc.
I search on Google with that string (quoted), and the only hit I get is this thread. Minus the quotes, I get a bunch of hits, but nothing remotely useful – one hit on bind in 2013 (long ago resolved), another with dnsmasq denied access to /etc/resolv.conf, and various other SELinux issues not involving either dnsmasq or bind.
Anyway, I’ve opened https://bugs.centos.org/view.php?id=18563 after confirming that the same issue exists in CentOS 8 stream.
And, the problem disappeared a couple of weeks ago for reasons unknown, and I’ve indicated that in the bugzilla report on Red Hat (the CentOS folks were not happy about my report on the CentOS bugzilla).