OWASP Backend Security Project MySQL Hardening - Revision history

Carlo.pelliccioni: /* Inside MySQL: DBMS' access control and privilege management */

2008-10-21T00:53:26Z

‎Inside MySQL: DBMS' access control and privilege management

Carlo.pelliccioni: /* Protection against stack-smashing and other memory corruption attacks */

2008-10-21T00:52:31Z

‎Protection against stack-smashing and other memory corruption attacks

Carlo.pelliccioni: /* Cryptographic appliances */

2008-10-21T00:51:47Z

‎Cryptographic appliances

Carlo.pelliccioni: /* Hardening the operating system environment */

2008-10-21T00:50:57Z

‎Hardening the operating system environment

Esonn: /* Overview */

2008-07-24T08:17:40Z

‎Overview

Esonn: /* Access management via SQL */

2008-07-24T08:17:10Z

‎Access management via SQL

Esonn: /* Security related configuration attributes */

2008-06-11T16:07:30Z

‎Security related configuration attributes

Esonn: /* TrueCrypt */

2008-06-11T16:07:04Z

‎TrueCrypt

Esonn: /* Introduction */

2008-06-11T16:06:46Z

‎Introduction

Esonn: /* Possible solutions: grsecurity under Linux */

2008-06-11T14:34:43Z

‎Possible solutions: grsecurity under Linux

