Top STIG – Part 6 (OS Accounts)


The final installment in my series on CAT I STIG controls is all about the use (or not) of the server operating system accounts that support the Oracle database. Two controls address the use of and access to the Oracle software installation account, and one addresses the privileges associated with individual user accounts for DBAs.

V-61537: DBA OS accounts must be granted only those host system privileges necessary for the administration of the DBMS.

This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy, such as Role Based Access Control (RBAC), is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account.

DBAs, if assigned excessive OS privileges, could perform actions that could endanger the information system or hide evidence of malicious activity.

Oracle Database 12c Security Technical Implementation Guide :: Release: 16 Benchmark Date: 24 Jan 2020

The reviewer will ask to see system documentation, including a security plan, that describe exactly what OS privileges DBA user accounts on the server should have, as well as the “dba” user group. They will also require output from a variety of system commands that provide evidence of policy compliance. Note that this control does not include the Oracle software owner account.

For UNIX systems (as root):

cat /etc/group | grep -i dba
groups root

If “root” is returned in the first list, this is a finding.

If any accounts listed in the first list are also listed in the second list, this is a finding.

Investigate any user account group memberships other than DBA or root groups that are returned by the following command (also as root):

groups [dba user account]

Replace [dba user account] with the user account name of each DBA account.

If individual DBA accounts are assigned to groups that grant access or privileges for purposes other than DBA responsibilities, this is a finding.

For Windows Systems (click or select):
– Start / Settings / Control Panel / Administrative Tools / Computer Management / Local Users and Groups / Groups / ORA_DBA
– Start / Settings / Control Panel / Administrative Tools / Computer Management / Local Users and Groups / Groups / ORA_[SID]_DBA (if present)

Note: Users assigned DBA privileges on a Windows host are granted membership in the ORA_DBA and/or ORA_[SID]_DBA groups. The ORA_DBA group grants DBA privileges to any database on the system. The ORA_[SID]_DBA groups grant DBA privileges to specific Oracle instances only.

Make a note of each user listed. For each user (click or select):
– Start / Settings / Control Panel / Administrative Tools / Computer Management / Local Users and Groups / Users / [DBA user name] / Member of

If DBA users belong to any groups other than DBA groups and the Windows Users group, this is a finding.

Examine User Rights assigned to DBA groups or group members:
– Start / Settings / Control Panel / Administrative Tools / Local Security Policy / Security Settings / Local Policies / User Rights Assignments

If any User Rights are assigned directly to the DBA group(s) or DBA user accounts, this is a finding.

Oracle Database 12c Security Technical Implementation Guide :: Release: 16 Benchmark Date: 24 Jan 2020

Corrective actions may include the following:

  • Revoke all host system privileges from the DBA group accounts and DBA user accounts not required for DBMS administration.
  • Revoke all OS group memberships that assign excessive privileges to the DBA group accounts and DBA user accounts.
  • Remove any directly applied permissions or user rights from the DBA group accounts and DBA user accounts.
  • Document all DBA group accounts and individual DBA account-assigned privileges in the System Security Plan.
V-61873: The DBMS software installation account must be restricted to authorized users.

DBA and other privileged administrative or application owner accounts are granted privileges that allow actions that can have a greater impact on database security and operation. It is especially important to grant access to privileged accounts to only those persons who are qualified and authorized to use them.

This requirement is particularly important because Oracle equates the installation account with the SYS account – the super-DBA. Once logged on to the operating system, this account can connect to the database AS SYSDBA without further authentication. It is very powerful and, by virtue of not being linked to any one person, cannot be audited to the level of the individual.

Oracle Database 12c Security Technical Implementation Guide :: Release: 16 Benchmark Date: 24 Jan 2020

The reviewer will check your procedures for controlling and granting access to use of the Oracle software installation account (typically the “oracle” account in UNIX or Linux environments). There are a couple of ways to control access to this account in UNIX or Linux systems:

  • In a stand-alone server environment, disable network logins for the account.
  • In a RAC environment, limit authentication for the oracle (or grid) account to the certificates used for inter-node communication or maintenance activity. Disable password authentication and do not share the private keys for use outside of the cluster.
  • Use the sudo utility to allow authorized users to access the software owner account functionality. You may only allow access to specific commands, or you may allow authorized users to “su” to the oracle account using sudo, but all sudo access will be audited and not anonymous.
V-61865: Use of the DBMS software installation account must be restricted.

Use of privileged accounts for non-administrative purposes puts data at risk of unintended or unauthorized loss, modification, or exposure. In particular, DBA accounts if used for non-administration application development or application maintenance can lead to miss-assignment of privileges where privileges are inherited by object owners. It may also lead to loss or compromise of application data where the elevated privileges bypass controls designed in and provided by applications.

The DBMS software installation account may require privileges not required for database administration or other functions. Use of accounts configured with excess privileges may result in the loss or compromise of data or system settings due to elevated privileges that bypass controls designed to protect them.

This requirement is particularly important because Oracle equates the installation account with the SYS account – the super-DBA. Once logged on to the operating system, this account can connect to the database AS SYSDBA without further authentication. It is very powerful and, by virtue of not being linked to any one person, cannot be audited to the level of the individual.

Oracle Database 12c Security Technical Implementation Guide :: Release: 16 Benchmark Date: 24 Jan 2020

A reviewer will examine your system documentation to identify the installation account, then verify whether the account is used for anything involving interactive activity beyond DBMS software installation, upgrade, and maintenance actions. This can be accomplished by checking shell command histories and OS audit trails for account activity.

The Big Picture

Taken together, we have a set of controls here that do the following:

  1. Require individual DBAs to use personal accounts for most administrative actions on the server.
  2. Limit access to the software owner account to specific, authorized individuals.
  3. Limit the use of the software owner account to specific functions related to the installation and maintenance of the software.

These controls require the system to define and enforce as official policy the principle of least privilege in regards to server operating system accounts and privileges: not granting any more permissions than are necessary to do a job and requiring individual accountability for actions taken on the system to the greatest extent possible. Note that the evaluation of compliance with all three controls starts with system documentation, which must include the following:

  • The OS privileges DBA user accounts on the server should have, as well as the “dba” user group.
  • Procedures for controlling and granting access to use of the Oracle software installation account.
  • The identity of the software installation account, and whether the account is used for anything involving interactive activity beyond DBMS software installation, upgrade, and maintenance actions.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.