Oracle Security

I.

Introduction

Database management systems have been around for many years as a repository of data.
During the last several years the relational database management system has occupied the
industry as it moves to store large amounts of data in an easy to use form. With the
advent of the Client/Server Architecture the database management system has become a
key component within the application system. In fact, the database management system
is the heart of the Client/Server Architecture.
The database management system allows for multiple users to access various data fields
at the same time to complete application transaction processing. The database
management system protects the integrity of each data field during updates to ensure that
only one transaction at a time affects the specific data field. Concurrent access is a key
attribute of the database management system in that it also allows many users to work on
different data fields at the same time. The database management system maintains the
necessary locks to protect the data until each concurrent transaction is completed.
All of the application data and many of the application programs are stored within the
database management system. In addition, we will see that the database allows for the
physical distribution of the data across a computer network. This capability allows the
designer to physically move the application data for performance or security reasons
without affecting the end-users interface.
The relational database management system allows provides for data integrity checks that
can be enforced each time the application data is access, modified, or deleted. These
integrity checks help to ensure that the application data is properly maintained as it
relates to other data fields or entities.
The database management system is a complex software product that sets the tone for
how the Client/Server application works within a complex networked environment.

II. What is a Oracle Database Management System

Oracle is a relational database management system. Oracle Corporation was one of the
first companies to design a true relational design paradigm. It popularity has allowed
Oracle Corporation to develop many versions of its database to run on different
machines and under many operating environments. Along with its technical capabilities,
the Oracle databases portability has provided many companies the cornerstone to build
sophisticated Client/Server applications.
The Oracle database management system is a collection of data within a table definition.
A table is nothing more than a two-dimensional structure similar to a spreadsheet. The
table is defined with columns (fields) across the top of the table and rows (records) down
the side of the table. The table can have many columns or fields and the number of rows
depends on how many records the table holds at any given point in time.
An application can be made up of many tables that are related to each other for
transaction processing.
All of the application tables are part of the makeup of a logical structure called a
database. The database is comprised of tables, views, indexes, clusters, sequences, and
stored procedures. Each of these will be defined as we unfold the specific of how they
work. Right now it is important to note that the payroll application stores its data in an
Oracle database that may be called Payroll. After the database is named or defined to
Oracle, the various logical structures are described to the newly created database to
complete the definition.
The database also has a physical structure. Each of the logical structures are grouped
according to use into logical storage units called tablespaces. These tablespaces are then
mapped to one or more physical files. The complete database definition is called a
schema definition.
One key component of the Oracle database management system is the data dictionary.
The data dictionary of an Oracle database is a set of system owned tables and views that
are used to list all of the entities defined to the database management system. What this
means is that for each user, table, column, and etc. defined for all the application
databases are stored in the data dictionary. In this way the Oracle database management
system can real-time authenticate who is authorized to access application data. Every
time an administrator creates a new database or table, the Oracle database management
system automatically updates the proper data dictionary table. These data dictionary
tables will be important to us when we are reviewing the integrity and control aspects of a
system.
It all boils down to two levels of activity against the application database. A transaction
submitted by the user in either a dynamic or static form is processed against the database
if the user is authorized to perform the activity.

Static activity comes in the form of a program or procedure. Static programs or

procedures are compiled processes that are designed to perform a certain activity within
the application database.
Dynamic activity comes in the form of a Query. This query is usually called Structure
Query Language (SQL). These requests are submitted and resolved dynamically by the
database management system.
The required user authority to run these transaction types will be the discussion of later
chapters.
The Structure Query Language is divided into three major parts. The first is called Data
Definition Language (DDL) and includes create, alter, and drop statements for
creating objects such as tables. To use these commands you must have been granted a
certain level of authority within the database. The second, is called Data Manipulation
Language (DML) and includes insert, delete, update, and select. Again, the user
who submits these commands must have the proper authority to affect the database. And
finally, is the Data Control Language (DCL) which includes grants and revokes to
allow users to perform activities within the database.

III.

Database Initialization

For a database to start and be available for system use requires three steps:
1. Start an instance
An instance is an allocation of the appropriate system processes and memory buffers for
database processing.
Before an instance is actually created, the Oracle database management system reads a
parameter file (e.g. INIT.ORA), which determines how the instance is initialized. To see
the current parameter settings issue the following command: SQLDBA> SHOW
PARAMETERS BLOCK
This file includes several security and control parameters that affect the overall integrity
of transaction processing. These key parameters are as follows:
- AUDIT_TRAIL

