Hide Forgot
Created attachment 501530 [details] details output Description of problem: SELinux is preventing /usr/sbin/dnsmasq from read access on the file nm-dns-dnsmasq.conf. I'm getting this issue on F15 after adding "dns=dnsmasq" to /etc/NetworkManager/NetworkManager.conf Seems to be creating this file in /var/run/ Version-Release number of selected component (if applicable): selinux-policy-3.9.16-24.fc15.noarch How reproducible: Steps to Reproduce: 1. Install dnsmasq 2. Add "dns=dnsmasq" to /etc/NetworkManager/NetworkManager.conf 3. Restart NM Actual results: Selinux troubleshoot flags up unexpected read Expected results: Additional info: Running the suggested steps appear to resolve this; allow this access for now by executing: # grep dnsmasq /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Orignally reported in bug #682460 as the "report bug" button linked to that issue.
This should be fixed here i believe: https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-26.fc15
Yes, it should be fixed.
I'm getting denied-getattr and denied-unlink on nm-dns-dnsmasq.conf using selinux-policy-3.9.16-34.fc15.noarch. Should this bug be reopened, or filed separately? I noticed in particular that when the file is first created it has context NetworkManager_var_run_t, but restorecon puts it back to var_run_t. I see no special rules for this file in semanage fcontext.
What avc msgs are you getting?
type=AVC msg=audit(1311446980.946:9756): avc: denied { getattr } for pid=984 comm="NetworkManager" path="/run/nm-dns-dnsmasq.conf" dev=tmpfs ino=215168 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=file type=AVC msg=audit(1311446980.946:9757): avc: denied { unlink } for pid=984 comm="NetworkManager" name="nm-dns-dnsmasq.conf" dev=tmpfs ino=215168 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=file I did a chcon back to NetworkManager_var_run_t, and since then it's been fine.
Any idea how it got labeled this? Were you running any tools at the command line to start the network?
Hmm, I almost always use nm-applet to manage connections. However, recently I was tinkering with loading/unloading e1000e for some driver issues I was having, so maybe NM got confused somewhere in that. I didn't investigate the sealert for a while at first, because the network still seemed to be working, until I noticed that my local hosts weren't resolving anymore while I was on the VPN. But now dns-dnsmasq is working again, so I guess I'll just watch to see if it happens again...
ok, could you open the bug if the problem occurs again.