NetworkManager, Multiple IPs, And Selinux…
Hello,
I was wondering if any one has seen issues with selinux name_bind denials that result from having IP:PORT bindings for services to specific IP
addresses managed on an interface under NetworkManager’s control?
I do realize that people will probably say stop using NetworkManager, and I
may, but the behavior is strange, and I’d like to have a better understanding of what’s going on.
The config is like so:
# nmcli c mod eth0 ipv4.addresses 192.168.1.10/24,192.168.1.11/24
# nmcli c down eth0
# nmcli c up eth0
# getenforce Enforcing
# systemctl start httpd
Apache has two simple IP based VHosts, site1 and site2, with different (and correct dns records and ssl certs). I’m snipping the config because I know the Apache config works.
Listen 443
…
…
I find the denial strange. I’ve done some testing such as removing one VHost’s config and adding a NIC to the VM (eth1) and reconfigure to have 1
IP on each NIC and use both Vhosts. Either way, the selinux denial disappears and everything works. All the packaged selinux policy relating to httpd_t and access to port 443 is correct.
I don’t doubt that if I ditched NetworkManager and went for eth0:0 and eth0:1 for the IP interfaces, all would be well. I’d just like to see if anyone has some input on the issue.
–Sean
2 thoughts on - NetworkManager, Multiple IPs, And Selinux…
Is selinux denying the request or the socket? Does it work with setenforce permissive?
I don’t believe apache selectively binds the socket to the address, but the interface. My suspicion is that you can only bind one listener for a port to an interface and not to individual IP addresses on the same interface. If you use “virtual” interfaces to separate the IP addresses
(eth0:0, eth0:1) then I would expect it to work.
– Mike
I don’t. I have httpd processes listening on specific ports, and multiple addresses per interface managed by NetworkManager.
I don’t see why.
What makes you think it’s an SELinux denial? Did you see an AVC logged in /var/log/audit/audit.log? Can you resolve the issue by setting the system to permissive mode? Either of those would suggest that the restriction is imposed by SELinux policy, but you didn’t provide either of those as diagnostic evidence.