Oracle Database Security Assessment Report - Privileges and Roles

Displays access to password verifier tables granted to users.

Users with these privileges can access objects that contain user password verifiers. The verifiers can be used in offline attacks to discover user passwords.

• Revoke object privileges

Displays the administrative privileges granted to user accounts.

Administrative privileges allow a user to perform maintenance operations, including some that may occur while the database is not open. The SYSDBA privilege allows the user to run as SYS and perform virtually all privileged operations. Starting with Oracle Database 12c Release 1 (12.1), less powerful administrative privileges were introduced to allow users to perform common administrative tasks with less than full SYSDBA privileges. To achieve the benefit of this separation of duty, each of these administrative privileges should be granted to at least one user account.

• Administrative Privileges
• Managing Administrative Privileges
• Granting and Revoking Administrative Privileges

Displays the user accounts that have been granted the DBA or PDB_DBA role.

The DBA role is very powerful and can be used to bypass many security protections. It should be granted to only a small number of trusted administrators. Furthermore, each trusted user should have an individual account for accountability reasons. As with any powerful role, avoid granting the DBA role with admin option unless absolutely necessary.

• Performing Privilege Analysis to Identify Privilege Use
• Administrative User Accounts
• Revoke

Displays the user accounts that have been granted roles with maximum data access privileges.

Like the DBA role, these roles (AQ_ADMINISTRATOR_ROLE, EM_EXPRESS_ALL, EXP_FULL_DATABASE, IMP_FULL_DATABASE, SELECT_CATALOG_ROLE, EXECUTE_CATALOG_ROLE, DELETE_CATALOG_ROLE, OEM_MONITOR, DBA, AUDIT_VIEWER) contain powerful privileges that can be used to bypass security protections. They should be granted only to a small number of trusted administrators.

• Users With System Privileges
• Granting and Revoking Administrative Privileges

Displays the system privileges granted to users.

System privileges provide the ability to access data or perform administrative operations for the entire database. Consistent with the principle of least privilege, these privileges should be granted sparingly. System privileges should be granted with admin option only when the recipient needs the ability to grant the privilege to others.

-g option reports all grants including common grants in a PDB. The report displays (*) for privileges being granted with admin option, (D) for privileges being granted directly, and (C) for privileges being granted commonly.

• Users With System Privileges
• Revoke

Displays information about user accounts with ANY system privileges and schema-level grants.

This will allow reviewing cases where SELECT ANY TABLE system privilege was granted to simplify management and replace them with schema-level grants instead.

• Managing Schema Privileges
• Revoke

Displays the system privileges granted to PUBLIC.

Privileges granted to PUBLIC are available to all users. This generally should include few, if any, system privileges since these will not be needed by ordinary users who are not administrators.

• ANY Privileges and the PUBLIC Role
• Revoke
• PUBLIC role

Displays the roles granted to PUBLIC.

Roles granted to PUBLIC are available to all users. Most roles contain privileges that are not appropriate for all users.

• Grants to PUBLIC on a CDB
• How the PUBLIC Role Works in a Multitenant Environment
• PUBLIC role

Displays the column access privileges granted to PUBLIC.

Privileges granted to PUBLIC are available to all users. This should include column privileges only for data that is intended to be accessible to everyone.

• Grants and Revokes of Privileges to and from the PUBLIC Role
• PUBLIC role

• Grants and Revokes of Privileges to and from the PUBLIC Role
• PUBLIC role

• DBMS_CRYPTO
• DBMS_RANDOM
• PUBLIC role

• Grants and Revokes of Privileges to and from the PUBLIC Role
• PUBLIC role

• DBMS_CREDENTIAL
• Grants and Revokes of Privileges to and from the PUBLIC Role
• PUBLIC role

• Grants and Revokes of Privileges to and from the PUBLIC Role
• PUBLIC role

• Managing Fine-Grained Access in PL/SQL Packages and Types
• Grants and Revokes of Privileges to and from the PUBLIC Role
• PUBLIC role

• DBMS_SQL
• DBMS_XMLGEN deprecation
• PUBLIC role

• Database Contents and Oracle JVM Security
• DBMS_JAVA
• Overview of Setting Permissions

• Switching to a Container Using the ALTER SESSION Statement
• How the Oracle Multitenant Option Affects Privileges

Displays all roles granted to users.

Roles are a convenient way to manage groups of related privileges, especially when the privileges are required for a particular task or job function. Beware of broadly defined roles, which may confer more privileges than an individual recipient requires. Roles should be granted with admin option only when the recipient needs the ability to modify the role or grant it to others.

