V-286179

Discussion

If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult, if not impossible, to achieve. In addition, access to audit records provides information an attacker could potentially use to their advantage. To ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, copy, etc. This requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files enjoy the proper file system permissions using file system protections and limiting log data location. Additionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring that audit information is protected from unauthorized access. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Satisfies: SRG-APP-000118-DB-000059, SRG-APP-000119-DB-000060, SRG-APP-000120-DB-000061

Check Content

Connect to MariaDB using an administrative account from the operating system shell:

mariadb -u root -p

Identify the audit log path and data directory:

SHOW GLOBAL VARIABLES LIKE 'server_audit_file_path';
SHOW GLOBAL VARIABLES LIKE 'datadir';

If "server_audit_file_path" returns a full path, use that path to locate the audit log file.

If "server_audit_file_path" returns only a file name, use the MariaDB data directory returned by "datadir" as the base directory. 

For example, if "server_audit_file_path" is "server_audit.log" and "datadir" is "/var/lib/mysql/", the audit log file should be reviewed at "/var/lib/mysql/server_audit.log".

Check ownership and permissions on the audit log file from the operating system shell:

sudo ls -al /path/to/server_audit.log

If the audit log file is not owned by the MariaDB service account/group or has permissions more permissive than 660, this is a finding.

If the MariaDB server is configured to use syslog for logging, consult the organization's syslog setting for permissions and ownership of logs.