Securely installing ownCloud

Tags: howtos, security, projects

Published on
« Previous post: Setting up an XMPP server with Prosody — Next post: Tools for Writing a Diploma Thesis »

In my quest for alternatives to Google Contacts and Google Calendar, I finally encountered ownCloud. Briefly put, this awesome software allows me to store my personal data (calendars, contacts, files, and much more) on my own server, while providing access through a number of well-defined protocols such as CalDAV. ownCloud is written in PHP, which I do not consider to be a very secure platform. To ensure that my server is not too vulnerable, I decided to secure my ownCloud installation.

Disabling some PHP features

I you have not already done so, you should disable the following PHP features globally, for example using php.ini:

register_globals = Off
magic_quotes_gpc = Off
magic_quotes_runtime = Off
magic_quotes_sybase = Off	

In my setup, ownCloud is hosted as its own Apache virtual host. In the virtual host configuration file, I disabled arbitrary directory operations by issuing php_admin_value open_basedir /path/to/vhost. This limits ownCloud’s PHP file accesses to the specified directory tree.

Securing Apache

By default, Apache uses a www-data user and group to interact with the content it serves. I wanted to have unique users for every virtual host as this severely decreases the impact of a break-in. To this end, I installed the apache2-mpm-itk package under Debian. This a version of Apache that allows you to run every vhost with a separate UID and GID. Files used by one vhost thus need not be accessible or even readable by the other vhosts!

After the installation, I added a section for the new module in each vhost configuration file. For the ownCloud vhost, for example, I created a user and a group named owncloud, set the user shell to /usr/sbin/nologin, and added the following to the configuration file:

<IfModule mpm_itk_module>
	AssignUserId owncloud owncloud
</IfModule>

This requires the proper permissions for all files in the ownCloud data directory.

Conclusion

I do not claim that my server can withstand a full-fledged attack, but I like to believe that my ownCloud installation now at least has a fighting chance to survive the onslaught brought on by automated “hacker” tools (quotes for the obvious reason that I do not believe that these tools are part of the real hacker philosophy). Have fun playing with ownCloud.

Some additional resources: