Unleash your inner root

Getting RequestTracker 4 to work with SELinux

Fighting with SELinux can be a tough thing in the IT world. Documentation for it is often fairly focused on a given problem, and generally explains THAT a given action fix’s something, rather then WHY a given action fix’s something. As such when you hit a wall with an application that there is no existing documentation for resolving, often the only thing you can find is “Just disable SELinux” people aren’t generally too interested in resolving SELinux issues… That was my situation when setting up a new server to run RequesTracker 4… However, After some head banging, I managed to come up with a winning combination that has made everything work.

This tutorial will not explain setting up RT4, there are tons of those already in existence. This will focus on taking a working install of RT4, and getting it to function with SELinux set to enforcing.

A few Quick Things

First) My install of RT is under /var/www/rt-live, you will obviously need to modify your paths depending on your environment.

Second) While I have managed to make this work, My understanding of SELinux is still rudimentary at best. This is a combined set of changes that made things function, It is possible that some of these changes are unneeded. Someday I may go back and try to refine these down, but for the time being. These work, and as far as I’ve been able to find there is literally no one else on the internet that has come up with a working solution.

The Solution

Setting Proper Context’s

Step one is simply to fix’ a few context issues for APACHE to be able to properly run the scripts necessary for the site to function. This part was fairly straight forward. Basically we are setting the file contexts for the sbin/bin files to be executable in SELinux.

In this step, we are also making html/Admin director files writable, this is a necessary change to allow updates to be pushed from the webgui.

# These fix the basic executable rights of the site
semanage fcontext -a -t httpd_sys_script_exec_t "/var/www/rt-live/sbin(/.*)?"
semanage fcontext -a -t httpd_sys_script_exec_t "/var/www/rt-live/bin(/.*)?"

# This fix's the write attribute of the admin directory, and resolves a few errors that pop up while using the site. 
# Without this the site appears to function, but throws up errors whenever things are changed.
semanage fcontext -a -t httpd_sys_rw_content_t/var/www/rt-live/share/html/Admin(/.*)?

# Finally we use restorecon to update all the changes we've made. semanage fcontext sets the default values in
# SELinux, but does not update the current file contexts
restorecon -R /var/www/rt-live/sbin
restorecon -R /var/www/rt-live/sbin
restorecon -R /var/www/rt-live/share/html/Admin

# This last one I'm fairly certain isn't necessary, I would recomend flipping this boolean only if you complete everything in this entire page, and things still aren't working.
setsebool -P httpd_can_sendmail 1
Fixing Postfix

Above should get your basic site functioning, however you will still be unable to generate new tickets from incoming emails. This is because incoming emails are tagged with a context of “postfix_local_t” which does not have the ability to cross over into httpd_sys_content_t, or httpd_sys_script_exec_t

The following is a module file, You should create a file with it’s content named “my-mailgate.te” It contains new rules for allowing the postfix_local_t context to touch the httpd context’s

module my-mailgate 1.0;

require {
        type httpd_sys_content_t;
        type httpd_sys_script_exec_t;
        type postfix_local_t;
        class dir search;
        class file { execute execute_no_trans open read ioctl};

#============= postfix_local_t ==============

#!!!! This avc is allowed in the current policy
allow postfix_local_t httpd_sys_content_t:dir search;
allow postfix_local_t httpd_sys_content_t:file { execute open read };

#!!!! This avc is allowed in the current policy
allow postfix_local_t httpd_sys_script_exec_t:dir search;
allow postfix_local_t httpd_sys_script_exec_t:file { execute execute_no_trans open read ioctl};

So basically we are adding allow rules for postfix_local_t to search directories of httpd_sys_content_t, and httpd_sys_script_exec_t, as well as allowing postfix to execute/execute_no_trans/open/read the files marked as httpd_sys_script_exec_t

It is somewhat complicated, but basically, SELinux is all about managing sandbox’s. Each application exists as it’s own sandbox, and the applications are only allowed to play in other sandbox’s based on some very strict rules. You can learn these rules by watching things fail, and reading what happens in the journalctl, or with the “ausearch -m AVC,USER_AVC -ts recent” command, and looking for “denied” messages,

For example:

time->Fri Feb 23 11:21:36 2018
type=PROCTITLE msg=audit(1519413696.182:185): proctitle=6C6F63616C002D7400756E6978
type=SYSCALL msg=audit(1519413696.182:185): arch=c000003e syscall=59 success=no exit=-13 a0=562ae94bada0 a1=562ae94baef0 a2=562ae94bab30 a3=4 items=0 ppid=3425 pid=3426 auid=4294967295 uid=99 gid=99 euid=99 suid=99 fsuid=99 egid=99 sgid=99 fsgid=99 tty=(none) ses=4294967295 comm="local" exe="/usr/libexec/postfix/local" subj=system_u:system_r:postfix_local_t:s0 key=(null)
type=AVC msg=audit(1519413696.182:185): avc:  denied  { search } for  pid=3426 comm="local" name="bin" dev="dm-0" ino=795914 scontext=system_u:system_r:postfix_local_t:s0 tcontext=unconfined_u:object_r:httpd_sys_script_exec_t:s0 tclass=dir

This entry is denying postfix_local_t the “search” for httpd_sys_script_exec_t, directories. The confusing thing about developing a solution is, you will often only see one error type at a time, and cannot see the next failure until after a fix is made. So it is a matter of seeing a failure, writing a module, installing the module, seeing a new failure, and updating the module as you go along, until no more failures pop up.

Anyway, moving on to compiling your .te file.


# First generate a .mod file with checkmoduel
checkmodule -M -m -o my-mailgate.mod my-mailgate.t

# Next you compile the mod into a .pp with semodule_package
semodule_package -o my-mailgate.pp -m my-mailgate.mod

# Finally install the module
semodule -i my-mailgate.pp

Once your module is installed, you will need to restart apache

systemctl restart httpd

And that should be all there is to it!


Brandon.Graves • February 23, 2018

Previous Post

Next Post

Leave a Reply

Your email address will not be published / Required fields are marked *

%d bloggers like this: