Category Archives: LAMP

Study Case: Apache and SELinux

Now that you can check and see SELinux contexts, let’s understand these contexts with a study case. We’ll go with an apache case since apache is a commonly used server.

First, you need to know that SELinux targeted policy has many rules deciding which process could read/access to file or bind to a port. Apache has its own context, ports, files do too.

The goal of this article is to help get your hand on SELinux and it’s not a recommanded recipe to deploy your web server with SELinux, I’ll write about it later :p

  • Bind to an uncommon port:

Suppose you need Apache to listen on some unusual port than 80 or 8008, you go to your configuration file and alter it with your new port number on the Listen directive(ex:9000), then your restart your server.

Here is the surprise, you can’t start your Apache or force binding to your new port:



Depending on your Linux distru, check your logs, look for lines in audit.log containing type=AVC and string denied:

[root@sar ~]# tail -n 2 /var/log/audit/audit.log



Using semanage command, you can check ports apache could listen to, you won’t find 9000:



You can see that the type http_*_t type context isn’t allowed to listen on ports other than 80,443,8080,…


No process (type) can access a port/file or other objects if there is not a SELinux rule allowing it.


So you need either to give apache the right to access 9000 port by adding this port to ports used by http_port_t type:

#semanage    port    -a    -t   http_port_t   -p   tcp    9000

or simply use a port listed with “semanage port   -l | grep http” , and I prefer the last one.


  • Use a DocRoot other than the default /var/www:


Well, I’ll go on with port 80. And now I would like to create a vhost for my selinux tutorial and I would like to have my DocumentRoot hosted on the home directory of setuto user (just an example).

I configure my vhost as follows:



Now I reload my apache, surprise: my apache couldn’t see the documentRoot for my newly created vhost:



Checking the audit.log, you can easily see that the denial is due to SELinux restrictions:

[root@sar ~]# tail -n 2 /var/log/audit/audit.log



To be sure, use the audit2allow command to check SELinux denials. Now I can find two denials, the first when we used port 9000 and the second when we gave apache a DocumentRoot it’s not allowed to access:

[root@sar ~]# audit2allow -l -a



Let’s see why my Apache couldn’t see the directory /home/setuto/www although it exists:

Apache uses the bin file /usr/sbin/httpd , use the following command to check which bin is used by your process:

[root@sar conf.d]# ps faux| grep [h]ttpd


Let’s see httpd and my vhost home SELinux context:

[root@sar conf.d]# ls   -lZ  /usr/sbin/httpd


[root@sar conf.d]# ls -lZ /home/setuto/www/


You can see from the outputs that SELinux type (or domain) for httpd is httpd_exec_t and for the vhost home directory : user_home_t.

Clearly httpd_exec_t can’t access user_home_t.


There are many things you can do to manage this issue:


  1. You can change the SELinux type of /usr/sbin/httpd to a type which has the right to access anything: unconfined_*_t, by using:

#chcon    –t     unconfined_exec_t    /usr/sbin/httpd

And it’s too dangerous, since unconfined types could access anything, once your apache is compromised, malicious users can use it to do whatever they want with your system.


  1. Or you can simply change the SELinux type of your vhost home to be httpd_sys_content_t same as the type of default DocumentRoot used by your apache which is commonly /var/www/ :

[root@sar conf.d]# ls    -lZ   /var/www/


By using following commands:

[root@sar conf.d]# chcon  -t httpd_sys_content_t   /home/setuto/www

Check then:


Updates of SELinux context done using chcon are not persistent see “Tips”

By doing this there may be some restrictions forbidden some access to /home/setuto/www since its type is httpd_sys_content_t, think of other processes using this directory. It’s not really recommanded


  1. Or may be you can follow audit2allow advices, let’s see them again:

[root@sar ~]# audit2allow -l -a



So you can either add a rule allowing httpd_t type to access user_home_dir_t . The rule will state the line allow httpd_t user_home_dir_t:dir { search getattr }; (see how to create customized SELinux policy modules)

Or simply activate the rule/Boolean httpd_enable_homedirs allowing apache to access home directories, using the command:

setsebool -P httpd_enable_homedirs on      (-P switch to make persistent changes)


To check httpd_enable_homedirs boolean status use getsebool as follows:

getsebool -a | grep httpd_enable_homedir


To see what this rule/Boolean is for, use command semanage as follows:

[root@sar setuto]# semanage boolean -l | grep httpd_enable_homedir



As you can see there is not a unique solution, everything depends on your own policy :p, although I personally prefer audit2allow advices 🙂

I hope this article helps you to see clearly what SELinux are for and how you can manage issues resulting from a bad SELinux configuration by spotting the root cause.

Whenever you can’t run something and you’re sure about your configuration, check SELinux denials, and use semange command to view detailed information and resolve your issue.

Cosmic Birth,



I’m a Mozilla Firefox user and I love it. One of the most awesome adds is Firebug. You can use it to debug your long time taking website or debug your JavaScript codes.

As for me, I used with clients. I get a lot of clients calls asking me why their sites are taking too much time to load. Almost all the time, the web server is well performing and the machine load is normal. But still the client won’t understand unless you show them “evidences”. And that’s what Firebug are for :D. It saves my life when at phone the client won’t believe in you LOL.

I run the site and Firebug at the same time:


Then I choose the net tab, all and look for the HTTP request/object taking too long to load. I point the cursor on and get the beautiful graphics breaking the time the query took into pieces of:

1- Horizontal and colorful graphics:


  • Blocking: The time that your environment takes to open a TCP connection
  • DNS lookup: The time name resolution takes,
  • Connecting: The time needed to establish a connection with the server. Here, you can notice the difference between having a keep alive connection and none.
  • Sending: Time needed to send the request to the web server,
  • Waiting:Time needed to receive the first byte/answer from the web server,
  • Receiving: Time needed to download the response/object from the server.

If the web server is taking too long to process your request then you should be able to spot it, just notice the “waiting time” value.

2-Vertical time lines:


The DomContentLoad and the load time. If you have some JavaScript code running on your website, these lines help you understand how JS events are fired.

This post: “Page load analysis” is a very good and detailed about Firebug and it goes with code simulation of many cases,