Enables or disables the audit trail. It is disabled by default

- DB_DOMAIN

Allows for the unique identification of database names

- FIXED_DATE

Should be set to null

- IFILE
integrity

Names of other parameter files that may affect system

- MTS_LISTENER_PORT

Sets up listen process for specific network activity

- OS_AUTHENT_PREFIX Sets the prefix to identify operating system authentication

(default = OPS$)
- OS_ROLES
roles.

Set to true allows the operating system to identify each usernames

2. Mount the database

Mounting a database is the process of associating a database with a previously started
instance.
3. Open the database

Opening a mounted database is the process of making the database available for normal
database operations. Any valid user can connect to the database and access its
information once it has been opened. In most cases, the database administrator opens the
database so that it is available for general system use.
Starting and stopping the database are powerful administrative functions and are
protected by the Oracle database management system by connecting to the database as
INTERNAL. INTERNAL is an operating system privilege Only the database
administrators should have the capability to connect to a database using INTERNAL.
Connection as INTERNAL allows the user unlimited access to the database. The
INTERNAL keyword should be protected by the OSOPER and OSDBA roles. Roles are
the easiest way to delineate the capability within the Oracle database management
system. Roles are defined in more details in the section on database security.

IV. Database Administration

The database administration function is an individual or group that is responsible for
setting up, installing, and administrating the Oracle RDBMS. This administration
function is giving special privileges to operate on the database. In fact, these
administrators have full access rights to system and application data. For this reason the
right to be a database administrator should be highly restricted.
Anyone with database administration privileges can enroll users, create roles, grant out
access rights, and create databases with all the logical structural components. All
database administrators should be separated from the day to day operations of
programming and security administration.
To perform many of the administrative duties, the database administrator must be able to
execute operating system commands. So we need to review the operating system
accounts to determine who has been giving this capability. In addition, the SQL*DBA
program requires that the administrators operating system account be giving the
capability to execute SQL*DBA commands. Access to the database administrators
operating system account and to these commands should be tightly controlled.
Within the Oracle RDBMS, specifically within the data dictionary an administrator can
be identified by a pre-defined role named DBA. Anyone granted privileges to the
DBA role has all database system privileges. For this reason only authorized
administrators should be granted the rights to this role.

During the installation process for Oracle, two user accounts are automatically created
and granted DBA role. The two user accounts are:
- username SYS

password CHANGE_ON_INSTALL

-username SYSTEM

password MANAGER

The SYS account owns all the database tables and views for the data dictionary. To
protect the integrity of the data dictionary tables, the password for the SYS account
should be changed.
The SYSTEM account is automatically enrolled with all system privileges for any new
database that is created. Because of its critical nature, the password for the SYSTEM
account should also be changed immediately after the Oracle RDBMS is installed.
In order for the database administrator to perform their job responsibilities, certain
database utilities are provided for their use. One in particular is the SQL*DBA utility
which was mentioned earlier. Another is the SQL*Loader which is used to load data
from standard operating system files. The Import/Export utility allows the administrator
to move existing data from one Oracle database to another. It has been our experience
that some of these utilities may store the administrators password in clear text. These
utilities are placed in operating system directories and should be restricted to the database
administrator. But it the directories where these utilities are stored are not properly
protected, then special operating system command could be used to search and find
password strings. To prevent any exposure, all passwords for any level of privileges
including administrators rights should only be stored in a one way encrypted fashion.

V. Database Security
Oracle is a comprehensive database management system that has many system and
application objects. Each of these objects need to be accessed in some manner by
different users. In order to allow authorized users the capability to perform their work
without compromising the integrity of the system, Oracle RDBMS has a discretionary
access control system. With the discretionary access control system users can be
assigned privileges to objects. A privilege is a permission to access a named object in a
prescribed manner.
The first step in the security process is to create a user. Users can be created using either
the Create User dialog box of SQL*DBA or the SQL command CREATE USER. A
typical example of an Oracle RDBMS authentication process would be as follows:
CREATE USER frank

