Has Anyone Managed to configure CSP Gateway on CentOS 7 with Apache 2.4 and Secure Enhanced Linux Enabled?

Hi!

I am not system admin. But it used to be very simple to install CSP Gateway on an apache system on Linux with Apache installed. I used to run the CSP Gateway installation program and after it was done, all I had to do was fine tune some configurations on CSP Gateway portal on http://<ip>/csp/bin/Systems/Module.cxw and I was up and running.

But now, with Secure Enhanced Linux (SELinux) things got a lot more complicated. At first, the CSP Gateway portal can't write on CSP.log or CSP.ini files. The documentation that comes on Caché DocBook mentions a "Locked-down" configuration but is incomplete.

The documentation that comes on a word file called "cspGatewayInstallation.doc" that is installed with CSP Gateway on /opt/cspgateway/docs does continue and instructs us to use semanage (an utility from SELinux) to change some settings of /opt/cspgateway/bin folder and CSP.ini/CSP.log files. But this doesn't work at all.

CSP Gateway will refuse to work properly until I completely disable SELinux on the box. Then, everything works just like before. Perfectly.

I feel the steps for configuring CSP Gateway on a SELinux enabled box on both DocBook and on 

cspGatewayInstallation.doc are incomplete and assume too much about the reader.

Can anyone share the steps taken to configure CSP Gateway on a CentOS/RedHat Linux box with Apache 2.4 and SELinux enabled?

  • 0
  • 0
  • 584
  • 2
  • 3

Answers

did you try to move CSP modules into Apache directory as recommended in documentation?

 

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

I have not. In fact, I don't want to do it because I want to install the csp gateway under a folder called /aupoldb/cspgateway instead of /opt/cspgateway.

That is because this folder is a logical volume system (lvs) and the plan is to have a snapshot of aupoldb file system (that is mounted on /aupoldb and includes caché on /aupoldb/cache and CSP Gateway on /aupoldb/cspgateway) before any patching so we can quickly rollback the entire filesystem if anything goes wrong with the patching.

Apache default installation is on /etc/httpd that is on the root logical volume. I wasn't planing on doing a snapshot of the root logical volume when patching Caché or CSP Gateway. At most, I would be saving httpd.conf before doing it as part of the backup procedure...

httpd_sys_content_t only allows httpd to read the files.  To read and write to them it should be httpd_sys_rw_content_t such as:

chcon -t httpd_sys_rw_content_t /opt/cspgateway/bin/CSP.log

chcon -t httpd_sys_rw_content_t /opt/cspgateway/bin/CSP.ini

In trying to run CSP and Cache on the same server I also ran into the issue that httpd was not being allowed to connect to port 1972.  The quickest fix was to turn on the SELinux boolean allowing httpd to establish network connections:

setsebool -P httpd_can_network_connect on

A more security-restrictive option (that I haven't tested) may be to change the SELinux type of port 1972 from unreserved_port_t to http_port_t.  But I'm not sure if this would have any other impact on Cache...

semanage port -m -t http_port_t -p tcp 1972

On a minimal install RHEL7.4 server, with SELinux enabled and set to enforcing, I installed TrakCare on HealthShare 2016.1.

These are the commands I ran to get TrakCare working:

CSP Gateway:

semanage fcontext -a -t httpd_sys_rw_content_t /opt/cspgateway/bin/CSP.ini
restorecon -v /opt/cspgateway/bin/CSP.ini
semanage fcontext -a -t httpd_sys_rw_content_t /opt/cspgateway/bin/CSPRT.ini
restorecon -v /opt/cspgateway/bin/CSPRT.ini
semanage fcontext -a -t httpd_log_t /opt/cspgateway/bin/CSP.log
restorecon -v /opt/cspgateway/bin/CSP.log

TrakCare web application files:

semanage fcontext -a -t httpd_sys_rw_content_t "/trak/site/env/web(/.*)?"
restorecon -Rv /trak/site/env/web/

If SELinux is enabled and the policycoreutils-python package is installed before HealthShare is installed then I did not have to run the following command.

semanage port -a -t http_port_t -p tcp 1972

To check if the superserver port is allowed you can run this:

semanage port -l | grep -w http_port_t