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.
Installer
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!