Leaving SELinux in enforcing mode with Evergreen on Fedora 17

Posted on Sun 02 September 2012 in Libraries

Ever since I switched over to Fedora a few years back (hi Fedora 13!), I've been guilty of a dirty secret: to run Evergreen, I've had to run setenforce 0 to disable the most excellent SELinux security policies before I could start up the Apache web server to serve up the Evergreen goodness. This worked for development purposes, but tonight something snapped and I decided that it was no longer acceptable to throw away a great layer of operating system security simply for the sake of hacking on Evergreen. So... I stepped into the world of what had formerly seemed to be inscrutable SELinux concepts, and came out with something that seems to work (at least for my fairly limited purposes thus far of searching the TPAC catalogue).

This was a pretty iterative process that involved trying to start the httpd.service, then checking /var/log/messages and /var/log/audit/audit.log for clues as to why httpd.service was either not starting, or (once I passed that hurdle) was simply returning internal server errors.

First, due to my recent experience with running a web.py script under Fedora, I had learned that the httpd SELinux policy had a number of booleans for enforcing or allowing particular behaviours, so I immediately ran the following command to enable httpd to connect to the network:

setsebool httpd_can_network_connect on

I then needed to change the labels on many of the OpenSRF and Evergreen files that were installed and which Fedora gave a default type of unconfined_t, which is understandably restrictive:

# Mark web content as, well, web contentchcon -R --type=httpd_sys_content_t /openils/lib/javascriptchcon -R --type=httpd_sys_content_t /openils/var/webchcon -R --type=httpd_sys_content_t /openils/var/templates*chcon -R --type=httpd_sys_content_t /openils/var/datachcon -R --type=httpd_sys_content_t /openils/var/xslchcon --type=httpd_sys_content_t /openils/conf/opensrf_core.xmlchcon --type=httpd_sys_content_t /openils/conf/fm_IDL.xml # Mark the custom Apache modules chcon --user=system_u --type=httpd_modules_t /usr/lib64/httpd/modules/mod_xmlent.so chcon --user=system_u --type=httpd_modules_t /usr/lib64/httpd/modules/osrf_*# Mark the dynamic libraries we need to load# "-h" changes the context of symlinks as well as fileschcon -h --type=lib_t /openils/lib/*# Mark executable scriptschcon -t httpd_sys_script_exec_t /openils/bin/openurl_map.pl chcon -t httpd_sys_script_exec_t /openils/bin/offline-blocked-list.pl # Might not have been necessarychcon -R --user=system_u /usr/local/share/perl5/chcon --user=system_u /etc/httpd/conf.d/eg.conf chcon --user=system_u /etc/httpd/startup.pl chcon --user=system_u /etc/httpd/eg_vhost.conf chcon -R --user=system_u /etc/httpd/ssl/

*Note:* I'm aware that simply running chcon won't survive a relabelling of the files. We really need to turn this into a policy, or alternately use semanage to make the changes permanent...

Next, I opted to finally start running Apache as the stock apache:apache user/group rather than as the opensrf user. This turned out to require only a few steps:

  1. Change the User setting in /etc/httpd/conf/httpd.conf back to apache, reverting the change we made following the default install documentation.

  2. To avoid errors writing to the /openils/var/log directory, cut over to using syslog - which, on Fedora, is provided by rsyslogd.

    1. Copy the very handy Open-ILS/examples/evergreen-rsyslog.conf file that Bill Erickson created into /etc/rsyslog.d/
    2. Restart the rsyslogd service with systemctl restart rsyslog.service.
    3. Edit /etc/httpd/eg_vhost.conf and /openils/conf/opensrf_core.xml to use syslog instead of writing to log files.
    4. Restart the OpenSRF services.

  3. One more restart of the httpd service and I was in business.

So this is a start. I think this has broader implications than for just Fedora; we should stop using the opensrf user to run the Apache service in the default configuration on all distributions (we've discussed this several times in the past, but never really done anything about it).

I hope to update the README accordingly, and I also hope to take the SELinux work a step further to provide a modified policy so that Fedora and Red Hat (and derivative) distributions can offer a more secure environment for running Evergreen.

Oh, and some handy resources:

Evergreen evergreen