Rule ID
SV-286214r1292245_rule
Version
V1R1
CCIs
In certain situations to provide required functionality, MariaDB needs to execute internal logic (stored procedures, functions, triggers, etc.) and/or external code modules with elevated privileges. However, if the privileges required for execution are at a higher level than the privileges assigned to organizational users invoking the functionality applications/programs, those users are indirectly provided with greater privileges than assigned by organizations. Privilege elevation must be used only where necessary and protected from misuse. 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.
Functions and procedures in MariaDB all have "DEFINER" and "SECURITY_TYPE" options. If "SECURITY_TYPE" is equal to "DEFINER", then the function/procedure is run using the privileges of the "DEFINER" account. If "SECURITY_TYPE" is equal to "INVOKER", then the function/procedure is run using the privileges of the user invoking the function or procedure. To list the values of the "DEFINER" and "SECURITY_TYPE" in functions and procedures, as the DBA (shown here as root), log in to the database (mariadb -u root -p) and run: SELECT ROUTINE_NAME, ROUTINE_SCHEMA, ROUTINE_TYPE, DEFINER, SECURITY_TYPE FROM information_schema.routines; Triggers in MariaDB have a "DEFINER" option. For triggers, the value of the "DEFINER" determines the privileges to be used at the time of trigger activation. To list the values of the "DEFINER" in triggers, as the DBA (shown here as root), run the following SQL: SELECT trigger_schema, trigger_name, action_statement, definer from information_schema.triggers; If elevation of MariaDB privileges is used but not documented, this is a finding. If elevation of MariaDB privileges is documented but not implemented as described in the documentation, this is a finding. If the privilege-elevation logic can be invoked in ways/contexts other than intended, or by subjects/principals other than intended, this is a finding.
Determine where, when, how, and by which principals or subjects elevated privileges are required. MariaDB functions and stored procedures support the "SQL SECURITY" attribute, which determines whether a routine executes using the privileges of the invoker or the definer. To modify the "SECURITY_TYPE" of a function or stored procedure, run: ALTER FUNCTION function_name SQL SECURITY INVOKER; or ALTER FUNCTION function_name SQL SECURITY DEFINER; For stored procedures, run: ALTER PROCEDURE procedure_name SQL SECURITY INVOKER; or ALTER PROCEDURE procedure_name SQL SECURITY DEFINER; "SQL SECURITY INVOKER" causes the routine to execute using the privileges of the user invoking the routine. "SQL SECURITY DEFINER" causes the routine to execute using the privileges of the account defined as the definer of the routine. To review the current definition of a function or procedure, execute the following command as a DBA: SHOW CREATE FUNCTION function_name; or SHOW CREATE PROCEDURE procedure_name; If the definer account must be changed, the function or procedure must be recreated with the appropriate definer account. Remove the existing routine if modification of the definer, if required: DROP FUNCTION function_name; DROP PROCEDURE procedure_name; Recreate the function or procedure using the definition returned by the "SHOW CREATE" statement, specifying the appropriate "DEFINER" account in the "CREATE" statement. This ensures that elevated privileges are granted only where required and are executed under the appropriate security context.