I Oracle Database Vault Security Guidelines

I.2.1 Managing Users with Root Access to the Operating System

Users who have root user access have full control over the system, including the following activities:

• Reading unencrypted files

• Moving and deleting any files

• Starting or stopping any program on the system

• Logging in as any user, including the user who owns the Oracle Database installation

Oracle Database Vault does not provide protection against the operating system root access. Ensure that you grant root user privileges only to the appropriate people with the appropriate responsibility.

I.2.2 Managing the Oracle Software Owner

Users who have access to a system as the Oracle software owner have control over the Oracle software, including the following activities:

• Disabling Oracle Database Vault in the given system

• Reading unencrypted database files

• Moving and deleting database files

• Starting or stopping Oracle programs in the system

Oracle Database Vault does not provide protection against the operating system access of the Oracle software owner. Ensure that you grant Oracle software owner access only to the appropriate people with the appropriate responsibility.

I.2.3 Managing SYSDBA Access

Oracle Database Vault does not provide full protection against users with SYSDBA access. Several Oracle Database components require SYSDBA access. These components are:

• Oracle Data Guard and Data Guard Broker command line utilities

• Oracle Recovery Manager command line utility

• Oracle Real Application Clusters

• Oracle Automatic Storage Management command line utilities

If your installation requires SYSDBA access, Oracle recommends that you add users who need this privilege to the OSDBA group for UNIX systems and the ORA_DBA group for Windows systems. Remember that SYSDBA actions are audited by default. See Oracle Database Installation Guide for more information about the OSDBA group and Oracle Database Platform Guide for Microsoft Windows for information about ORA_DBA.

I.2.4 Managing SYSOPER Access

By default, Oracle Database limits SYSOPER access to operating system users in the SYSOPER group and the user SYS. It prevents SYSOPER from modifying the Oracle data dictionary directly. The SYSOPER role has limited privileges within the database, but individuals with this role can start and shut down the Oracle database. Only grant the SYSOPER role to trusted individuals.

I.3.1 Security Considerations for the UTL_FILE and DBMS_FILE_TRANSFER Packages

The UTL_FILE package is owned by SYS and granted to PUBLIC. However, a user must have access to the directory object in order to manipulate the files in that operating system directory. You can configure the UTL_FILE package securely; see Oracle Database PL/SQL Packages and Types Reference for more information.

The DBMS_FILE_TRANSFER package is owned by SYS and granted to the EXECUTE_CATALOG_ROLE. Users with EXECUTE access on this package can move files from one location to another on the same file system. They also can move files between database instances, including databases on remote systems.

To secure the DBMS_FILE_TRANSFER package, do the following:

• Revoke the EXECUTE privilege from the DBMS_FILE_TRANSFER package and grant the EXECUTE privilege only to trusted users who need it.

• Create command rules to control the CREATE DATABASE LINK and CREATE DIRECTORY SQL statements. See "Creating and Editing a Command Rule" for information on creating command rules by using Oracle Database Vault Administrator.

Alternatively, Example I-1 and Example I-2 show you can use the Oracle Database Vault MACADM package to create command rules that limit and enable access to the CREATE DATABASE LINK statement that is used to establish connections to remote databases. To use this method, log in to SQL*Plus using the Oracle Database Vault Owner account.

begin 
 dbms_macadm.create_command_rule 
  (command      => 'CREATE DATABASE LINK', 
  rule_set_name => 'Disabled', 
  object_owner  => '%', 
  object_name   => '%', 
  enabled       => dbms_macutl.g_yes); 
  end; 
  / 
commit;

When a user needs to use this command, the Oracle Database Vault owner can re-enable it from Oracle Database Vault Administrator or issue the following commands in SQL*Plus.

begin 
 dbms_macadm.update_command_rule 
  (command      => 'CREATE DATABASE LINK', 
  rule_set_name => 'Enabled', 
  object_owner  => '%', 
  object_name   => '%', 
  enabled       => dbms_macutl.g_yes); 
 end; 
 /  
commit;

Similarly, Example I-3 shows command rules that disable and enable access to CREATE DIRECTORY.

-- Disable access to CREATE DIRECTORY
 
begin
 dbms_macadm.create_command_rule 
  (command       => 'CREATE DIRECTORY', 
  rule_set_name => 'Disabled', 
  object_owner  => '%', 
  object_name   => '%', 
  enabled       => dbms_macutl.g_yes); 
  end; 
  / 
commit;

-- Enable access to CREATE DIRECTORY
begin 
 dbms_macadm.update_command_rule 
  (command      => 'CREATE DIRECTORY', 
  rule_set_name => 'Enabled', 
  object_owner  => '%', 
  object_name   => '%', 
  enabled       => dbms_macutl.g_yes); 
 end; 
 /  
