Relocating an Apache DocumentRoot under Selinux

Selinux works pretty well straight out of the box, but I have learnt that when application reconfigurations mysteriously result in failures to startup – then Selinux is generally the culprit. In particular, if any file locations are customised from what’s installed, Selinux will lock it down, and for the uninitiated, the debugging process can be quite confusing. Apache webserver (HTTPD) provides a good example of what happens in this scenario, and I’ll demonstrate how to make it work with the Document Root in a different location.

Selinux can be distinctly daunting for Linux sysadmins, and often seems to be more trouble than it’s worth. However it is an extremely powerful tool which increases security and encourages rigour in configuration. Essentially, Selinux augments the usual Unix file permissions and ownership by adding more granular application-specific contexts as well. I won’t go into the details here, as it’s well documented elsewhere.

What I’ll aim to show here is two ways for relocating the Apache DocumentRoot directory – the proper way, and a quicker dirtier way.

Say, you decide to situate the Apache webserver root under /home/apache/www instead of the default /var/www/html. You edit the /etc/httpd/conf/httpd.conf and change the DocumentRoot line to:

DocumentRoot /home/apache/www

Copy your HTML files into place, change the directory and file onwerships, and permissions:

# chown -R apache. /home/apache/www
# chmod 755 /home/apache/www
# chmod 644 /home/apache/www/*

(NB: That’s not a typo – you can type “apache.”, with the dot at the end, in chown rather than “apache:apache” and save yourself a few keystrokes).

Restart httpd to make sure, and browse to your web page. You’ll get something like this in your browser:

Forbidden
You don't have permission to access / on this server.

And in /var/log/httpd/error_log:

[client 10.65.140.97] (13)Permission denied: access to /index.html denied

This is because the Apache back-end process, running as user “apache”, can’t access the file /home/apache/www/index.html – even though we granted all the correct permissions. What gives? Turns out, with Selinux, having regular old permissions and ownership isn’t enough.

Here’s how you can fix this, nice and quickly.

First things first, check that you’ve got Selinux running, and that this is in fact the source of your problem:

  # getenforce
Enforcing

Yep. Next, check the Selinux context of the original HTTPD DocumentRoot directory. The ls command has the “-Z” switch which displays this:

# ls -ldZ /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html

Take note of the colon-delimited string “system_u:object_r:httpd_sys_content_t:s0″. Take note of this string; you’ll need it later. Each field is:

  • User: system_u
  • Role: object_r
  • Type: httpd_sys_content_t
  • Level: s0

Checking the Selinux context on our new erroneously configured folder, we see this:

# ls -Z file1
drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 /home/apache/www

So this explains why Apache can’t read the index.html file – it’s got the wrong Selinux context for Apache to read it. You can see how this enhances security. Apache can never server up a page unless it has explicitly got a context set that matches Apache privilege.

To reset the directory and file contexts, you need to ensure that the semanage software is installed (it may not be, depending on what package groups you have):

  # yum whatprovides */semanage
  # yum -y install policycoreutils-python

A very full discussion of how to change Selinux policies and file contexts is given here, but briefly, the steps are:

  # semanage fcontext -a -t httpd_sys_content_t "/home/apache/(/.*)?"
  # restorecon -Rv /home/apache
restorecon reset /home/apache context unconfined_u:object_r:var_t:s0->system_u:object_r:httpd_sys_content_t:s0
restorecon reset /home/apache/www context unconfined_u:object_r:var_t:s0->system_u:object_r:httpd_sys_content_t:s0
restorecon reset /home/apache/www/index.html context unconfined_u:object_r:var_t:s0->system_u:object_r:httpd_sys_content_t:s0

The semanage argument “/home/apache/(/.*)?” is a regular expression indicating the context should apply to the directory “/home/apache” and everything under it. Yes you need to do this for the home directory as that stays in user_sys_content. Unless you change that the https will still complain.

Quick and Dirty Fix
If, however you don’t have access to the semanage program or if you just need to make a small ad hoc change to a file context, you can simply set this manually. Remember that string coloured red earlier? Grab the relevant text from it.

  # chcon -R -u system_u -t httpd_sys_content_t /home/apache/

