1

We have a web service written in java (using Axis 1.4). We access this in c++ code using gSOAP (2.8.101). We are using OpenSSL (1.1.1e). On RHEL 8 we are seeing the SOAP 1.2 fault. The error is as below: SOAP 1.2 fault: SOAP-ENV:Receiver [no subcode] "Permission denied" Detail: connect failed in tcp_connect()

The same code works good in RHEL7. Any suggestions on how to fix this?

Luka
  • 1,718
  • 3
  • 19
  • 29
Madhu Gowda
  • 13
  • 3
  • There are still missing details about your setup, and people cannot help you properly without them. If you have SELinux enabled, have you checked your system and audit logs yet? Also, you can try temporarily disabling SELinux by executing `setenforce 0` to rule out the cause of the problem more easily. – Luka May 12 '20 at 09:18
  • Thanks, setting to 'permissive' mode solved the issue. But, we want it to be in 'enforcing' mode. – Madhu Gowda May 12 '20 at 10:21
  • Of course, I didn't mean you leave it disabled. The point has been to conclude that SELinux is the problem. Now you need to take a look at your audit logs to see which boolean you need to enable to make SELinux allow the connection. Can you show me the line in your audit log where your application is denied access to the TCP socket? – Luka May 12 '20 at 10:26
  • This is the line from audit.log: type=AVC msg=audit(1589295399.787:1515): avc: denied { name_connect } for pid=30416 comm="httpd" dest=8080 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_cache_port_t:s0 tclass=tcp_socket permissive=0 – Madhu Gowda May 12 '20 at 16:47
  • Try the following command: `setsebool -P httpd_can_network_connect on`, as I have stated in my answer below. – Luka May 12 '20 at 17:11
  • Thank you very much.... This solved the issue. – Madhu Gowda May 12 '20 at 17:31
  • With little change in our setup, we are seeing different error, as SOAP 1.2 fault: SOAP-ENV:Receiver [no subcode] "Connection refused" Detail: connect failed in tcp_connect() This time the Apache httpd server is built from source code (version 2.4.37) We set the enforcing to 'Permissive' (setenforce 0), but, still got same error. There is no info about this error in 'error_log' The 'audit_log' and 'access_log' also donot have logs related to this error – Madhu Gowda Jun 29 '20 at 15:46

1 Answers1

0

It seems as if SELinux is blocking the connection. To temporarily allow the connection, you can use setenforce 0. This won't survive a server reboot, so if you'd like it to survive, you need to set SELinux to work in permissive mode in /etc/selinux/config.

To continue working in enforcing mode, depending on the application, there might be a built-in SELinux policy to allow the connection you need with SELinux set to enforcing just by enabling an appropriate boolean. You can get the list of all SELinux booleans by executing:

getsebool -a # List all available SELinux booleans on your system

For example, to allow the HTTPD scripts and modules to connect to the network, enable the following SELinux boolean:

sudo setsebool -P httpd_can_network_connect on

If you don't want to allow HTTPD to connect to any port, you can use an appropriate boolean:

sudo setsebool -P httpd_can_network_connect_db on

This will allow HTTPD to connect to the database over the network. If there's no appropriate boolean for you to enable, you'll have to build your own policy. You can do that using the audit2allow -M command. For example, if your command that generates an error in your audit.log is httpd, you can do the following:

sudo ausearch -c 'httpd' --raw | audit2allow -M my-policy
sudo semodule -X 300 -i my-policy.pp

Usually, it's not a good practice to use audit2allow to allow access for a service if there's a built-in boolean available for that service. Use audit2allow as your last resort if there is no appropriate boolean for your paticular service.

Luka
  • 1,718
  • 3
  • 19
  • 29