@@ Line 392: / Line 392: @@
 [[Image:Mysql_access_control.png|thumb|290px|Schematic presentation of the DMBS' internal accounting and management procedures, as executed by the MySQL database server.]]
 ==== <tt>user</tt> table ====
@@ Line 448: / Line 446: @@
   +-----------------------+------------------+------+
 rows in set (0.01 sec)
 As listed, <tt>user</tt> additionally defines four columns related to cryptographic methods
@@ Line 487: / Line 484: @@
 Note, that these privileges are commonly not used via SQL-statements, but through using the mysqladmin shell command. This is a security related model, since a user who intends to force privilege escalation atempts on the MySQL server, will not be able to use this commands inside the standard MySQL shell. The above rights should be reduced to an absolute minimum of users.
 === Setting up the <tt>root</tt> password ===
@@ Line 499: / Line 495: @@
   UPDATE user SET password = PASSWORD('secret') WHERE user = 'root';
 === Tables and security functions ===
@@ Line 529: / Line 524: @@
      Deleted_by = USER()
    WHERE Company = 'Someothername Ltd."
 === Check table consistencies and repair databases ===

@@ Line 317: / Line 317: @@
 Todays high-level programming languages like Java and C\# follow a conceptional hiding of pointers to the developer, which, spoken generally, leads to more secure code since overflows nearly always sustain upon exploitable pointer structures. Nevertheless I'm going to figure out some possibly insecure code-snippes of the current MySQL version, before describing howto avoid attacks on them.
 Here's an outtake of <tt>mysql-5.0.45/libmysql/libmysql.c:693</tt>
@@ Line 342: / Line 341: @@
   name = memcpy(mem_alloc(log_dir_len + ((sizeof logfilename) + 11)), log_dir, log_dir_len);
   memcpy(name + log_dir_len, logfilename, sizeof logfilename);
 This code is part of the InnoDB sources, which attempts to be an journaling ACID-compatible database backend. The developer wants to put the <tt>log_dir</tt> string into a newly created buffer called <tt>name</tt>. The memory allocation of <tt>name</tt> is done within the <tt>memcpy</tt> call, and the return value is not checked against 0, which would indicate that the memory allocation has failed. In such a situation, the MySQL database server process will probably get killed by the System, since writing to unallocated memory normally leads to a segmentation fault.
 === Possible solutions: grsecurity under Linux ===

@@ Line 151: / Line 151: @@
 An OpenSSH tunnel is easy to setup and maintain, as well as secure and well-known to most Unix users.
 ==== OpenSSL ====
@@ Line 223: / Line 222: @@
 <tt>$DIR</tt> is to be replaced by the chosen key and certificate directory.
 ==== OpenSSH ====
@@ Line 266: / Line 264: @@
 The statement in line 1 just activates IP packet forwarding in the Linux kernel. The second command activates traffic redirection from the OpenSSH server (where the <tt>iptables</tt> rulebase is active) to the MySQL database server. Finally, with the third command, we activate masquerading to ensure that responses of the MySQL server are correctly translated and redirected to the calling host (e.g. the MySQL client).
 ==== OpenVPN ====
@@ Line 289: / Line 284: @@
 # Format the crypted data container with a filesystem of our choice (ReiserFS in this case).
 # Mount the crypted container, as it’s ready to use.
 These steps are done via the following commands:
@@ Line 316: / Line 310: @@
 === Non-realtime encryption routines for database backups ===
 == Protection against stack-smashing and other memory corruption attacks ==

@@ Line 28: / Line 28: @@
 A perfectly configured Oracle Database Server, including DMBS account and role management etc., won’t be useful if everybody may be able to simply copy the raw data from the filesystem for obtaining the desired information quickly and easily. For more in-depth information about Unix and the Unix system environment, I’d refer to [SWF05], [Amb07] and [Bau02].
 === Filesystem access restrictions and ACLs ===
@@ Line 60: / Line 59: @@
 Moreover, the <tt>mysql</tt> user should by no means be able to invoke a command shell. This assures that crackers arn't be able to login at the server system, even if this user has been hacked. Revoking command shells is done within <tt>/etc/passwd</tt>, by changing the last column of the mysql user from <tt>/bin/bash</tt> to <tt>/bin/false</tt>. The program given here will be invoked when a user has been successfully authenticated by the system.
 ==== Logfiles ====
@@ Line 77: / Line 75: @@
 <tt>chroot</tt> basically repositions the global root directory (/) via remapping it into a specific directory of any directory within the filesystem tree. Any commands, applications, users etc. which act within the chroot-environment actually don’t know that they are working in a sandbox and should have no chance for accessing any part of the filesystem outside the jailed area.
 ==== Manually designing a sandbox ====
@@ Line 99: / Line 96: @@
    libc.so.6 = > /lib/i686/cmov/libc.so.6(0xb7e42000)
    /lib/ld-linux.so.2 (0xb7fd9000)
 Now we’ll just need to copy the given objects in the corresponding directories of the sandbox. This can be done manually file by file, or simply with the following piece of code:
@@ Line 116: / Line 112: @@
         cp $i ./`dirname $i`;
       done
 We can now initially start the MySQL Server inside the chroot-environment by calling

← Older revision		Revision as of 08:17, 24 July 2008
Line 1:		Line 1:
	= Overview =		= Overview =
−
−	'''DISCLAIMER: The following section about MySQL hardening isn't by far completed yet and deserves deeper inspection. It is currently built up and heavily under construction; It's not yet recommended to actually use or rely on those techniques (at least not in production environments)'''
−
−	~~Cheers, Erik.~~

	* Firstly, we will deal about hardening the underlying operating system environment. This is an ultimately essential step towards application layer security, since also the best security mechnism and configuration won't be useful if the whole system is attackable one layer beyond the actual target application. Operating system hardening includes setting right filesystem permissions, the design and implementation of a virtual chroot-jail application executing environment, the use of access control lists as well as a quick introduction about modern virtualization approaches.		* Firstly, we will deal about hardening the underlying operating system environment. This is an ultimately essential step towards application layer security, since also the best security mechnism and configuration won't be useful if the whole system is attackable one layer beyond the actual target application. Operating system hardening includes setting right filesystem permissions, the design and implementation of a virtual chroot-jail application executing environment, the use of access control lists as well as a quick introduction about modern virtualization approaches.

@@ Line 489: / Line 489: @@
 === Access management via SQL ===
-All permissions and restrictions stored in the mysql database, are classically managed via SQL, mainly using GRANT and REVOKE statements.
+All permissions and restrictions stored in the <tt>mysql</tt> database, are classically managed via SQL, mainly using GRANT and REVOKE statements. While GRANT statements usually gives a permission to a user, the corresponding REVOKE statement disallows the user to own this certain permission.
 A GRANT statement consists of the permissions which are to be set, as well as the database and table it is refering to, and a user/hostname pair. For example:
@@ Line 497: / Line 497: @@
 The REVOKE command is used adequatly. For a detailed description on GRANT and REVOKE you may consider having a look on the official MySQL reference [Vas04].
-There is no main difference between setting up permissions via the tables inside the mysql database using DML or typing SQL GRANT and REVOKE statements. However, while the latter version will activate the permissions immediately, privilege settings applied by direct DML, deserve reloading the values. This can be done via FLUSH PRIVILEGES.
+There is no big difference between setting up permissions via the tables inside the <tt>mysql</tt> database using DML or typing SQL GRANT and REVOKE statements. However, while the latter version will activate the permissions immediately, privilege settings applied by direct DML, deserve reloading the values. This can be done via FLUSH PRIVILEGES.
 There a several privileges only used for database administration, namely
@@ Line 503: / Line 503: @@
 * SHUTDOWN, allowing the user to shutdown the MySQL server via the shutdown command,
 * SUPER, allowing the user to perform the kill command for killing certain MySQL threads,
-* RELOAD, allowing the user to perform <tt>flush-hosts</tt>, <tt>flush-logs</tt>, <tt>flush-privileges</tt>, <tt>flush-status</tt>, <tt>flush-tables</tt>, <tt>flush-threads</tt>, <tt>refresh</tt> as well as <tt>reload</tt> commands.
+* RELOAD, allowing the user to perform <tt>flush-hosts</tt>, <tt>flush-logs</tt>, <tt>flush-privileges</tt>, <tt>flush-status</tt>, <tt>flush-tables</tt>, <tt>flush-threads</tt>, <tt>refresh</tt> as well as <tt>reload</tt> commands. It's not recommended ever to give one of those permissions to ordinary users.
 Note, that these privileges are commonly not used via SQL-statements, but through using the mysqladmin shell command. This is a security related model, since a user who intends to force privilege escalation atempts on the MySQL server, will not be able to use this commands inside the standard MySQL shell. The above rights should be reduced to an absolute minimum of users.
 === Setting up connection limits ===

@@ Line 387: / Line 387: @@
 == Security related configuration attributes ==
-The <tt>my.cnf</tt> file may contain a rich set of possible configuration attributes and values, which can change the behaviour of the MySQL server dramatically. The whole file is basically split up into a couple of different sections, each describing the configuration of a specific MySQL executable which is written within brackets, e.g. <tt>mysqld</tt>, <tt>mysqldump</tt>, <tt>client</tt>, etc. We will further focus on <tt>mysqld</tt> only. The whole set of configuration attributes can be archieved in the MySQL sample configuration files, usually found in <tt>$MYSQL/support-files/</tt>.
+The <tt>my.cnf</tt> file may contain a rich set of possible configuration attributes and values, which can change the behaviour of the MySQL server dramatically. The whole file is basically split up into a couple of different sections, each describing the configuration of a specific MySQL executable which is written within brackets, e.g. <tt>mysqld</tt>, <tt>mysqldump</tt>, <tt>client</tt>, etc. We will further focus on <tt>mysqld</tt> only. The whole set of configuration attributes can be achieved in the MySQL sample configuration files, usually found in <tt>$MYSQL/support-files/</tt>.
 === Connectivity ===
@@ Line 395: / Line 395: @@
 === Logging ===
-Turning on the <tt>log</tt> parameter, makes MySQL enable full query logging. This means, that every MySQL query (even ones with incorrent syntax) is getting logged. This is either good for debugging reasons on the one hand, and very interesting on detecting certain database attacks like SQL-injections on the other hand.
+Turning on the <tt>log</tt> parameter, makes MySQL enable full query logging. This means, that every MySQL query (even ones with incorrect syntax) is getting logged. This is either good for debugging reasons on the one hand, and very interesting on detecting certain database attacks like SQL-injections on the other hand.
 === Transactions and ACIDness ===

@@ Line 320: / Line 320: @@
 Like <tt>dmcrypt</tt>, also Truecrypt offers two possibilities of creating encrypted volumes:
 * Format a whole partition which is to be filled with encrypted content, or
-* creating a fixed-size container archive file; this file will again be looped back to a pseudo-device which can be accessed by the operating system just like a normal partition.
+* creating a fixed-size container achive file; this file will again be looped back to a pseudo-device which can be accessed by the operating system just like a normal partition.
 Interestingly, the latter is the faster alternative, according to the corresponding article on the German IT online news magazine heise.de.

@@ Line 16: / Line 16: @@
 == Introduction ==
-The enormous global increase of information which is to be stored, forces certain approaches of archiving and restoring data, while keeping track of numerous valuable and essential preconditions, e. g. data integrity.
+The enormous global increase of information which is to be stored, forces certain approaches of achiving and restoring data, while keeping track of numerous valuable and essential preconditions, e. g. data integrity.
 Relational databases are still the common way of accomplishing the storage of masses of information, although its conceptional basics reach back to 1970, where E. F. Codd firstly introduced this method of data handling [Cod70].
@@ Line 25: / Line 25: @@
 The language of given sourcecodes should be clear from the context they are mentioned. However, shell scripts are written using the Bourne Again Shell (/bin/bash), and most sources are plain C. When shell command examples are given, every line is prefixed with either # or $. While the hash indicates that the following statement has to be called as root user, the dollarsign commands doesn’t need administrative permissions.
 == Hardening the operating system environment ==

@@ Line 372: / Line 372: @@
 * Flagging of memory areas which contain executable machine code as non-writeable. This prevents attacks which are trying to directly access and modify the process' code segment for taking over the execution flow.
 * Providing of ASLR, what means Address Space Layout Randomization. This makes exploitation itself much harder, since most exploits rely on the knowledge of return addresses on the stack (in fact, in most cases, the return pointers of a running procedure which should be overwritten is only estimated; with ASLR, the estimation will be much harder).
 == Security related configuration attributes ==