On 10/4/18 4:10 PM, Sean wrote:

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?

Is selinux denying the request or the socket? Does it work with setenforce permissive?

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 <errors> permission denied binding to 192.168.1.10:443

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 <VirtualHost 192.168.1.10:443> ... <VirtualHost 192.168.1.11: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.

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