This command uses the “-R” switch so will apply recursively to all files under the directory. Note that the difference between this command and the semanage command is that chcon will not update the Selinux policy.

So the proof of the pudding will be in the reloading. Ctrl-R your browser and BOOM! Your page is back and being happily server up.

Install gnupg php extension in centos

All commands ran via SSH as root from /root. If you get “No package available” errors, you probably need to install the EPEL repositories.

yum install libgpg-error yum install libgpg-error-devel yum install gpgme yum install gpgme-devel yum install pygpgme pecl install gnupg

You will then need to edit your /usr/local/lib/php.ini file and verify/insert the extension=gnupg.so line. If this line isn’t already in the file, just add it at the bottom. Run php -m and look for a gnupg line. Next run php -r "phpinfo();". You should see something like:

gnupg support => enabled GPGme Version => 1.1.8 Extension Version => 1.3.2-dev

Then you’ll just need to restart the web server .

How to Create a SSL Certificate on Apache for CentOS 6

About Self-Signed Certificates


A SSL certificate is a way to encrypt a site’s information and create a more secure connection. Additionally, the certificate can show the virtual private server’s identification information to site visitors. Certificate Authorities can issue SSL certificates that verify the virtual server’s details while a self-signed certificate has no 3rd party corroboration.

Step One—Install Mod SSL


In order to set up the self signed certificate, we first have to be sure that Apache and Mod SSL are installed on our VPS. You can install both with one command:

yum install mod_ssl

 

Step Two—Create a New Directory


Next, we need to create a new directory where we will store the server key and certificate

mkdir /etc/httpd/ssl

 

Step Three—Create a Self Signed Certificate


When we request a new certificate, we can specify how long the certificate should remain valid by changing the 365 to the number of days we prefer. As it stands this certificate will expire after one year.

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/httpd/ssl/apache.key -out /etc/httpd/ssl/apache.crt

With this command, we will be both creating the self-signed SSL certificate and the server key that protects it, and placing both of them into the new directory.

This command will prompt terminal to display a lists of fields that need to be filled in.

The most important line is “Common Name”. Enter your official domain name here or, if you don’t have one yet, your site’s IP address.

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:NYC
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Awesome Inc
Organizational Unit Name (eg, section) []:Dept of Merriment
Common Name (e.g. server FQDN or YOUR name) []:example.com                  
Email Address []:webmaster@awesomeinc.com

 

Step Four—Set Up the Certificate


Now we have all of the required components of the finished certificate.The next thing to do is to set up the virtual hosts to display the new certificate.

Open up the SSL config file:

 vi /etc/httpd/conf.d/ssl.conf

Find the section that begins with <VirtualHost _default_:443> and make some quick changes.

Uncomment the DocumentRoot and ServerName line and replace example.com with your DNS approved domain name or server IP address (it should be the same as the common name on the certificate):

 ServerName example.com:443

Find the following three lines, and make sure that they match the extensions below:

SSLEngine on
SSLCertificateFile /etc/httpd/ssl/apache.crt
SSLCertificateKeyFile /etc/httpd/ssl/apache.key

Your virtual host is now all set up! Save and Exit out of the file.

Step Five—Restart Apache


You are done. Restarting the Apache server will reload it with all of your changes in place.

 /etc/init.d/httpd restart

In your browser, type https://youraddress to view the new certificate.

Debugging .htaccess

Debugging .htaccess is at time shooting in dark. I had gone through one such day where every thing makes sense but it does not work. I had outlined the step i used to find out the bug.

Add a Garbage inside the .htaccess to see whether you get Server Error. If you get a server error it is working

<IfModule mod_rewrite.c>

#Options +FollowSymlinks

This is Garbage and should result in failure

RewriteEngine On
RewriteBase /
RewriteRule ^(.*$ /deubg.php?$1 [QSA]
</IfModule>

If you get a server error then there is some problem in the your .htaccess config. You can try the online .htaccess tool to debug the same

http://htaccess.madewithlove.be/

If you do not get a .htaccess error then .htaccess is not read by the Apache

  1. Open the Apache configuration file located at /etc/httpd/conf/httpd.conf
  2. Change AllowOveride None to AllowOveride All inside the DocumentRoot Directory Directive, normally<Directory “/var/www/html”>
This will allow the directives to be modified.