I had a problem with Dnsmasq that led to my last post on understanding
where policies come from. Now that I know and have had dnsmasq
comfortably running with udp comms to unbound on port 553, I have run
into the original problem that I thought I had caused.
I suppose I did cause it, but not in the way I imagined. I was awash
again with AVCs from dnsmasq, but this time I took a closer look and
realised the source context was not as expected. Instead of running in
dnsmasq_t, it was running in resolvconf_t. I checked the binary and that
was as expected so I restarted using run_init just to see if that was
the problem, and it was! So now dnsmasq is running in the correct
context, but how did it ever get to resolvconf_t? Surely if I had
restarted it without using run_init then it would have been in sysadm_t?
One possibility is that it got into this context when my interface went
down and up again. I had a problem last night with my Virgin fibre modem
and I noticed that after the inevitable hardware reset, a bunch of
services had been restarted. Besides the issue that dnsmasq is not bound
to the interface in question, I guess I could test it quite easily,
although I am not sure everyone else on the LAN will be too keen.
Any thoughts welcome
Robert Sharp
