SELinux violation attempt

Ask Fedora
1

I got several {dac_override} denials in the sudo ausearch -m avc log. I’m not sure how to investigate it. I run nspawn containers which block DAC overrides by default, so I’m thinking it comes from within containers. What could be causing this? I have been doing containers for a while and never had quite any SELinux errors before.

avc: denied { dac_override } for pid=2216405 comm="11-dhclient" capability=1 scontext=system_u:system_r:NetworkManager_dispatcher_dhclient_t:s0 tcontext=system_u:system_r:Networkmanager_dispatcher_dhclient_t:s0 tclass=capability permission=0

and

avc: denied { dac_override } for pid=2216407 comm="20-chrony-dhcp" capability=1 scontext=system_u:system_r:NetworkManager_dispatcher_chronyc_t:s0 tcontext=system_u:system_r:Networkmanager_dispatcher_chronyc_t:s0 tclass=capability permission=0

and a couple of other similar ones for comm="04-iscsi" and comm="20-chrony-onoff"

I don’t even have NetworkManager installed inside containers. One container has NetworkManager-libnm installed for some reason, which is depended upon by tracker-miners package…and I don’t even know why tracker-miners package got installed because nothing depends on it inside the container. Could this NetworkManager-libnm inside a container be the culprit?

2

To see what installed a specific package in Fedora using dnf we can run dnf history <package-name>.

Well, this is weird now. I ran dnf history tracker-miners, and this shows that it was installed with install openbox Xephyr firefox. But I’m not seeing firefox require tracker-miners package. Maybe mozilla-filesystem package that’s part of firefox required it? I’m so confused now.

Anyway, is this a weak dependency that can be ignored by running dnf install <package> --weakdep=False?

3

As far as I know, nspawn containers will run all their processes under a single context. The context is typically something like container_t or spc_t (though it is customizable via systemd-nspawn’s --selinux-context= option). Since the processes that are generating the errors are running with source contexts of NetworkManager_dispatcher_dhclient_t and NetworkManager_dispatcher_chronyc_t, I would expect that they are running on your host system, not in any of your containers.

P.S. I remember someone else reporting difficulties with NetworkManager and SELinux in recent history: The NetworkManager service doesn't start during boot after upgrading the kernel to versions higher than Linux 6.8.9-300.fc40.x86_64 - #4 by glb I wonder if the problem you are seeing might be (more?) fallout from that bug?

1 Like
4

My kernel version is below 6.8.9, so it’s not that bug.

Ok, so what is this NetworkManager dispatcher trying to bypass DAC access controls?? I also don’t even have a dhclient installed/running. And my host’s NetworkManager does not have any dispatcher scripts installed in /etc/NetworkManager/dispatcher.d/ …So weird.

5

The default location for 11-dhclient appears to be /usr/lib/NetworkManager/dispatcher.d:

$ dnf provides '*/11-dhclient'                                                                                                                                                                    
Last metadata expiration check: 1 day, 23:31:42 ago on Wed Aug 28 14:08:22 2024.
dhcp-client-12:4.4.3-13.P1.fc40.x86_64 : Provides the ISC DHCP client daemon and dhclient-script
Repo        : @System
Matched from:
Filename    : /usr/lib/NetworkManager/dispatcher.d/11-dhclient
1 Like
6

Please enable full auditing and check DAC permissions of the file/directory which triggers this denial.
https://fedoraproject.org/wiki/SELinux/Debugging#Enable_full_auditing

3 Likes