Rule ID
SV-286208r1292199_rule
Version
V1R1
CCIs
If MariaDB provides too much information in error logs and administrative messages to the screen, this could lead to compromise. The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements. Some default MariaDB error messages can contain information that could aid an attacker in, among other things, identifying the database type, host address, or state of the database. Custom errors may contain sensitive customer information. It is important that detailed error messages be visible only to those who are authorized to view them; that general users receive only generalized acknowledgment that errors have occurred; and that these generalized messages appear only when relevant to the user s task. For example, a message such as "An error has occurred. Unable to save changes. If this problem persists, contact the help desk" would be relevant. A message such as "Warning: the transaction generated a large number of page splits" would likely not be relevant. Administrative users authorized to review detailed error messages typically are the ISSO, ISSM, SA, and DBA. Other individuals or roles may be specified according to organization-specific needs, with appropriate approval. This calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the DBA is organizationally separate from the application developers, and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed and must document what has been discovered.
Log in to MariaDB Enterprise Server as the DBA. Determine the location of the MariaDB error log: SHOW GLOBAL VARIABLES LIKE 'log_error'; Verify that the "log_error" variable is configured. If "log_error" is empty or disabled, this is a finding. Identify the directory containing the log file if the returned value is an absolute path. The log file is located in the MariaDB data directory if the returned value is only a file name. Verify the ownership and permissions of the log directory as the SA: ls -ld <log_directory> Verify the ownership and permissions of the error log file: ls -l <log_file> Verify the following: - The log directory is owned by mysql:mysql. - The log directory permissions are no more permissive than 750. - The error log file is owned by mysql:mysql. - The error log file permissions are no more permissive than 640. Verify that detailed database error messages are not exposed directly to users who are not authorized to view them. If any of these conditions are not met, this is a finding.
Log in as the DBA. Configure the location of the MariaDB error log by setting the "log_error" server option. Example: [mariadb] log_error=/var/log/mariadb/mariadb.err Restart MariaDB Enterprise Server, if required, for the configuration change to take effect. Configure the ownership of the log directory and log file as the SA: chown mysql:mysql /var/log/mariadb chown mysql:mysql /var/log/mariadb/mariadb.err Configure the directory permissions: chmod 750 /var/log/mariadb Configure the log file permissions: chmod 640 /var/log/mariadb/mariadb.err Verify the configuration: SHOW GLOBAL VARIABLES LIKE 'log_error'; Verify the error log directory and log file have the required ownership and permissions, and that detailed database error information is not disclosed to unauthorized users.