Posts Tagged ‘SELinux’

Fedora 16 with SELinux running WordPress with Akismet

June 17, 2013

So you have WordPress and Akismet to get rid of spam. But for some reason Akismet is not working:

WordPress with Akismet failing

You can test if you have a valid key and connectivity from the command line with either wget:

wget --post-data 'key=YOURKEYGOESHERE&blog='\

or using curl:

curl -d 'key=YOURKEYGOESHERE' -d 'blog=' \

If it works you should receieve a file called “verify-key” containing the word “valid”

If that doesn’t work then you have problems outside the scope of this article.

But if you can retrieve the key than chances are your SELinux configuration is limiting what the httpd server can do.

Luckily the fix is simple: allow httpd to make outgoing connections:

setsebool -P httpd_can_network_connect on

But wait a minute you say. Now my httpd server can connect to anything, attackers can use it to attack other systems potentially (especially if you allow CGI scripts and arbitrary WordPress plugins or themes which can contain PHP code).

So we need to limit what systems the httpd server can connect to. The good news here is that IPTables supports this.

In the case of Akissmet you’d want to add something like this to your /etc/sysconfig/iptables file:

-A OUTPUT -m owner --uid-owner apache -m tcp -p tcp --dport 80 \
--dest -j ACCEPT
-A OUTPUT -m owner --uid-owner apache -m tcp -p tcp --dport 80 \
--dest -j ACCEPT 
-A OUTPUT -m owner --uid-owner apache -m tcp -p tcp --dport 80 \
--dest -j ACCEPT
-A OUTPUT -m owner --uid-owner apache -m tcp -p tcp --dport 80 \
--dest -j ACCEPT
-A OUTPUT -m owner --uid-owner apache -j REJECT

This should allow only existing inbound connections (e.g. web clients) and outgoing connections to Akismet (you may want to add any other services you use of course).

Fedora 16 with SELinux running WordPress with WP Super Cache

January 4, 2012

Updated (Jan 5, 2012): chcon changes the SELinux security on a file, but a restorecon would wipe that out, you need to actually run semanage to change the policy, then run restorecon to make it “permanent”.  Thanks to [email protected] for pointing this out to me.

So I recently started upgrading all the CloudSecurityAlliance web servers from F14 (with SELinux enabled) to F16 (with SELinux enabled). But I ran into a nasty little problem, WP Super Cache was broken. The error message that came up was:

Error: Your cache directory (/var/www/html/wp-content/cache/)
or /var/www/html/wp-content need to be writable for this
plugin to work. Double-check it.

Cannot continue... fix previous problems and retry.

Well shoot. The file permissions were correct, apache had write permissions and so on to the directory. But it was unable to write… Ah.. must be SELinux. The quickest way to test this is to simply disable SELinux for a second:

setenforce Permissive

and reload the WP Super Cache control page. Ah it works. So we know it’s an SELinux problem. The good news is that this is easy to fix, simply set the label on the directories and files you want the httpd process to be able to write to (and don’t forget to re-enable SELinux after you disabled it in the previous step):

You can use chcon to change the content on the directories:

chcon -R -t httpd_sys_rw_content_t /var/www/html/wp-content/cache/
chcon -R -t httpd_sys_rw_content_t /var/www/html/wp-content/plugins/
chcon -R -t httpd_sys_rw_content_t /var/www/html/wp-content/themes
chcon -R -t httpd_sys_rw_content_t /var/www/html/wp-content/uploads/
chcon -t httpd_sys_rw_content_t /var/www/html/wp-content/wp-cache-config.php

For a more permanent change however use semanage to change the targeted policy:

semanage -S targeted -i - << _EOF
fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/cache(/.*)?
fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/uploads(/.*)?
fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/plugins(/.*)?
fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/themes(/.*)?
fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/wp-cache-config.php
fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/themes(/.*)?
fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/blogs.dir(/.*)?
restorecon -R -v /var/www/html

Also you may want to add “/var/www/html/wp-content/blogs.dir(/.*)?” so that WordPress multi-site uploads work properly.

Be mindful of selinux policy updates, they shouldn’t overwrite the changes you made but you may want to in order to get the latest greatest policies. Also you probably won’t have semanage installed:

yum install policycoreutils-python

Ok that was easy. But how do we find out what label needs to be applied? Well the ls command can give us a hint:

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

So we’re dealing with httpd (obviously, but for other servers and services it may not be as simple so I’m doing this step by step). We can check for httpd related contexts using grep:

grep httpd /etc/selinux/targeted/contexts/files/file_contexts

Which will return a huge list of stuff. If you examine the output however you will notice lines like:

/var/lib/drupal.*       system_u:object_r:httpd_sys_rw_content_t:s0
/var/cache/mediawiki(/.*)?      system_u:object_r:httpd_cache_t:s0

So it would appear we have two main choices: httpd_sys_rw_content_t and httpd_cache_t. There are a number of other related labels as well: httpd_mediawiki_rw_content_t, httpd_git_rw_content_t, httpd_bugzilla_rw_content_t, httpd_mojomojo_rw_content_t and httpd_dspam_content_rw_t to name a few. Any of these will work, but I chose httpd_sys_rw_content_t as it;s rpetty obvious as to what it is for at first glance.

For more details on Red Hat Enterprise Linux (this also applies to Fedora) with SELinux and confined services check the Red Hat documentation: