Working with SELinux and ColdFusion MX in Red Hat Linux 4

Support for Red Hat Enterprise Linux 4 is introduced with the release of ColdFusion MX 7.01. This presents a new security challenge to System Administrators configuring ColdFusion MX for Apache since the SELinux functionality is ACTIVE by default starting with RHEL4. SELinux, or Security Enhanced Linux, is a software product developed by the National Security Agency and has become a standard in Red Hat Linux distributions including RHEL and Fedora Core Linux (FC remains unsupported by CFMX). The most notable problem arises when attempting to configure the webserver to run the ColdFusion connector stub. This problem and a recommended solution are described further below, but first I'll quote from two references regarding the nature of SELinux.

Security Enhanced Linux (SELinux) is a project to provide built-in administrative protection for aspects of your Linux system. Instead of relying on users to protect their files or on a specific network program to control access, security measures would be built into the basic file management system and the network access methods.
...
Linux and Unix Systems normally use a discretionary access control (DAC) method for restricting access. In this approach users and the objects they own, such as files, determine permissions. The user has complete discretion over the objects it owns. The weak point in many Linux/Unix systems has been the user administrative accounts. If an attacker managed to gain access to and administrative account they would have complete control over the service the account managed. Access to the root user would give control over the entire system, all its users, and any network services it was running. To counter this weakness the NSA set up a mandatory access control (MAC) structure. Instead of an all-or-nothing set of privileges based on accounts, services and administrative tasks are compartmentalized and separately controlled with policies detailing what can and cannot be done. Access is granted not just because one is an authenticated user, but when specific security criteria are met. Users, applications, process, files, and devices can be given just the access they need to do their job, and nothing more.
Ref: The Complete Reference: Red Hat Enterprise Linux and Fedora Core 4, pp. 335-336

SELinux is a software product that includes several mechanisms that protect against attacks exploiting software vulnerabilities, including attacks on 0-day vulnerabilities. In particular, SELinux implements role-based access control and sandboxing.
...
SELinux works by associating each program or process with a sandbox known as a domain. Each domain is assigned a set of permissions sufficient to enable it to function properly but do nothing else. For instance, a domain is limited in the files it can access and the types of operations it can perform on those files. To enable specification of such permissions, each file is labeled with information called a security context. The definition of a domain spells out what operations it can perform on files having specific security contexts. A domain cannot access files having security contexts other than those for which it is explicitly granted access.
Ref: SELinux - NSA's Open Source Security Enhanced Linux, pp. 12-13

To begin configuring the Apache webserver for ColdFusion, I previously modified the cf_root/bin/connectors/apache_connector.sh example script to match the locations of the httpd and apachectl executables on my system, and I added a -v switch at the end to output verbose information when run. Here I've run the script and the verbose output was generated. Notice the error at the bottom for Exec'ing /usr/sbin/apachectl restart, apachectl: Configuration syntax error, will not run "restart":

At the same time, the following SELinux security audit message denied was written to /var/log/messages:

The apache_connector.sh script should have restarted the Apache process by running the apachectl command but received the security error above. So I manually attempted to restart Apache but failed on another security error message which was output right on the console:

When attempting to restart Apache above, the corresponding security audit entries were made in /var/log/messages:

Knowing that SELinux was configured to ENFORCING mode on the system, I inspected the security context on the ColdFusion connector module mod_jrun20.so and the httpd binary since the Apache httpd binary will need to load the connector module when starting. If the SELinux security policy has sandboxed httpd to only run files in its security domain, then the mod_jrun20.so module would not be able to be loaded into httpd process unless mod_jrun20.so shared the same security domain.

The system commands ls and ps now have a new switch -Z to show the security context of a file, directory, or process. Using ls -Z [file] I determined that mod_jrun20.so had the security context of root:object_r:usr_t composed of three parts where root is the security id (not the same as system user 'root'), object_r is the security user role, and usr_t is the security domain. Further, Apache's httpd binary had the security context system_u:object_r:httpd_exec_t where the security domain is http_exec_t, and Apache's apachectl binary had a security context system_u:object_r:sbin_t where the security domain is sbin_t .

In order for the Apache httpd binary to load the ColdFusion mod_jrun20.so connector module I would have to change the security domain of the module to be like that of httpd, and this is most easily done with the chcon command where the --reference=[reference file] switch indicates the reference security context to be applied to the target file or directory like so:
chcon --reference=/usr/sbin/httpd \
/opt/coldfusionmx7/runtime/lib/wsconfig/1/mod_jrun20.so.

Notice in the above that the security context of mod_jrun20.so was changed to match the security context of the httpd binary file. SELinux would then permit Apache to start and the httpd process successfully loaded the ColdFusion connector module.

Comments