| only for RuBoard - do not distribute or recompile | |
System security applies to the environment in which MySQL is installed—the hardware, network topology, and operating system. For example, if your MySQL database is installed on a machine where dozens of people have root access, they can bypass your excellent database security through direct manipulation of the MySQL database and executable files.
A user in the system security context differs from a user in the MySQL database security context. Specifically, a user in a system security context is any individual with access to operating system processes—via either direct access or across the network.
The job of the operating system is to protect the MySQL installation and its files from illegal external access. In short, this means that only the MySQL processes and authenticated database administrators should ever be able to touch the MySQL installation. However, certain files such as client configuration files do need to be readable by other users to enable them to connect to the server and perform valid operations. You therefore need to pay special attention to how you enable access to MySQL files.
Whatever directory structure you choose for the rest of your MySQL installation, you must keep the MySQL data files in their own directory. By default, a MySQL Unix installation places these files in /usr/local/mysql/data, /usr/var/mysql, or some other separate directory.
Because any user with read access to the MySQL data files or write access to the configuration and executable files has the potential to cause trouble, you should run the MySQL server under a special, dedicated user ID. The default MySQL installation expects a mysql user and group. You can customize this user/group pair to suit your own needs. This user and group should have full access to the MySQL data and should never be used for any purpose other than running MySQL.
If the previous two precautions have been addressed, you have a special directory for the MySQL data files and a special user and group under which the MySQL process runs. You therefore need to make sure that only this special user and group can access the data directory. You accomplish this task by setting the proper filesystem permissions on this directory. On a Unix system, the data directory and all its contents should be owned by your mysql user and group with 770 permissions for directories and 660 permissions for files.[5] Windows systems are not quite as simple. If your operating system (Windows 9x/ME) does not support NTFS, there is no way to protect the files. If you are using an NT-based Windows, you must have MySQL installed on an NTFS volume. You can then right-click on the MySQL data directory and set its permissions.
[5] 770 permissions means owner read/write/execute, group read/write/execute, and no permissions for the world. You can set this value using the command chmod -R 770 datadir.
Your configuration files and executables should be readable, but not writable by anyone. The executables, of course, should also be executable.
Which is a bigger threat to your employee salary database?
A script-kiddie with a password cracking script
A disgruntled employee with a big hammer
The answer is the disgruntled employee with the big hammer. As a general rule, it is easier to take down a web site through brute force against the server hardware than it is to hack the site. People rarely spend enough effort on the relatively simple effort of securing the hardware.
The degree of hardware security you need is proportional to how badly outsiders wish to access or destroy the data it houses. If you have a machine hosting your personal home page, locking the door to your house is probably good enough. If, on the other hand, your MySQL database stores the salary data for your entire company, that machine better be locked behind a door whose access is monitored.
Because you almost always leverage MySQL across a network, you need to protect the 1s and 0s the database is exchanging with other applications. The simplest form of network security is, of course, to disable network access to the MySQL server. In general, this solution is impractical; it means all applications that need to talk to MySQL have to run on the same box as the database. Such an architecture is impossible for client/server applications in which the client is almost always running on some desktop machine. Though in a multitier application, you can stick in the middle tier on the same server as the database, you give up scalability and accomplish nothing more than shifting the security burden from the database to the middle tier.
To fully appreciate the network security needs of MySQL, it is helpful to know how different applications talk to it. All applications talk to MySQL in one of two ways:
Using the MySQL C libraries
Using the MySQL network protocol
Your application may use one of the many meta-APIs such as ODBC, JDBC, DB-API, etc. Under the hood, however, these APIs all use one of the two methods listed above. As a matter of fact, even the MySQL C library technically uses the network protocol. In situations where the client and server are on the same machine, however, it uses Unix sockets or Windows pipes instead of TCP/IP sockets.
Until MySQL 4.0, no support existed to encrypt this network protocol. In other words, all data exchanged between a client and MySQL—including user authentication—went across the network in plain text. MySQL has introduced support for SSL encryption on top of its network protocol with MySQL 4.0.
The network security tasks of a network administrator boil down to the following:
Securing network paths so that each network service (i.e., the MySQL server process) can be accessed only by valid clients
Verifying that no application is transmitting sensitive information across the network
Ensuring that compromises of individual services on the network do not compromise all services on the network
The network topology (how machines are connected to each other and other networks) determines who can access which services. As a general rule, no MySQL server should ever be accessible from the Internet. If your application requires a MySQL server to be directly accessible over the Internet, you have a serious application architecture problem. Instead, your MySQL installation should be hidden behind a firewall, preferably on a network segment in which only the client applications such as the web server or application server can route to it.
Using software readily available on the Internet, it is simple for anyone to sniff network traffic and eavesdrop on data being transmitted between two applications. Therefore, no sensitive data should ever pass across a network—even protected networks—without encryption. No matter what you have in your database, you are always transmitting at least user IDs and passwords across a MySQL connection. Until MySQL 4.0, there was no way to implement this rule.
MySQL 4.0 introduced SSL support. Using SSL, the data is encrypted during its transmission across the network. Consequently, sniffers pick up only nonsense when they eavesdrop on your communications. To leverage SSL support, you need SSL libraries on both client and server machines, and you must compile MySQL and client components with SSL support. When compiled with SSL support, MySQL always attempts to use SSL before falling back to an unencrypted session.
The network administrator needs to understand the privileges granted to services on the network and how a direct compromise may impact those services. With respect to MySQL, this task requires you to make sure that a flaw in one of your applications or the MySQL server itself cannot compromise the rest of the system. Flaws in service applications generally enable remote attackers to use a service to execute arbitrary code on a server using the privileges of that service. These flaws result from programming errors in the service itself. Though MySQL has a remarkable security record on this count, it has never been put through a formal security audit such as the one OpenBSD puts its services through.
First of all, you should never, never run MySQL as root. If you install MySQL using a special MySQL user and group and use them to support only MySQL, a compromise of a MySQL service can affect only your MySQL database. Of course, if your MySQL service is protected from the open Internet by a firewall, it becomes extremely difficult—but never impossible—for an attacker to manage a direct compromise of the MySQL service.
The second—and probably more vulnerable—thing to watch for is the quality of your own code. You need to audit it for two common security errors:
Buffer overflow
Execution of arbitrary code
The first error is the kind of error seen over and over again in Sendmail. A buffer overflow occurs when a programmer fails to verify that the data she is placing into memory fits the memory allocated for that data. The most common form of this error is copying a string where the target buffer is allocated to a size smaller than the actual string. The security problem occurs when the source string is sent from arbitrary data set across the network. An attacker can use this overflow to overwrite critical application memory space and access resources using the privileges of the compromised service. In short, you always need to check the size of any data you are copying before you copy it!
Execution of arbitrary code was a terribly common problem in the early days of CGI programing. Programmers would write their CGI scripts to execute applications on the server using data input from HTML form data. Clever attackers could use this mistake to coerce a CGI script to execute programs under the server using the privileges of the web server.[6]
[6] In the early days of the Internet, it was common for web servers to run as root!
| only for RuBoard - do not distribute or recompile | |