SQL> col name for a40
SQL> col value for a100
SQL> set lines 220
SQL> select name,value from v$parameter where isdeprecated='TRUE';
NAME VALUE
---------------------------------------- ----------------------------------------------------------------------------------------------------
lock_name_space
instance_groups
pre_page_sga TRUE
resource_manager_cpu_allocation 0
active_instance_count
db_block_buffers 0
buffer_pool_keep
buffer_pool_recycle
fast_start_io_target 0
serial_reuse disable
rdbms_server_dn
cursor_space_for_time FALSE
plsql_v2_compatibility FALSE
plsql_debug FALSE
background_dump_dest /opt/oracle/product/23c/dbhomeFree/rdbms/log
user_dump_dest /opt/oracle/product/23c/dbhomeFree/rdbms/log
commit_write
sql_trace FALSE
parallel_adaptive_multi_user FALSE
asm_preferred_read_failure_groups
20 rows selected.
SQL>
There are a small number of interest to securing the database. Lets have a look at some:
- rdbms_server_dn: This is used to get the distinguished name of the server (DN) from the database for use in enterprise roles when they are in an enterprise directory server
- plsql_v2_compatibility :This is deprecated for a long time and this allows if set to TRUE old behaviour to be used in PL/SQL. Use of this could occur if you use a very old third party PL/SQL based application. If the application is under your control, change it!
- plsql_debug :This parameter is retained for backwards compatibility but has been deprecated for some time as above. If this were set to TRUE then all PL/SQL would be compiled with debug so could be used to intercept a PL/SQL procedure/package at run time and more easily steal data
- background_dump_dest :Also deprecated for a long time since 12.1 but retained. It is ignored if set if the diagnostic_dest is used. If used this is the location of the alert log and also background process trace files. We should be aware that these files can contain structural details of the database and also in some cases data (in SQL or in memory dumps). We should control the locations of where the alert log is written and also these trace files BUT importantly make sure that they are managed; archived, purged and be aware that that can contain useful information to a hacker
- user_dump_dest :This is also deprecated a long time and also affected by the diagnostic_dest. This parameter controls where user created trace is written and for the same reasons as above these trace files must be managed, archived, purged as they can contain data that is not protected in the database with database security
- sql_trace :This parameter is dangerous as it could be used to kill the database by enabling it at the database level. If this were the case and the file systems are not adequate then the database could be hung. Also remember that setting sql_trace effectively gives only Oracle v6 trace as there are no binds and waits. Oracle suggest that you use DBMS_MONITOR or DBMS_SESSION instead and trace should be targeted not system wide
A lot of these parameters are deprecated for some time and not newly deprecated in 23c and should not be used for reasons above. Check in your database that these are not set and be aware that security is everywhere in an Oracle database.
#23c #dbsec #oracleace #oracle #security #parameters
