CentOS - Oct 2018 - 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
<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.


--Sean

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

On 10/4/18 1:10 PM, Sean wrote:
> 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 don't.? I have httpd processes listening on specific ports, and 
multiple addresses per interface managed by NetworkManager.

> I do realize that people will probably say stop using NetworkManager

I don't see why.

> # systemctl start httpd
> <errors> permission denied binding to 192.168.1.10: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.

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.