reuse Selinux Policy
 

Hi I am working on securing apache web server using SELinux on RHEL 5. By default Apache server is installed with OS and when the SElinux is enabled, the httpd_t domain/policy is applied. In my case, we are not using the default apache webserver, instead, we are uninstalling the default webserver and we are compiling it from source. The location of the webserver is /usr/local/apache2214. By default the default SElinux type assigned for all the files/directories under /usr is usr_t. I now want to assign the httpd_t(apache server domain/type) to the my own apache installed at /usr/local/apache2214. I want to reuse the existing selinux rules on my apache.

One of the aspects that keeps installations secure is the fact that Red Hat and therefore Centos use mature package management tools. For instance with the Yum security plugin it is easy to find out when updates are available and if any updates are necessary to maintain a level of security. Compiling SW from source means you no longer have these advantages and you become responsible yourself for keeping it updated.


Unless you have compelling reasons to do so I would advise against using such locations as versions change and using a compile time default prefix of --prefix=/usr/local makes applying SELinux rules easier as well.


That's a catchall, not a generic rule for everything: for instance /usr/sbin/httpd has "httpd_exec_t" and /usr/lib/httpd/modules/ modules have "httpd_modules_t".


Feel free to do so using the 'semanage' command to make changes that stick across relabeling (as opposed to 'chcon'), for instance 'semanage fcontext -a -t httpd_exec_t /usr/local/sbin/httpd' and then restore contexts on these files.

avc denial
 

Hi UnSpawn,

As you have suggested, I have taken the backup of all the files/directories of apache and modified them accordingly to the apache which I have compiled from source located at /usr/local/apache2214. I start the apache and it runs in the domain apache_t(a new domain which I have created). In the domain I created, I have written that the service needs to run on port 80. When I change the port to some other port number for example, 81, the apache should not start and an entry of it needs to be there in audit.log file and an avc denial message should popup, but, in my case, none of these are happening, apache is getting started happily on port 81. I am not able to judge how confined is my apache. I am not able to know what I am missing, to avoid these kind of issues, I wanted a way so that I can reuse the existing domain as per my requirement so that the rules are intact and I dont have much worries. Any help would be great.

On the right distribution all standard tools now support SELinux. This means that files, process, open files and network will that "-Z" and show the context which you then can check.


If you wanted to "reuse the existing domain" then why did you create a domain? Who told you what was the "right" approach? No that it matters, you ignored about everything I wrote anyway.

Clear status
 

Hi Unspawn,

I did not ignore what you said earlier. After looking at your first response, I changed the labels of the the files/folders for the apache I have installed by compiling from source, located at /usr/local/apache2214. I have changed all the labels using "semanage" command and started the apache, it was great to see that the apache started under the domain "httpd_t", but, the problem I got was, I was not getting the AVC denials, as you know that apache is configured to run on port 80 and there is a variable(httpd_port_t) in selinux already defined with value 80. If the apache port is changed to port 81 for example, apache should not start and the AVC denial message should be flashed stating that the port is not authorized. But, in my case that is not happening. Apache is happily starting on port 81 and no denials are happening. I worked on it, but, there was no improvement. I took an another approach of defining a whole new domain like apache_t, and wrote the same set of rules which were written for httpd_t domain and performed labeling of the files/folders accordingly. Even in this approach, apache started in apache_t domain but avc denials were not happening. Then I stopped this approach and again started thinking of re-using the existing domain, so that the transition might be smooth and the domain works as it was supposed to work. Now you know where I stand.

Daemons, before transitioning to their own lesser-privileged account and binding to a port as root user, are allowed reserved port access <1024 as running 'seinfo -p81 -ltcp' should show?:

Create new Boolean Functions and variables
 

Hi UnSpawn,

I have started writing new policy rules for my new apache. I just wanted to know how can we define a new Boolean Rule in our domain. For example for the domain httpd_t , there is an Boolean function like "Allow httpd to access mod_auth_pam". If I have to define the same Boolean in my domain for my customized apache, what should I do.

I also wanted to know how do we define the variables like httpd_port_t which defaults to 80. I wanted to create an variable like apache_port_t, how can I do that.

Why do you seem so bent on entering a world of pain you are not familiar with (yet)? Unless you're a masochist I'd say it's a waste of time as you can reuse the current httpd policy by customizing (labeling files).

Hi UnSpawn,

I have tried re-labelling the files, but, when I start the httpd process it is starting as a unconfined process and avc denials are not happening when the ports are changed.

status
 

Hi UnSpawn,

There are 2 scenarios I am going to represent:

CASE 1:

In redhat 5, we have default HTTPD server already installed which runs perfectly. there are 495 TE rules defined for this service. I have my own apache compiled, located at /usr/local/apache2214. I have analyzed the File labeling done for the default and made similar labeling for my apache and the labeling has been done as follows
/usr/local/apache2214(/.*)? --- httpd_config_t
/usr/local/apache2214/bin(/.*)? --- httpd_exec_t
/usr/local/apache2214/conf(/.*)? --- httpd_config_t
/usr/local/apache2214/htdocs(/.*)? --- httpd_sys_content_t
/usr/local/apache2214/icons(/.*)? --- httpd_sys_content_t
/usr/local/apache2214/modules(/.*)? --- httpd_modules_t
/usr/local/apache2214/logs(/.*)? --- httpd_log_t

After re-labelling, I start the httpd daemon, it starts like an unconfined process.

CASE 2:

I install the SELinux policy editor SEEDIT. To use the editor, we have to initialize it, and durin the process of initialization, it is overwriting all the existing rules which were already there by its own set of rules. For example, for the default httpd there are like 8 boolean functions, all of them are deleted and only one boolean function exists and it says "Disable SElinux monitoring for HTTPD service". Having said that, I open the httpd_t domain and edit the policy by changing the paths of various folders accordingly and compile it. The changes take effect and when I start the service, the httpd service runs under the httpd domain. Since the rules written by seedit for the httpd does not handle many of the security parameters which the default HTTPD domain had, it is not working effectively, For example, I changed the port of apache to 81 and start it, the service starts and there is no denial happening and there is not trace of it in audit.log file.


I hope you understand the situation where I am, I want your advice in how do I proceed in this kind of a situation.

[EDIT]
...done. Works like this:
# Install Apache from source. I use './configure --prefix=/usr/local/apache2'.
# As we already have the httpd RPM installed list the context as it is and as it should be:
# Set the context on the executables:
# ...and the rest:
# ...and make it stick across reboots adding to /etc/selinux/targeted/contexts/files/file_contexts.local:
# That's gonna bite you:
# Check please:
# Edit your httpd.conf, run pre-flight check then start it and check again:
[/EDIT]

HTH

Hi UnSpawn,

Thank you very much for helping me in solving the problem. You have helped me in solving the issue which I was trying almost from 2 weeks. The mistake I committed was with labeling the files incorrectly.