Secure by Default in MySQL 5.7

MySQL 5.7 comes with enhancements which makes a deployment secure by default. These features try to minimize attack surface as much as possible without hampering usability aspect. They are useful for novice user because they help close common security loopholes which can be leveraged by an attacker.

Secure-by-default features concentrate on four major areas.

  • Creation of installer packages in such a way that resultant installation is secure
  • Preparing secure pre-installation environment
  • Secure configuration for newly installed database
  • Secure communication links between server-client

In this blog, we will explain roles that individual feature play In these areas and make overall deployment secure.


Demo/Test artifacts moved to a separate package

In order to minimize the attack surface, demo/test/example artifacts are moved to a separate package. For example, packages containing the MySQL server binary will not contain authentication plugins used for unit testing. Such artifacts are not required in a production environment. Their presence not only occupies additional space, it may open up possibility where an attacker may use them to his/her advantage.


Pre-installation Environment

Stricter control over system account used to run MySQL server

On *nix systems, MySQL server is installed using platform specific packages (e.g. RPMs, DEB packages etc), as a part of installation process, a new user account – mysql (and corresponding group mysql) is created. This user is:

  • Owner of mysql data directory
  • Used when MySQL server is started – as value for –user argument. So, privileges of MySQL server process are restricted to that of mysql user

In this sense there is no need for such a user to have shell access. So, we now set shell to /bin/false when new user is created as a part of installation.

Stricter permission set for deployed files

Files extracted from installer are deployed with minimum set of permission required for MySQL server installation to proceed without any problem.


Secure configuration for newly installed database

Stricter file/directory permission for generated files

MySQL server generates files/directories as part of various operations like CREATE TABLE, CREATE DATABASE etc. These files/directories can be read/write/executed by user running the MySQL server (e.g. mysql user in default case). However, group permission are now restricted to read/execute. Other user will not get any type of access.

Protected seed user account

Default administrative account – root is now protected by default in one of the following way:

  • A random password is generated for seed user account
  • *nix credential of system administrator are used to authenticate seed user account

Having a known password (or no password at all!) makes a newly installed database vulnerable to threats from within the organization. A random password/system based authentication makes sure that database is protected since inception and only handful of administrator gets privileged access.

In addition, instead of having multiple seed administrative accounts and putting onus on users to remove unwanted ones, we now create a single seed account – root@localhost.

Stricter default access

Till MySQL 5.6, running mysql_install_db used to create test database. It also created set of default permission in such a way that newly created user can create/alter/drop various object in test database. Such a database and associated permission are not at all essential in production environment. In fact, it breaches principle of least privileges where new users get privileged access (though limited to a demo db).

Enforcing password policy by default

As one of the installation steps, validate_password plugin is installed after database creation. This enforces default policy of – 8 character password with mixed case characters, at least one digit and one special character. This makes sure accounts created after installation have strong passwords to begin with.

Restriction on location used for data import/export

MySQL server uses FILE privilege to restrict use of data import/export operations such as LOAD DATA … IN FILE and SELECT … INTO OUT FILE. Only a user with FILE privilege can perform such operations. However, there is another aspect to it too – location used for data import/export. This is controlled by server option –secure-file-priv. It restricts location used for importing or exporting data. If it is set to an empty string (which was the default value prior to MySQL 5.7), there is no restriction on location other than those imposed by OS itself. This may lead to situations where a privileged user can carefully replace content of files with mysql database which may lead to privilege escalation.

In order to prevent this, import/export operation are restricted to a single directory by default. Installation process creates mysql-data directory at a level similar to data directory. This directory path is used as default value for –secure-file-priv. Moreover, it is now possible to disable data import/export operation altogether by setting it to string literal “NULL”.

Secure communication links

SSL by default for libmysql

With MySQL 5.7, libmysql will attempt SSL connection by default. If server supports encrypted connection, this change guarantees encrypted connection out-of-the-box.  This change affects both standard MySQL command-line clients (mysql, mysqldump, etc.) and language drivers which rely on the libmysql client library.

Automatic generation of SSL artifacts

If libmysql attempts SSL connection by default, it is only appropriate if server starts with SSL support without intervention. This is achieved by two features:

  • Automatic discovery of SSL key material: If relevant certificate files (e.g. ca.pem, server-cert.pem and serer-key.pem) are available in data directory, server automatically uses them to enable SSL support if SSL related options are not specified at start-up.
  • Automatic generation of SSL key material: If server fails to detect these artifacts in data directory and none are provided either through command line argument or through configuration file, server attempts to generate them on its own.
    • For binary complied with OpenSSL support, this is done by calling appropriate OpenSSL APIs to generate various certificates required to support encrypted connection.
    • For binary compiled with yaSSL support, this is done by executing a separate utility – mysql_ssl_rsa_setup at the time of database installation. Successful execution of this utility requires openssl command line tools available through PATH.

In both cases, automatically generated files are placed in data directory so that automatic discovery mechanism can kick-in and enable support for encrypted connection.

Note that, if certificates are automatically generated, CA certificate is self-signed. Users should use switch to valid set of certificates at earliest possible opportunity.  For a hardened deployment, users should also configure client tools to validate the identity of the server.

Our attempt to make default installation secure is a stepping stone. We will continue to harden our deployment in future as well. As always, we would like to hear your opinion on these features and your suggestion to make it even more secure. Thank you for using MySQL!

7 thoughts on “Secure by Default in MySQL 5.7

  1. Having a more secure MySQL environment is good for everyone so I fully support the direction you are moving.

    Often systems are managed by external configuration management software and so these changes may not actually be applied as you expect for servers which had run older versions of MySQL (through an upgrade process) and there’s no way to tell if your recommended settings are _still_ being enforced.

    There are many reasons why people may choose (or have chosen) to do things differently, and given previous setups may not necessarily follow your current guidelines I think it would be useful to have a way to verify that these specific suggested configuration settings are still enabled as expected.

    (a) a program (or shell script) which verifies directory / file permissions
    – binaries and at least directories under $datadir.
    (b) a program which can verify null accounts or accounts with no password
    (c) SSL configuration. It’s a lot easier now in 5.7 but for those not that used to SSL the setup can be a bit intimidating. Perhaps having a program that can validate the current state of the SSL configuration might be useful?

    If you do not want to maintain such a program then a textual check list explaining the recommended settings would be useful I think. People can check against that and use it to verify their own setup. That ensures people do things consistently.

    I am sure that many of the items in such a theoretical “Secure MySQL setup” would be applicable to older versions of MySQL so even if users of these older versions can not do everything they’ll have a better idea of what needs checking.

    1. Hi,

      Thank you for your feedback.
      Some of the changes made as part of Secure by Default initiative are applicable to fresh installations. Reason for not applying them to older versions (which are upgraded to MySQL 5.7) is to make sure that we do not introduce any unintended changes in behavior.

      MySQL documentation contain useful information about general security issues and measures to harden a deployment.
      Please see

      We will identify if more information is required and update it as required.

      Also note that mysql_secure_installation is available with older version of MySQL. This utility is useful in improving security of MySQL server.

Leave a Reply

Your email address will not be published. Required fields are marked *

Please enter * Time limit is exhausted. Please reload CAPTCHA.