Does the httpd_can_network_connect boolean (and other httpd ones) apply to Apache Tomcat 9 running on Rocky with enforcing SELinux?
Tomcat runs an application that will call another web service within the same server. I am familiar with Apache httpd not working until httpd_can_network_connect is set to ON. Is this also applicable to Tomcat since it uses http protocol for the application?
It can apply yes, since it can also apply to haproxy and nginx. Not only that, but if using the non-standard ports, you may even need to use an additional rule. Tomcat defaults to 8080 and 8443 for SSL, so if you change these to something else - because something else already uses these ports or something, then you would also need:
semanage port --add --type http_port_t --proto tcp 9090
for example, I change port 8080 to 9090 I then need to tell selinux to allow that port. And most likely the httpd_can_network_connect as well.
More generally, the question is whether process (Tomcat) is configured to have same process type as process httpd. That is apparently done via file type. See httpd_selinux(8) - Linux man page
In a way this helps because it confirms that I am on the right direction. But it doesnât answer my question.
Do the booleans need to be set when I use Apache Tomcat instead of Apache HTTPD? Afterall Tomcat is using the http protocol. Hope my thinking is going the right direction?
Thanks you @iwalker. This gives me a good direction.
Luckily I use port 443 on firewall and forward this to 8443 of Tomcat. The external webservice I relay to is on port 9980 but maybe I can get away with just toggling 2 booleans.
Thank you again. I will explore.
Hi @jlehtone
Thank you. I will spend some time reading this so I can get a better understanding of the concepts. After reading I am certain I will be more confident
i did not use webservice using tomcat so i do not know if it required or not
i guess tomcat doc will be the one that would help you to determine which option is required
but if it does then the option there you can modify it
Clarify how you installed tomcat 9, especially regarding the systemd service.
The thing is, tomcat used to be available in RHEL, and it was tightly controlled with both itâs security manager AND selinux, but RHEL ditched tomcat, and as far as I know if you install it to a random location, it wonât care about selinux (at least in relation to file contexts). Iâd start without setting the bool, let it try to connect to a different service and see if you get sealerts.
Hi @gerry666uk
I downloaded tomcat from the website. I unpacked it under /opt/ folder and installed it under tomcat user in that folder. I then set the systemd config file to let systemd service manage the service lifecycle.
PS: I got the service to work through port 443 (forwarded to port 8443) via my SOAP UI. But when I integrate the Tibco service bus system, it gets a socket error. But I am yet to retry the integration after I changed the SSHHostConfig tag of tomcat to explicitly specify TLSv1.2 and TLSv1.3. I suspect the Tibco system doesnât support TLSv1.3 by default. I will know for sure what is happening and I will share feedback.
Regarding the systemd config file, did they provide it for you? Iâm asking because at one point (with tomcat 7) you had to create it yourself. Itâs important because (as you said), you have to set the âtomcatâ user.
Regarding the selinux file contexts in /opt, I think youâll find it doesnât care; in the older RHEL supplied tomcat version, it would refuse to start unless it had the correct file contexts in place (similar to apache).
If you know some java, you could create a simple âHello tilcoâ servlet which you could use to test connecting using TLS, and then capture the exception.
Thank you @gerry666uk. I have just reverted the boolean for network access to off. I confirm I am still able to run tomcat.
I should be able to verify the Tibco integration tomorrow to see if they now have access via suitable TLS version.
Just to clarify further, I donât think the bool would prevent tomcat from starting, it MIGHT prevent it from making a network request to another service, but I donât think so.