The second Installation STIG item pertains to access controls for the account (typically ‘oracle’) that owns the Oracle software on the database server.
Group ID (Vulid): V-2422
Group Title: DBMS software owner account access
Rule ID: SV-24374r1_rule
Severity: CAT II
Rule Version (STIG-ID): DG0040-ORACLE11
Rule Title: The DBMS software installation account should be restricted to authorized users.
Vulnerability Discussion: 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.
Fix Text: Develop, document and implement procedures to restrict use of the Oracle DBMS software installation account. Ensure that the Oracle DBMS software installation account is locked when not in use.
The first part seems simple enough. In a day when most database applications are three-tier, with a web client, an application server, and a database server, there really isn’t any reason for anyone who isn’t “qualified and authorized” to have any access to the database server at all. This should keep the number of user accounts on the server low and manageable.
The trickier part of this item is found in the “fix text”, where it states “ensure that the Oracle DBMS software installation account is locked when not in use.” While many things can be accomplished with accounts that belong to the “dba” operating system group, certain types of operations can only be performed by the ‘oracle’ account, including some forms of backup operations, startup and shutdown, and some forms of monitoring. As such, it doesn’t make practical sense to make this account completely unavailable.
Fortunately, on UNIX and Linux systems there is a simple work-around. Rather than log on directly to the oracle account, we can use the “sudo” application to provide authorized DBA access to it. Sudo is available by default in most Linux distributions, including Red Hat Enterprise Linux and Oracle Linux, and may be compiled from source and installed in most other *NIX environments.
Assuming sudo is installed and ready for use, we can begin restricting access to the oracle account by removing the account password from the /etc/shadow file, as well as any account expiration parameters. This effectively locks the account, making direct access from either the network or the console impossible. Next, we can configure a DBA group in sudo that allows authorized users to execute “su – oracle” with root privileges. This will allow authorized users to access the oracle account shell for maintenance purposes, but prevent the account from being attacked or compromised directly. Additionally, every access to the oracle account will be audited automatically by sudo, ensuring that we have a complete accounting of all users who have used (or tried to use) the account and when they used it.
A side benefit of this approach is that we have eliminated the oracle account password completely from our infrastructure, meaning one less password to maintain and memorize, or to distribute to a list of authorized users every time it is changed. Each authorized user now need only remember their own personal credentials for the database server.
All quotations from the Database STIG taken from:
Defense Information Systems Agency. Oracle 11 Database Installation STIG Version 8 Release 1.10. http://iase.disa.mil/stigs/app-security/database/Pages/index.aspx. Published January 2014. Accessed April 4, 2014.