commit;

I.3.2 Security Considerations for the Recycle Bin

In this release of Oracle Database Vault, the RECYCLE BIN feature has been disabled, and a command rule has been created to prevent it from being turned on. If you need to use the RECYCLE BIN, disable the command rule ALTER SYSTEM and then enable the RECYCLE BIN as follows:

SQL> ALTER SYSTEM SET RECYCLEBIN=ON;

I.3.3 Security Considerations for the CREATE ANY JOB and CREATE JOB Privileges

In this release of Oracle Database Vault, the CREATE JOB privilege has been revoked from the DBA and the SCHEDULER_ADMIN roles. Ensure that this change does not affect your applications.

I.3.4 Security Considerations for the CREATE EXTERNAL JOB Privilege

The CREATE EXTERNAL JOB privilege was introduced in Oracle Database 10g Release 2 (10.2). It is required for database users who want to execute jobs that run on the operating system outside the database. By default, this privilege is granted to all users who have been granted the CREATE JOB privilege. For greater security, revoke this privilege from users who do not need it and then grant it only to those users who do need it.

I.3.5 Security Considerations for the LogMiner Packages

In this release of Oracle Database Vault, the role EXECUTE_CATALOG_ROLE no longer has EXECUTE privileges granted by default on the following LogMiner packages:

• DBMS_LOGMNR

• DBMS_LOGMNR_D

• DBMS_LOGMNR_LOGREP_DICT

• DBMS_LOGMNR_SESSION

Ensure that this change does not affect your applications.

I.3.6 Security Considerations for the ALTER SYSTEM and ALTER SESSION Privileges

Be aware that trace and debug commands have the potential to show Oracle database memory information. Oracle Database Vault does not protect against these commands. To help secure the Oracle database memory information, Oracle recommends that you strictly control access to the ALTER SYSTEM and ALTER SESSION privileges. These privileges can be granted by the user SYS when connected as SYSDBA and by any user granted the DBA role.

Oracle also recommends that you add rules to the existing command rule for ALTER SYSTEM statement. You can use Oracle Database Vault Administrator to create a rule and add it to a rule set.

Example I-4 shows how you can create such a rule. This rule prevent users with ALTER SYSTEM privilege from issuing the command ALTER SYSTEM DUMP. Log in to SQL*Plus as the Oracle Database Vault Owner when you create this command rule.

SQL> CONNECT dv_owner_acct
Enter password: password
SQL> begin
   2 dbms_macadm.create_rule('NO_SYSTEM_DUMP',
   3 '(INSTR(UPPER(DVSYS.DV_SQL_TEXT),''DUMP'') = 0)');
   4 end;
/
SQL> exec dbms_macadm.add_rule_to_rule_set
   2 ('Check trigger init parameter','NO_SYSTEM_DUMP');
SQL> commit;

Alternatively, you can use Oracle Database Vault Administrator to create and add this rule to the rule set. See "Creating a Rule to Add to a Rule Set" for more information.

I.3.7 Security Considerations for Java Stored Procedures and Oracle Database Vault

A definer's rights stored procedure relies on the privileges of the owner of the stored procedure to access objects referenced within the stored procedure. Invoker's rights stored procedures rely on the privileges of the executor of the stored procedure to access objects referenced within the stored procedure. The default for Java stored procedures is invoker's rights.

Oracle Database Vault security works by intercepting calls made within the Oracle Database.

For Java stored procedures with definer's rights, the execution of the stored procedure is not blocked and realm protection is not enforced. However, underlying objects accessed by the Java stored procedure can be protected by Oracle Database Vault command rules.

For Java stored procedures with invoker's rights, the execution of the stored procedure is not blocked. However, underlying objects accessed by the Java stored procedure are protected by both Oracle Database Vault realms and command rules.

