| Oracle® Database Vault Administrator's Guide Oracle9i Release 2 (9.2.0.8) Part Number B32509-05 |
|
|
View PDF |
| Oracle® Database Vault Administrator's Guide Oracle9i Release 2 (9.2.0.8) Part Number B32509-05 |
|
|
View PDF |
Oracle Database Vault restricts access to application data from many privileged users and roles in the database. However, in some cases, Oracle Database Vaults trusts certain roles and privileges.
Table C-1 lists the trusted roles and privileges that are created when you install Oracle Database Vault.
Table C-1 Trusted Oracle Database Vault Roles and Privileges
| Role or Privilege | Status | Description |
|---|---|---|
|
|
Open |
Role created during installation and used for creating new database accounts |
|
|
Open |
Role created during installation and used for managing realms, factors and command rules. This user cannot add himself or herself to realm authorizations, nor can users who have the |
|
|
Enabled |
Privilege created during Oracle Database installation. Required by some Oracle features. See "Managing SYSDBA Access" for guidelines on managing |
|
|
Enabled |
Privilege created during Oracle Database installation. Database startup and shutdown. Granted to |
Several accounts and roles have very powerful privileges in a default Oracle Database installation. You should limit these accounts and roles only to trusted individuals.
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.
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.
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. Remember that SYSDBA actions are audited by default. See Oracle Database Installation Guide for more information about the OSDBA group.
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.
Follow these configuration and security guidelines:
Security Considerations for SYSDBA Operating System Authentication
Security Considerations for SYS Users Accessing Realm Objects
Security Considerations for the DBMS_MACUTIL.GET_SQL_TEXT Function
Security Considerations for the ALTER SYSTEM and ALTER SESSION Privileges
Security Considerations for Java Stored Procedures and Oracle Database Vault
Note:
Be aware of the following:Installing patches and new applications might re-grant some of the privileges that Oracle recommends that you revoke in this section. Check these privileges after you install patches and new applications to verify that they are still revoked.
When you revoke EXECUTE privileges on packages, ensure that you grant EXECUTE on the packages to the owner, check the package dependencies, and recompile any invalid packages after the revoke.
To find users who have access to the package, log in to SQL*Plus as SYSTEM and issue the following query.
SELECT * FROM dba_tab_privs
WHERE table_name = package_name;
package_name is the name of the package you are looking for.
To find the users, packages, procedures, and functions that are dependent on the package, issue this query:
SELECT owner, name, type
FROM all_dependencies
WHERE referenced_name = package_name;
Note that these two queries do not identify references to packages made through dynamic SQL.
See Also:
Be careful about whom you grant SYSDBA privileges to in the operating system DBA group. Only grant this privilege to trusted individuals.
By default, SYS is not allowed to access realms. To grant SYS access to realm objects, you can add SYS as realm participant to realm objects.
Be careful about adding commented text to SQL on which you plan to run the DBMS_MACUTIL.GET_SQL_TEXT function. This function cannot filter out comments within SQL text.
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.
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
Ensure that this change does not affect your applications.
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 C-1 shows how you can create this type of 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.
Example C-1 Adding Rules to the Existing ALTER SYSTEM Command Rule
CONNECT dbvacctmgr
Enter password: password
BEGIN
DBMS_MACADM.CREATE_RULE('NO_SYSTEM_DUMP',
'(INSTR(UPPER(DVSYS.DV_SQL_TEXT),''DUMP'') = 0)');
END;
/
EXEC DBMS_MACADM.ADD_RULE_TO_RULE_SET
('Check Trigger Init Parameter','NO_SYSTEM_DUMP');
EXEC DVSYS.DBMS_MACADM.UPDATE_COMMAND_RULE
('ALTER SYSTEM', 'Check Trigger Init Parameter', 'SYSADMIN', '%', 'Y');
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.
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.
By default, the EXECUTE ANY PROCEDURE privilege is granted to the DBA, EXPORT_FULL_DATABASE, and IMPORT_FULL_DATABASE roles. You can limit access to Java stored procedures by revoking the EXECUTE ANY PROCEDURE from users and roles who do not require it, and then by selectively assigning them read privileges. Note also that revoking the EXECUTE ANY PROCEDURE from users further secures the database by limiting access to SYS-owned packages.
Oracle recommends that you analyze your Java stored procedures when using Oracle Database Vault to maximize security. You can do so by following these steps:
Step 1: Identify the Java Stored Procedures Created with Definer's Rights
Step 2: Find the Java Stored Procedures That Access Realm-Protected Objects
Step 3: Create a Package to Wrap Procedures Accessing Realm-Protected Objects
Step 4: Identify the Java Stored Procedures Created with Invoker's Rights
Step 6: Verify Oracle Database Vault Protection for Java Stored Procedures
Step 7: Secure the Invoker's Rights for New Java Stored Procedures
Identify the Java stored procedures that were created with definers rights by running the query in Example C-2. This query returns only Java stored procedures that connect to the database, and then it spools the results to the file java_dr.lst.
Example C-2 Query to Identify Java Stored Procedures with Definers Rights
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
Analyze the Java stored procedures you queried in Step 1 and determine whether any of them access Realm protected objects. You can find a list of the realm-secured objects in the current database instance by using the DBA_DV_REALM_OBJECT view, which is described in "DBA_DV_REALM_OBJECT View".
For Java stored procedures that do access realm-protected objects, create a PL/SQL package to wrap the Java stored procedure. Due to PL/SQL optimizations, the PL/SQL package wrapper must have a dummy variable defined in the package header. Adding the dummy variable enables Oracle Database Vault to intercept and block execution of Java stored procedures. Bear in mind that while this method does secure the execution of the Java stored procedure, it does not provide protection against calls to other Java stored procedures that may be embedded.
Example C-3 shows the PL/SQL package mypackage being created to wrap the Java class emp_count.
Example C-3 Creating a PL/SQL Wrapper
CREATE OR REPLACE PACKAGE SCOTT.MYPACKAGE AS tmp varchar2(200) := 'TEST'; -- dummy variable FUNCTION empcount RETURN VARCHAR2; END; / CREATE OR REPLACE PACKAGE BODY SCOTT.MYPACKAGE AS FUNCTION empcount RETURN VARCHAR2 AS LANGUAGE JAVA NAME 'emp_count.count() return java.lang.String'; END; /
Next, you are ready to identify the Java stored procedures that were created with invoker's rights. Do so by running the query in Example C-4. This query only returns Java stored procedures that connect to the database, and then it spools the results to the file java_dr.lst.
Example C-4 Identifying Java Stored Procedures with Invoker's Rights
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
Oracle Database Vault realm and command rules are enforced for invoker's rights stored procedures. However, it can be useful to even block execution on Java stored procedures. You can do this by following Step 3: Create a Package to Wrap Procedures Accessing Realm-Protected Objects.
Verify that Oracle Database Vault is protecting your Java stored procedures. Example C-5 show how you can test Oracle Database Vault security. Log in to a tool such as SQL*Plus. Then try to access a realm-protected object directly and execute a Java stored procedure to access a realm protected object.
Example C-5 Testing Oracle Database Vault Protection for Java Stored Procedures
SQL> CONNECT u1
Enter password: password
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;
ERROR at line 1:
ORA-01031: insufficient privileges
--Now show protecting access through Java
SQL> SELECT SCOTT.MYPACKAGE.EMPCOUNT FROM DUAL;
ERROR at line 1:
ORA-01031: insufficient privileges
ORA-06512: at "SCOTT.MYPACKAGE", line 2
If you are writing new Java stored procedures, ensure that Java classes execute with invoker's rights and define them in a PL/SQL package specification. Remember, it is important to include a dummy PL/SQL variable in the package header. Adding the dummy variable enables Oracle Database Vault to intercept and block execution of Java stored procedures.
|
 Copyright © 2006, 2008, Oracle. All rights reserved. Legal Notices |
|