0

I'm currently setting up an installation of mediawiki on arch linux using nginx and mariadb as a database. Since it will be a private wiki I would like to encrypt the database files using veracrypt.

So far I have done the following:

  1. Straight forward installation of mediawiki
  2. Create a veracrypt container & mount it
  3. After stopping all the relevant services (nginx, php-fpm, mysqld) I moved all the database files (/var/lib/mysql/nameofthewikidb/) into the container, unmount the container
  4. Delete the contents of /var/lib/mysql/nameofthewikidb/ and mount the container at /var/lib/mysql/nameofthewikidb/
  5. Start the mediawiki installation (nginx, php-fpm, mysqld)

So far everything looks good and I was able to use the wiki (insert/edit articles). I am planning on writing a simple bash script to start/stop the wiki and mount/unmount the containers

I will employ a similar approach for the mediawiki installation in /usr/share/webapps/mediawiki/ since it will contain uploaded images etc.

My question(s):

  • Can you spot any obvious flaw with my security concept so far?
  • I think I will have to deal with the log files (mysql-bin.XXXXXX) as well. Is it safe to delete them or should I put them in a container as well?

Thanks in advance!

0

The log files (mysql-bin.XXXXXX) are binary log. It can contains all query the database server executed, so it can contain sensitive information.

The security concern would be

  • key stored in your bash file for mounting
  • Thanks for your comment. I was planning on entering (pasting) the key each time I mounted the container. However, I was able to turn on encryption for the logfiles following HBruijn's advice so this is not an issue anymore. – jludewig Jul 7 '15 at 13:52
0

I'm not very familiar with veracrypt but a quick glance at the docs make it look like yet another whole disk/volume encryption tool.

Since by design whole-disk encryption is completely transparent to your applications, that class of technology protects against only a small number of threats, mainly unauthorised access to your hardware (theft, loss, access by hosting providers etc.). That kind of technology won't protect your data against curious administrators or when your system gets compromised while it is running...

In general your data is protected against a much larger range of threats when the application, the database server does the encryption. Then you can't by-pass the access controls built into your database by simply reading the data directly from the file-system.

MariaDB supports database encryption and they have a nice knowledge-base article on protecting data at rest with a high-level introduction.

For the moment, the only engines that fully support encryption are XtraDB and InnoDB. The Aria storage engine also supports encryption, but only for tables created with ROW_FORMAT=PAGE (the default).

MariaDB allows the user to configure flexibly what to encrypt. One can choose to encrypt everything in XtraDB/InnoDB — all tablespaces (with all tables) and log files. Or individual tables. Or everything, but excluding individual tables.

  • Thank you for your detailed answer. I tried out the encryption in the mariadb beta. It seems to work just fine but I have to somehow make the key file available. That means my data would be just as vulnerable if my system is compromised. My approach with veracrypt would have been to paste the key in the ssh prompt when mounting the volume. This way the key never really resides on the server (except in the memory but I guess that's inevitable). Maybe I should combine the two approaches and put the key-file in a veracrypt container and mount it when needed using ssh? – jludewig Jul 7 '15 at 14:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.