We’ve been working recently on security, in this particular document we’re focussing on wordpress file and directory permissions.
nn
This is a working document, which should be subject to updates and revisions
nn
Firstly, there is no reason that I can find..that any of the files or directories in a wordpress installation should be world readable, so to that effect we can assume all permissions will end in a “0”, removing any world-readable permissions.
nn
Secondly, we shouldn’t have the web user (apache, http, www-data for example) owning any of the files. In the very least a human should own the files in the web root, and the web process user should be accessing based on group permissions. The reason for this is, the owner can change file permissions as he wishes..which may well be undesirable in the event that a malicious script is executed for example. Additionally, we want the user to be able to write to files..whereas the web server process usually only a needs to *read* files. So in the very first place we’d do About something like this
nn
[plain]chown -R (your username):(web server group) /path/to/webroot/[/plain]
nn
so in the case of my system, I’d perhaps do something like this:
nn
[plain]chown -R dcr226:apache /var/webroot/www[/plain]
nn
So onto actual permissions for these user/group combinations. As stated before, there is no good reason to have anything in the webroot world readable. So from an overarching perspective, files can How be 640 and directories 750. To explain how this works:
nn
Files – 640 permission
nn
Owner has read/write access (in this case a human owner, *not* the web server) (rw)
nn
Group members have read access (in this case the web server’s user – perhaps apache, httpd or www-data) (r)
nn
Everyone else has no access whatsoever (-)
nn
Directories – 750 permission
nn
Basically the same as above, with the exception that directories need to execute in order to change directory, etc. So both the owner and group get execution permissions (rwx)
nn
Fixing the file permissions:
nn
So, now we know what file permissions we want to issue..its time to do the work. This can be done as follows:
nn
[plain]find /path/to/webroot -type d -exec chmod 750 {} ;[/plain]
nn
the above command searches (find) through the defined web root, looking for directories (-type d), then executes chmod 750 on each of them. Should take a few seconds to complete.
nn
[plain]find /path/to/webroot -type f -exec chmod 640 {} ;[/plain]
nn
the above command does the same, but this time for actual files, instead of directories. ‘find’ in this case will recurse through directories.
nn
SELINUX NOTES:
nn
so it looks like centos6 at least ships with the httpd_unified boolean set. With the boolean on, Apache processes can read/write/execute all httpd_sys_content* labels. This isn’t what we want to achieve.
nn
[plain]setsebool -P httpd_unified 0[/plain]
nn
then, we can create read only selinux labelling for the web root using:
nn
[plain]semanage fcontext -a -t httpd_sys_content_t “/path/to/www(.*)?”
nn
restorecon -Rv www[/plain]
nn
now, apache simply isn’t allowed to write to any files, or execute any files in the webroot.
nn
htaccess
nn
you’ve got a choice here, you can either manually copy/paste and .htaccess settings into the file yourself, or allow apache to write to the file using the following permissions
nn
[plain]chown dcr226:apache /path/to/www/.htaccess
nn
chmod 660 /path/to/www/.htaccess[/plain]
nn
then set the correct selinux context..
nn
[plain]semanage fcontext -a -t httpd_sys_rw_content_t /path/to/www/.htaccess
nn
restorecon -v /path/to/www/.htaccess[/plain]
nn
some things need write contexts and permissions…
nn
Apache needs to write to the wp-content/ directory in the very least to add new media, themes and plugins, so we need to make that happen with file permissions and a selinux context.
nn
[plain]find /path/to/webroot/wp-content -type d -exec chmod 770 {} ;
nn
find /path/to/webroot/wp-content -type f -exec chmod 660 {} ;
nn
semanage fcontext -a -t httpd_sys_rw_content_t “/path/to/www/wp-content(.*)?”
nn
restorecon -Rv /path/to/www/wp-content[/plain]
nn
Optional – protect xmlrpc.php
nn
unless you’re posting using a desktop/mobile application, or connecting to the xmlrpc api, then you likely want to prevent access to xmlrpc.php. This can be done a couple of ways, one of which is using your httpd.conf (or relevant config file in the drop directory) as such
nn
Inside of your
nn
[plain]
nn
Order allow,deny
nn
Deny from all
nn
[/plain]
nn
nn
When Its Time To Update The Whole Thing
nn
When you need to update wordpress core files, if you want wordpress to update itself, then you’re going to need to give the web process writeable permissions throughout the webroot..
nn
[plain]find /path/to/webroot -type d -exec chmod 770 {} ;
nn
find /path/to/webroot -type f -exec chmod 660 {} ;
nn
[/plain]
nn
and if you’re using selinux..
nn
[plain]
nn
chcon -R -t httpd_sys_rw_content_t /path/to/webroot
nn
[/plain]
nn
Not forgetting to re-set them again afterwards!