• Performing Privilege Analysis to Identify Privilege Use

Displays account management privileges granted to users.

User management privileges (ALTER USER, CREATE USER, DROP USER) can be used to create and modify other user accounts, including changing passwords. This power can be abused to gain access to another user's account, which may have greater privileges.

• Revoke

Displays privilege management privileges granted to users.

Users with privilege management privileges (ALTER ANY ROLE, CREATE ROLE, DROP ANY ROLE, GRANT ANY OBJECT PRIVILEGE, GRANT ANY PRIVILEGE, GRANT ANY ROLE) can change the set of privileges granted to themselves and other users. This ability should be granted sparingly, since it can be used to circumvent many security controls in the database.

• Revoke

Displays database management privileges granted to users.

Database management privileges (ALTER DATABASE, ALTER SYSTEM, CREATE ANY LIBRARY, CREATE LIBRARY) can be used to change the operation of the database and potentially bypass security protections. This ability should be granted only to trusted administrators.

• Revoke

Displays audit management tool access granted to users.

The DBMS_AUDIT_MGMT package allow for execution of Audit management tools. Access should be strictly limited and granted only to users with a legitimate need for this functionality.

• Revoke
• DBMS_AUDIT_MGMT

Displays audit management privileges granted to users.

Audit management privileges (AUDIT ANY, AUDIT SYSTEM) can be used to change the audit policies for the database. This ability should be granted sparingly, since it may be used to hide malicious activity.

• Revoke

Displays access to audit objects granted to users.

Users with these privileges can directly access and modify objects containing audit information. Access to these objects may allow a malicious user deduce privilege settings for other users and to manipulate the audit information by replacing or deleting audit records.

• Revoke
• Who Can Perform Auditing?

Displays access control exemption privileges that are enforced.

Users with exemption privileges (EXEMPT ACCESS POLICY, EXEMPT REDACTION POLICY) can bypass the row and column access control policies enforced by Virtual Private Database and Data Redaction. Most administrative tasks do not require access to the data itself, so these privileges should be granted rarely even to administrators.

• Revoke
• Oracle Virtual Private Database and Oracle Label Security Exceptions
• Exemption of Users from Oracle Data Redaction Policies

Displays access to restricted objects granted to users.

Users with these privileges can directly modify objects in the SYS, DVSYS, AUDSYS or LBACSYS schemas. Manipulating these system objects may allow security protections to be circumvented or otherwise interfere with normal operation of the database. Object permissions granted to PUBLIC must be restricted for objects in the SYS, DVSYS, AUDSYS or LBACSYS schemas.

• Revoke

Displays the user accounts that have been granted rights to impersonate other users.

The BECOME USER privilege and these PL/SQL packages (DBMS_AQADM_SYS, DBMS_AQADM_SYSCALLS, DBMS_IJOB, DBMS_PRVTAQIM, DBMS_REPCAT_SQL_UTL, DBMS_SCHEDULER, DBMS_STREAMS_ADM_UTL, DBMS_STREAMS_RPC, DBMS_SYS_SQL, INITJVMAUX, LTADM, WWV_DBMS_SQL, WWV_EXECUTE_IMMEDIATE) allow for execution of SQL code or external jobs using the identity of a different user. Access should be strictly limited and granted only to users with a legitimate need for this functionality.

• Revoke
• System Privileges (Organized by the Database Object Operated Upon)

Displays the user accounts that have been granted rights to access or copy any data from a client or server.

These PL/SQL packages (DBMS_BACKUP_RESTORE, UTL_DBWS, UTL_ORAMTS) can send data from the database using the network or file system. Access should be granted only to users with a legitimate need for this functionality.

• DBMS_FILE_TRANSFER
• Revoke

Displays all program units granted CBAC roles.

Code Based Access Control(CBAC) can be used to grant additional privileges on program units. CBAC allows you to attach database roles to a PL/SQL function, procedure, or package. These database roles are enabled at run time, enabling the program unit to execute with the required privileges in the calling user's environment.

• Using CBAC for Definer's Rights and Invoker's Rights

Displays the user accounts that have been granted privileges to run Oracle Java classes within the database.

Oracle Java permission grants control the ability of database users to run Oracle Java classes within the database server. A database user running Oracle Java code must have both Oracle Java security permissions and database privileges to access resources within the database. These resources include database resources, such as tables and PL/SQL packages, operating system resources, such as files and sockets, Oracle JVM classes, and user-loaded classes. Make sure that these permissions are limited to the minimum required by each user.