2

According to semanage-port(1) ...

  • -a does the same as --add
  • -t does the same as --type
  • -p does the same as --port

and the command

 semanage port -a -t http_port_t -p tcp 81

allows Apache to LISTEN ON port 81.

So far, so good. But this solution to a haproxy related problem tells me that the command

semanage port --add --type http_port_t --proto tcp 8001

adds port to the list of ports haproxy can CONNECT TO.

Does that mean listening on and connecting to are always the same, as far as SELinux is concerned? Or is there some rule that associates port lists as either ingress, egress, or both? If so, where can I find this informationin my OS and how can I modify it?

Bananguin
  • 7,984

1 Answers1

1

As far as SELinux is concerned, "listening on" and "connecting to" are not the same thing. These are two different things and to be able to do either, a process's needs to have the correct permission. In the case of binding to a port and connecting to a port, those permissions are name_bind and name_connect respectively.

In this case, we're interested in class permissions. But again, as is generally the case with SELinux, we're missing one piece of information - permissions on which class? I feel that there must be a better way to find this, but I haven't really come across it yet. So let's use what we know:

sesearch -d -A -t http_port_t
Found 81 semantic av rules:
    allow cloud_init_t http_port_t : tcp_socket name_connect ;
    ...

This will show us all of the allow rules where http_port_t is the target. Thankfully, we can notice that they all operate on the same class - tcp_socket. And that makes sense. Now let's check all of the permissions that the class tcp_socket has (this, as far as I am aware, is defined in the policy itself).

seinfo -ctcp_socket -x
  • -c prints object classes (note that there must not be a space between the flag and the name)
  • -x shows more info (in this case, actually the thing we're interested in - the permissions!)

This will list all the permissions that apply to the tcp_socket class - among them, name_bind and name_connect, which are the LISTEN ON and CONNECT TO meanings from your question.

Let's assume that you want to use haproxy - haproxy has the SELinux type of haproxy_t. Now to see which permissions haproxy has on the ports defined in http_port_t:

sesearch -d -A -s haproxy_t -t http_port_t
Found 1 semantic av rules:
    allow haproxy_t http_port_t : tcp_socket { name_bind name_connect } ;

This shows us that haproxy has name_bind and name_connect permissions. So whichever port you add to http_port_t, that will allow haproxy to bind and connect to said port (however, all other types which use http_port_t will also be able to use their respective permissions on said port! For instance, openvpn will be able to receive and send messages, and bind and connect).

If instead of http_port_t, haproxy used specific types for each permission, say haproxy_connect_port_t and haproxy_bind_port_t with name_connect and name_bind permissions respectively, then if you added the port to only haproxy_connect_port_t, it would only be able to connect to said port, not listen/bind to it.

user6075516
  • 898
  • 6
  • 11