COLUMN plsql_owner FORMAT a8
COLUMN plsql FORMAT a30
COLUMN java_owner FORMAT a8
COLUMN java FORMAT a30
SPOOL java_dr
select distinct plu.name plsql_owner, plo.name plsql,
                ju.name java_owner, jo.name java
 from obj$ plo, user$ plu, user$ ju, obj$ jo, procedurejava$ j
 where jo.name=j.classname and ju.user#=jo.owner# and ju.name=j.ownername
   and jo.type#=29 and bitand(jo.flags, 8)=0
   and plo.owner#=plu.user#
   and j.obj#=plo.obj# and bitand(plo.flags, 8)=0
   and ju.name not in ('SYS', 'ORDSYS') 
   and jo.obj# in
   (select d_obj# from dependency$ connect by d_obj#=prior p_obj#
   start with p_obj#=(select obj# from obj$ where name='java/sql/Connection'
      and owner#=0));
SPOOL off

SQL> CREATE OR REPLACE PACKAGE SCOTT.MYPACKAGE AS
    tmp varchar2(200) := 'TEST';  -- dummy variable
    FUNCTION empcount RETURN VARCHAR2;
    end;
    /
 
Package created.
 
SQL> CREATE OR REPLACE PACKAGE BODY SCOTT.MYPACKAGE AS
    FUNCTION empcount RETURN VARCHAR2 AS LANGUAGE JAVA
    NAME 'emp_count.count() return java.lang.String';
    END;
    /
 
Package body created.

COLUMN plsql_owner FORMAT a8
COLUMN plsql FORMAT a30
COLUMN java_owner FORMAT a8
COLUMN java FORMAT a30
spool java_ir
 
select distinct plu.name plsql_owner, plo.name plsql,
                ju.name java_owner, jo.name java
 from obj$ plo, user$ plu, user$ ju, obj$ jo, procedurejava$ j
 where jo.name=j.classname and ju.user#=jo.owner# and ju.name=j.ownername
   and jo.type#=29 and bitand(jo.flags, 8)=8
   and plo.owner#=plu.user#
   and j.obj#=plo.obj# and bitand(plo.flags, 8)=0
   and ju.name not in ('SYS', 'ORDSYS')
   and jo.obj# in
   (select d_obj# from dependency$ connect by d_obj#=prior p_obj#
   start with p_obj#=(select obj# from obj$ where name='java/sql/Connection'
      and owner#=0));
 
spool off

SQL> connect u1
Enter password: password
Connected.
SQL> select * from session_privs;
 
PRIVILEGE
----------------------------------------
CREATE SESSION
SELECT ANY TABLE
CREATE PROCEDURE
EXECUTE ANY PROCEDURE
 
Protecting access on direct SQL access 
 
SQL> select count(*) from scott.emp;
select count(*) from scott.emp
                           *
ERROR at line 1:
ORA-01031: insufficient privileges
 
Now show protecting access through Java
 
SQL> select scott.mypackage.empcount from dual;
select scott.mypackage.empcount from dual
       *
ERROR at line 1:
ORA-01031: insufficient privileges
ORA-06512: at "SCOTT.MYPACKAGE", line 2

I.3.8 Security Considerations for External C Callouts and Oracle Database Vault

For external C callouts with definer's rights, the execution of the callout is not blocked and realm protection is not enforced. However, underlying objects accessed by the external C callout are protected by Oracle Database Vault command rules. The default for external C callouts is invoker's rights.

For external C callouts with invoker's rights, the execution of the external C callout is not blocked. However, underlying objects accessed by the external C callouts are protected by both Oracle Database Vault realms and command rules.

Oracle Database Vault security works by intercepting calls made within the Oracle Database.

spool external_wrap
select u.name OWNER, o.name object, o.type#, o.flags from
  sys.obj$ o, sys.user$ u
where o.owner# = u.user# and
u.name not in ('MDSYS', 'ORDSYS', 'SYS') and o.obj# in (
select d_obj# from dependency$ connect by d_obj#=prior p_obj#
   start with p_obj# in (select obj# from library$ where property = 0))
order by owner, object;
spool off

create or replace package scott.mytestpkg1 as
tmp integer;  /* create a dummy plsql variable */
function test return binary_integer;
end;
/
 
create or replace package body scott.mytestpkg1 as
function test return binary_integer as language C library
c_utils name "test" with context parameters(context,
            return indicator short,
          return int);
end;
/

spool external_standalone
select u.name OWNER, o.name object, o.type#, o.flags from
  sys.obj$ o, sys.user$ u
where o.owner# = u.user# and
u.name not in ('MDSYS', 'ORDSYS', 'SYS') and
o.type# in (7,8) and o.obj# in (
select d_obj# from dependency$ connect by d_obj#=prior p_obj#
   start with p_obj# in (select obj# from library$ where property = 0))
order by owner, object;
spool off

SQL> connect u1
Enter password: password
Connected.
SQL>
SQL> select * from session_privs;
 
PRIVILEGE
----------------------------------------
CREATE SESSION
SELECT ANY TABLE
CREATE PROCEDURE
EXECUTE ANY PROCEDURE
 
SQL>
SQL> select count(*) from scott.emp;
select count(*) from scott.emp
                           *
ERROR at line 1:
ORA-01031: insufficient privileges
 
SQL> select test from dual;
TEST
-------------------------------------------------------------------------------
14
 
SQL>
SQL> select scott.mypackage1.test from dual;
select scott.mypackage1.test from dual
       *
ERROR at line 1:
ORA-01031: insufficient privileges
ORA-06512: at "SCOTT.MYPACKAGE1", line 2