IDENTIFIED BY hop-scot
DEFAULT TABLESPACE
p_data
TEMPORARY TABLESPACE t_data
QUOTA 250M ON sys_test
QUOTA 800M ON p_data
PROFILE manager;
If we were interested in authenticating this user through the operating system, the CREAT
USER statement would be set to:
CREATE USER OPS$frank
IDENTIFIED EXTERNALLY
....;
OPS$ is the prefix set in the OS_AUTHENT_PREFIX parameter. If this parameter is
different then the prefix would also be set to match this parameter.
Authentication of a user to the database can be accomplished either by the operating
system or by the associated Oracle database as indicated above. A review of the
authentication process would be required to ensure that proper integrity checks are
performed. These checks or characteristics include:
- password constructure rules
- password aging
- violation attempts reporting
To create a user the creator must have CREATE USER system privilege. Normally, this
would be the database or security administrator. Any of the security settings can be
altered by the administrator. The actual user can change their own passwords but are
restricted from changing their security domain.

The second step in the security process is the user profile. User profile are used to restrict
resource limits. These profile assign values for the use of tablespaces and space usage
quotas and CPU time. Each user can be assigned only one profile at any given time.
Profiles can only be assigned to users and not to roles. If a user is not assigned a profile
then the system DEFAULT profile is used to set the users limits. The DEFAULT profile
is set up initially as UNLIMITED.
The data dictionary has a complete listing of all users and their associated profiles. This
includes the following data dictionary views:
- ALL_USERS
username

Information about all users of the database

user_id
created
- USER_USERS
Information about the current user
username
user_id
default_tablespace
temporary_tablespace
created
- DBA_USERS
Information about all users of the database
username
user_id
password (encrypted)
default_tablespace
temporary_tablespace
created
profile
- USER_TS_QUOTAS
Tablespace quotas for the user
tablespace_name
bytes
max_bytes
blocks
max_blocks
- DBA_TS_QUOTAS Tablespace quotas for all users
tablespace_name
username
bytes
max_bytes
blocks
max_blocks
- USER_RESOURCE_LIMITS Displays the resource limits for the current user
resource_name
limit
- DBA_PROFILES Profiles assigned to each user
profile
resource_name
limit
- RESOURCE_COST Cost for each resource
resource_name
unit_cost
The third step in the security process is the establishment of privileges.
A privilege is a right to execute a particular type of SQL statement or access to another
users object. Privileges can be granted to a user explicitly. Privileges can also be
granted to roles which acts like a named group for privileges. For example the privileges

to select and update to the PAY table can be granted to the role named PAYROLL, which
in turn can be granted to Anne and Frank. The assignment of privileges to roles is an
easier way to manage access rights.
There are two categories of privileges. These are the system and object privileges.
System privileges are usually only assigned to security and database administrator. There
are many system privileges and each one allows the user to perform selective activity on
a particular object. The key system privileges that require review are who has the
following:
ALTER DATABASE
Allows grantee to alter the database.
GRANT ANY PRIVILEGE Allows grantee to grant any system privilege
CREATE PROFILE Allows grantee to create profiles. (Review ALTER and DROP too)
CREATE ROLE
Allows grantee to create roles (Review ALTER and DROP
too)
RESTRICTED SESSION
Allows grantee to connect after the database is started using
STARTUP
RESTRICT. The special OSOPER and OSDBA roles contain this
privilege.
CREATE SNAPSHOT
Allows grantee to create snapshots of data
ALTER SYSTEM
Allows grantee to issue ALTER SYSTEM statements
CREATE USER
Allows grantee to create users.
ALTER USER
Allows grantee to alter other users.
The granting of system privileges to users or roles can be accomplished by using the
SQL*DBA dialog box Grant System Privileges/Roles or Revoke System
Privileges/Roles. Or the SQL commands of GRANT and REVOKE. Only users granted
a system privilege with the WITH ADMIN OPTION or a user with GRANT ANY
PRIVILEGE system privilege can grant or revoke a system privilege to or from other
users or roles of the database.
The fourth step in the security process is the establishment of roles.
Roles are named groups of related privileges that are granted to users or other roles.
Roles allow for easier security administration. They also allow for the change in the role
privileges and all the security domains of all users granted the role are automatically
changed by reference. Roles allow for selective enabling or disabling of capabilities.
Passwords can be incorporate to verify the use of a role by an application or a user.
An application role is used to define the privileges necessary to run an application.
A user role is used to group user that have common privilege requirements.
A role can have system or object level of privileges granted to it. It can be granted to
other roles. Any user can be granted a role and the role can be enabled or disabled. A
users security domain does not include any role that is not enabled. Any user with

