8

I'm in the process of enabling SELinux on my CentOS 7.3 server. I have it set in permissive mode and monitoring the audit log for denials. I'm looking to implement the minimal set of rules that will allow all that is needed on the server and no more.

So this morning I noticed that httpd would have been blocked from connecting to the network when I used WordPress's FTP update feature last night. audit2why recommends setting either httpd_can_network_relay or httpd_can_network_connect.

I just want to make sure I'm understanding the difference between these two correctly. Would it be accurate to say that httpd_can_network_connect allows httpd to make any outgoing network connection it wishes, whereas httpd_can_network_relay allows only the FTP port and ephemeral ports?

audit2why says:

# setsebool -P httpd_can_network_connect 1
Description: Allow httpd to act as a relay

# setsebool -P httpd_can_network_relay 1
Description: Allow httpd to act as a FTP client connecting to the ftp port and ephemeral ports

If so, how would it go about defining what the ephemeral ports are, or would it just allow anything over 1024?

Is there some more detailed reference on all this that I'm missing?

Update

I misread the order of comments to commands, the above should read:

Description: Allow HTTPD scripts and modules to connect to the network using TCP.
# setsebool -P httpd_can_network_connect 1

Description: Allow httpd to act as a relay
# setsebool -P httpd_can_network_relay 1

2 Answers 2

10

As Enigma says:

The first option [httpd_can_network_relay] is used in an reverse proxy scenario in which your httpd is relaying requests to some backend httpd in behalf of the client.

As for httpd_can_network_connect, it allows httpd to make network connections, including scripts and modules.

Basically the output from audit2why is formatted in a strange way that made it hard to tell which description matched which boolean, hence the weird question based on that. I updated the question with the correct interpretation of that.

3

The first option [httpd_can_network_relay] is used in an reverse proxy scenario in which your httpd is relaying requests to some backend httpd in behalf of the client.

The second one [httpd_can_network_connect] allows httpd modules and scripts to make outgoing connections to ports which are associated with the httpd service. To see a list of those ports run semanage port -l | grep -w http_port_t

To make your scenario work you need to run setsebool -P httpd_can_network_connect 1 and then add the port that your httpd should be able to connect to by running this command semanage port -a -t http_port_t -p tcp <PORT>

2
  • The information I had added about the types from audit2why was misinterpreted. I updated my question.
    – user112461
    Commented Feb 26, 2017 at 3:05
  • 1
    Thanks for your answer. I find the part about the ports is not correct. It seems that httpd_can_network_connect allows any outgoing network connection. I switched it on and am able to connect to SFTP on an obscure random port that is certainly not in the list of ports for http_port_t. I don't know what that is for, but it's not this.
    – user112461
    Commented Feb 26, 2017 at 3:09

You must log in to answer this question.