The cost of improved security on a MySQL server

Security-Enhanced Linux or SELinux is a Linux kernel feature that provides a mechanism for supporting access control security policies. It enables a system administrator to create an extra set of rules that define allowed operations for programs even after the standard controls are checked. In other words, SELinux can help improving system security by restricting access of an application to only a few resources it actually needs, which makes it more difficult for an attacker to gain access to the entire system through exploiting any possible vulnerabilities in the application.

However as rarely anything in life is free, is there any price we have to pay to use SELinux on a MySQL server?

I ran a simple MySQL benchmark first with database working in a system with SELinux enabled (SELINUX=enforcing), and then also with the extra security layer entirely disabled (SELINUX=disabled).

The tests were performed on a 8-core system, running RedHat Enterprise Linux 6.2. The benchmark used Sysbench’s read-write OLTP test with data fully fitting into the InnoDB buffer pool.

Here are the results:

As it turned out, the difference in MySQL performance was negligible with small concurrency. However at eight threads MySQL lost approximately 20% of the throughput when SELinux was enabled. At sixteen threads it got much worse. Not only the difference continued to grow, but while on a clean system MySQL was able to maintain the throughput and even show some improvements, with the security policies applied the throughput started dropping quite rapidly.

The impact of keeping SELinux enabled seems rather high on servers that can become busy, although it does not mean this security feature should always be avoided. There is always a balance of what is more important.

Often a database server is buried under many layers of other things such firewalls, reverse proxies, web servers, application servers, or various kinds of middleware. In such cases one may not actually need to rely on that extra bit of security in that place. But in cases when there are one or two servers running both web service and database (think a typical WordPress site), it is unlikely that achieving the absolute top MySQL performance matters all that much, whereas keeping the server(s) safe does.

SELinux is not the only such solution out there, but the most popular as it is included in every Linux kernel. Often it is also enabled by default during the system installation process. Even more reasons to know what its impact on MySQL performance could be.

P.S. Yes, I am aware that running a WordPress installation or a similar software rarely focuses one’s concerns about security on the database server :-)

[MySQL Health Check]
About Maciej Dobrzanski

A MySQL consultant with the primary focus on systems, databases and application stacks performance and scalability. Expert on open source technologies such as Linux, BSD, Apache, nginx, MySQL, and many more. @linkedin

Comments

  1. Matic says:

    Try TOMOYO, it’s much easier to use than SELinux and supports auto-learning. I don’t know about performance penalty. Perhaps you could benchmark it and post the results? Also, you can use Grsecurity instead of TOMOYO. Grsecurity also provides some other security enhancements.

  2. Przemek Skowron says:

    the cost of improved security can be much lower than in your benchmark dependly of selinux policy (type, target, deep, etc.). I think we can do this benchmark again together, with more specific policy for db server. what do you think? :)

  3. Bartosz Bednarowicz says:

    Could you, provided you have enough time, describe what exactly in SELinux slows MySQL down?

    • Bartosz,

      I didn’t go into deep analysis of why was this happening. I just got a typical environment with SELinux enabled and ran a few benchmarks. Maybe I’ll get around to it again someday and then investigate it more. Przemek suggested fine-tuning the policies could help a lot, so maybe trying that will be the opportunity to measure this problem in more detail.

Speak Your Mind

*