GRANT ANY ROLE system privilege can grant or revoke any role to or from other users
or roles of the database. Any user granted a role with the WITH ADMIN OPTION can
grant or revoke the role to or from other users or roles of the database.
Within a database, each role or name must be unique and a username and a role can not
be the same.

Pre-defined roles are automatically defined for Oracle databases. These roles are special
but can be modified by an authorized administrator. The pre-defined roles are the
following:
- CONNECT The privileges are alter session, create cluster, create database link, create
sequence
cerate synonym, create table, create view
- RESOURCE The privileges are create cluster, create procedures, cerate sequence, create
table
create trigger
- DBA

The privileges are all system privileges with admin option

- EXP_FULL_DATABASE The privileges are select any table, backup any table, insert,
delete,
and update on sys.incvid, sys.incfil, and sys.incexp.
- IMP_FULL_DATABASE

The privileges are become user

The data dictionary has a listing of all the system privileges and roles. These tables
include the following:
- DBA_ROLES
- DBA_ROLE_PRIVS
- DBA_SYS_PRIVS
- ROLE_ROLE_PRIVS
- ROLE_SYS_PRIVS
- ROLE_TAB_PRIVS
- SESSION_PRIVS
- SESSION_ROLES
Each user database has a user called PUBLIC. The PUBLIC user has access to any
resources granted to this user. Any user that can connect to the database can use the

PUBLIC privileges. A review of the privileges granted would ensure that only authorized
and required access has been granted to this special user.

VI. Application Security

The user of a database application must first sign-on to the database either through the
operating system or directly into the database management system. Once onto the system
an application level password may be required. This level of password would be part of
the application design. Once the user is properly authenticated to the application work
can begin.
There are two primary ways that a user can access data for an application. The first is
direct access to the database tables. This access level allows the user to issue direct SQL
statements (dynamic requests) such as select, insert, delete, and update. In order for a
user to use these commands, the user must have been granted table level access for each
command. Another way that the user could be granted this level of access is if the table
has been granted to the PUBLIC user. If a table has been granted to PUBLIC then any
command by any user can be used against the table. Obviously, PUBLIC definitions are
a major exposure in todays Client/Server world. This is because many client programs
such as Access, Paradox, Powerbuilder, and SQL/PLUS are available on client platforms
that would allow a user to submit a dynamic request.
The second and preferred way to access the application is to allow the use to EXECUTE
a stored procedure. Stored procedures are like programs in that they are complied and
stored in executable form in the data dictionary. A user can be granted EXECUTE
authority to the stored procedures which allows the user to run the procedure to affect the
application data. This places a high reliance on the ability of the procedure to only
perform authorized activity.
Procedures are also preferred due to their increased performance characteristics.
Procedures are stored in the data dictionary on the file server close to the data. This
architecture allows the procedure to use CPU speed verses network speed to perform the
activity. Compare this with a dynamic SQL which is issued from the client across the
network. With a dynamic SQL the work is split between the client and the server. For
dynamic queries against large databases, the performance of the system may be affected.
At a minimum the performance and resulting service level may fluctuate greatly
depending on how many queries the users are running. For this reason and for security
and control it is preferred not to allow users direct access to the database tables. Some
companies allow direct access for SQL selects. This eliminates the direct update risk but
does not eliminate the performance issue that may occur.
So if we look at the process of how to establish a user within a Client/Server environment
running Oracle as the database management system, the following must occur.
First the user must be properly authenticated. This as describe before would be
completed by submitting a userid and password from the client to the server. This
authentication could be completed at the operating system level or at the database
management system level. This authentication has a major weakness today in that the

userid and password may travel across the network in clear text. Certain operating
system have eliminated this exposure by going to a challenge and response system. A
challenge and response system allows the user to submit their userid and password with a
one time ticket mechanism. This system incorporates the users password into a one time
key that is resolved by the server. This eliminates the ability to capture the clear text or
even the encrypted version of the password and replay it to sign on as that specific users.
Some Systems that provide for the challenge and response are the Novell operating
system, IBM LAN Server, and Microsofts NT. At the database level Oracle and
Sybases System 10 have options that allow the administrator to set up a challenge and
response authentication.
Whether the user is authenticated through the operating system or by the database
management system the user always has to be defined to the Oracle database
management system as a valid user. This is the only way that the Oracle RDBMS can
check the authorization level of the user as they access database objects.
Next the user would start to work with their application. Most of the time the user would
be setting at their workstation and using a Graphical User Interface (GUI) or an Object
Oriented User Interface (OOUI). When the user clicks on some activity the front-end
program would submit a dynamic SQL request or call a remote procedure that is stored in
the data dictionary. The bottom line is that the user will be able to affect the application
data. So in order to validate the user authority, we need to perform the following:
1. Obtain a schema definition of the database that is being reviewed. This represents all
the tables for the
database, their relationships to each other and the columns (fields) that are in each
table.
2. By reviewing the columns within each table determine which columns are sensitive or
critical.
3. Determine who has what access rights for each of the sensitive or critical columns.
This would effectively
be either a user, a stored procedures or a role. Also be sure that the tables have not be
granted to
Public.
4. If a user has direct table authority such as SQL select, update, delete, insert, and etc,
then this user could
write a dynamic SQL command to directly affect the applications data. To understand
the significance of
this level of authority, it is important to remember that any client program today
probably can issue SQL
commands. This means that a user that is using an applications GUI or OOUI could
have been granted

direct authority into the database tables as part of the application design. The user in
most cases would
not even know that this level of authority has been granted to them. As long as the
user goes through
the GUI or OOUI front-end then all the application edits would be properly
performed. But if the user
wanted to buy and install their own front-end tool that generates dynamic SQL they
would be able to
access the database tables without going through the applications front-end edits. So
the bottom line
is try not to provide direct table authority for a user or a role. Force everyone to user
stored procedures
when accessing a database.
5. Review all roles that have access to the applications sensitive or critical data fields.
Verify which users
are granted the right to use the role(s). Determine that each user needs the role
privileges to perform
their job assignment. An application role is one that is granted all privileges necessary
to run a
given database application. A user role is one that is created fro a group of database
users with
common privilege requirements.
6. Review all stored procedures that have access to the applications sensitive or critical
data fields. Verify
which users are granted execute authority to the procedure. Determine that each user
needs the
capability that the stored procedures provide. There is only one object privilege for
procedures
including stand-alone procedures and functions, and packages. A user must have
EXECUTE
authority. Packages allow for the storage of multiple procedures and functions. Any
procedure or
function granted to PUBLIC can be used by any user that has access to the system.
7. Obtain a listing of all of the profiles for the application users. Review the profiles to
ensure that
security standards are being met.
8. Obtain a listing of all the views for the application tables. Determine if the user that
has access to the
view definition should have this level of access.
Views are a security mechanism to reduce the full access rights to a table. By creating a
view of a table, only the pertinent columns can be displayed within the view. Thereby

restricting the user to those columns only. Views can restrict the columns that are
displayed and can use attributes such as loan amounts less than $25,000.00 as further
restriction of the column itself. By using views every column of every table along with
its attributes can be restricted to only authorized users.
First the view is created by an administrator and then the user is granted the privilege to
use the view. To use the view, a user only is required the appropriate privileges for the
view. The user does not require any privileges for the base object (base table definition)
that underlie the view.
9. Obtain a listing of all the triggers for the application tables. Determine if the triggers
are properly constructed to help ensure the integrity of the application system.
Triggers are an Oracle RDBMS implementation that allows a procedure to be executed
when a table is affected by an SQL insert, update, or delete statement. Triggers are like
stored procedures but they are used to check referential integrity. For example, lets say
that the application transaction is getting ready to delete a particular customer. The
normal operation would be to just match the customer number and delete the entry and go
on to the next transaction. But what if the customer had orders in a database table called
ORDERS. In this case if the system did not check to see if the customer had orders,
there would be an entry or record in the ORDERS table that would still be pointing to
the deleted customer. For this and other reason triggers were invented. Triggers are
bound directly to the table definition. This means that no command activity can bypass
the trigger established for a particular table or column on a table. Trigger help to maintain
referential integrity but can also be used for edits, rules, and auditing.
To list the privileges or roles for a user use the following data dictionary tables:
ALL_COL_PRIVS Grants on columns for which the user or PUBLIC is the grantee
ALL_TAB_PRIVS Grants on objects for which the user or PUBLIC is the grantee
USER_ROLE_PRIVS
Roles granted to the user
ROLE_TAB_PRIVS Information about table privileges granted to roles
ROLE_ROLE_PRIVS
Information about roles granted to other roles
USER_COL_PRIVS Grants on columns for which the user is the owner, grantor, or
grantee
COLUMN_PRIVILEGES Grants on columns for which the user is the grantor,
grantee, or owner, or
PUBLIC is the grantee