CHAPTER 2

SYSTEM PRIVILEGES
CHAPTER CONTRIBUTOR: Dr. K. Ruth Ramya

2.1 SYSTEM PRIVILEGES

A system privilege is the right to perform a particular action, or to perform an action on any
schema objects of a particular type. For example, the privileges to create tablespaces and to delete
the rows of any table in a database are system privileges. There are over 60 distinct system
privileges. The bulk of privileges that we want our Security Administrator to have will be granted by
SYS:
GRANT
CREATE USER
ALTER USER
CREATE ROLE
GRANT ANY OBJECT PRIVILEGE
GRANT ANY PRIVILEGE
GRANT ANY ROLE
CREATE ANY PROCEDURE
CREATE ANY TRIGGER
CREATE ANY CONTEXT
CREATE PROFILE
AUDIT SYSTEM
AUDIT ANY
TO secadm_role.
Oracle database defines the following system privileges for object types:

CREATE TYPE enables you to create object types in your own schema

CREATE ANY TYPE enables you to create object types in any schema

ALTER ANY TYPE enables you to alter object types in any schema

DROP ANY TYPE enables you to drop named types in any schema

EXECUTE ANY TYPE enables you to use and reference named types in any schema

UNDER ANY TYPE enables you to create subtypes under any non-final object types

UNDER ANY VIEW enables you to create subviews under any object view

The following roles are helpful:

The RESOURCE role includes the CREATE TYPE system privilege.

 The DBA role includes all of these privileges.

2.1.1 Schema Object Privileges:

•Two schema object privileges apply to object types:
EXECUTE enables you to use the type to:
 Define a table.

 Define a column in a relational table.

 Declare a variable or parameter of the named type.

EXECUTE lets you invoke the methods of a type, including the constructor.
Method execution and the associated permissions are the same as for stored PL/SQL
procedures.

 UNDER enables you to create a subtype or subview under the type or view on which
the privilege is granted.
 Only a grantor with the UNDER privilege WITH GRANT OPTION on the direct supertype
or superview can grant the UNDER privilege on a subtype or subview.

The phrase WITH HIERARCHY OPTION grants a specified object privilege on all subtypes of the
object. This option is meaningful only with the SELECT object privilege granted on an object
view in an object view hierarchy. In this case, the privilege applies to all subviews of the
view on which the privilege is granted.

2.2PRIVILEGES GRANTED TO THE SECURITY ADMINISTRATOR

ROLE

The SECURITY ADMINISTRATOR role in Oracle is a powerful role that grants the user a wide
range of privileges, including the ability to:

 Create, alter, and drop database objects

 Grant and revoke privileges to other users
 Audit database activity
 Perform backup and recovery operations
  Manage Oracle Data Guard

In addition to these general privileges, the SECURITY ADMINISTRATOR role also grants the user
several specific privileges, such as:

 CREATE ANY DIRECTORY

 CREATE ANY PROCEDURE
 CREATE ANY SEQUENCE
 CREATE ANY SYNONYM
 CREATE ANY TABLE
 CREATE ANY TRIGGER
 CREATE ANY VIEW
 DELETE ANY TABLE
 DROP ANY DIRECTORY
 DROP ANY PROCEDURE
 DROP ANY SEQUENCE
 DROP ANY SYNONYM
 DROP ANY TABLE
 DROP ANY TRIGGER
 DROP ANY VIEW
 EXECUTE ANY PROCEDURE
 GRANT ANY OBJECT PRIVILEGE
 GRANT ANY ROLE
 GRANT ANY SYSTEM PRIVILEGE
 IMPORT ANY TABLE
 INSERT ANY TABLE
 LOCK ANY TABLE
 MANAGE ANY SYNONYM
 MODIFY ANY TABLE
 REFERENCES ANY TABLE
 SELECT ANY TABLE
 SHOW ANY PROCEDURE
 SHOW ANY SEQUENCE
 SHOW ANY SYNONYM
 SHOW ANY TABLE
 SHOW ANY TRIGGER
 SHOW ANY VIEW
  UPDATE ANY TABLE

It is important to note that the SECURITY ADMINISTRATOR role is a very powerful role, and
should only be granted to users who need it to perform their job duties.

1. Most of these system privileges that we grant to secadm_role allow us to do some of what we
have already done as SYS.
2. We will allow our security administrator to create and edit users, create roles and assign them
to users.
3.secadm will grant privileges to roles to work with Oracle objects (structures) in other diagrams.
It will grant certain system privileges to the roles.
4. It will also create procedures and triggers, which are like procedures, but which run when
certain events occur. And the security administrator will create profiles,
5. For now, we are relying on the default profile.
6. We will also set up audits as security administrators.
7.We will be auditing a variety of system events, and we will be auditing access to tables and
other structures in the HR schema - hence the AUDIT ANY privilege.
8. Anytime you see EVERYTHING in an object privilege grant, you can read it as “in any
schema”.
9. Usually, a user already has these privileges in their own schema.
10. These are not all the system and schema object privileges that our security administrator will
need to do his job, but they will get us started.
11. We will come back as SYS and give the security administrator a bit more privileges later.

2.2.1 The Audit Role:

The audit role in Oracle is a set of privileges that allow users to perform auditing tasks. This
includes creating and managing audit policies, viewing audit data, and managing the audit trail
administration.

There are two audit roles in Oracle:

 AUDIT_ADMIN: This role enables users to create unified and fine-grained audit policies,
use the AUDIT and NOAUDIT SQL statements, view audit data, and manage the audit trail
administration. Grant this role only to trusted users.
 AUDIT_VIEWER: This role enables users to view and analyze audit data. It provides the
EXECUTE privilege on the DBMS_AUDIT_UTIL PL/SQL package. The kind of user who
needs this role is typically an external auditor.
 Auditing is an important security measure that can help you to monitor database activity, detect
unauthorized access, and troubleshoot problems. By auditing database operations, you can gain
valuable insights into how your database is being used and identify any potential security threats.

•Finally, as SYS, we are going to set up some initial auditing on the auditing trail itself.
•This will deter a rogue database administrator from doing something wrong and then erasing
their tracks by deleting their audit records:
AUDIT SELECT, UPDATE, DELETE ON sys.aud$ BY ACCESS;
•When we designate BY ACCESS for auditing, we are saying that we want detailed information.
•The other (possibly default) option is BY SESSION. This gives less detail, but still audits each
occurrence, rather than only providing a single audit record per session, as in earlier releases of
Oracle.

2.2.2 The Data Dictionary:

• We want our security administrator to be able to view all data in the Data Dictionary, which is
a collection of views in the SYS schema that list structures and system data in Oracle. (A view is
a defined way to look at a table of data).
• For example, we may want to list details about all the database users:
SELECT * FROM sys.dba_users;
• There are many columns in the DBA_USERS view that are not available in the PUBLIC data
dictionary views:
• ALL_USERS (fewer details) and USER_USERS (a bit more detail, but only for the current
user).
• Much of the data dictionary has been granted to PUBLIC by default, and can be selected by
every user.
• However, selecting some parts of the Data Dictionary requires the
SELECT_CATALOG_ROLE. Grant that role to the secadm_role:
GRANT select_catalog_role TO secadm_role;
• Note that this is a role granted to a role.
• From now on, when we set the role to secadm_role, we will also have the
SELECT_CATALOG_ROLE.

2.3 WORKING AS THE SYSTEM ADMINISTRATOR

• Now that our security administrator has been defined with the privileges he needs to do his job, we
are going to put him to work. Go ahead and connect:
 CONNECT secadm;
• As you will recall from our creation of the security administrator role, secadm_role, we required
that it be validated by a procedure.
• We have only permitted one account, secadm to execute the procedure. Execute it now to acquire
secadm_role:
EXEC sys.p_check_secadm_access;
• Note that when secadm connects to Oracle, he does not automatically acquire secadm_role.
Because
• It is a secure application (verified) role, and not directly granted to secadm, it cannot be a default
role.
• Every time the secadm user connects, he will have to execute the procedure to gain his Security
Administrator role and privileges. This is in contrast to roles that are granted directly to a user, which
are default roles initially. That status of default role can be unset.

2.4 ACQUIRE SECADM_ROLE FROM A SQL*PLUS LOCAL

CONNECTION

To acquire the SECADM_ROLE from a SQL*Plus local connection, you can use the following
steps:

Connect to the database as a user with the SYSDBA privilege. For example:
SQL> CONNECT SYS AS SYSDBA;

Acquire the SECADM_ROLE. For example:

SQL> ALTER SESSION SET ROLE = SECADM;

Verify that you have acquired the role. For example:

SQL> SHOW ROLE;

ROLE
SECADM

Once you have acquired the SECADM_ROLE, you can perform any administrative tasks that are
allowed by the role. For example, you can create and manage users, roles, and database objects.
Note: The SECADM_ROLE is a very powerful role, so it is important to only acquire it when you
need to perform administrative tasks. Once you have finished performing the administrative tasks,
you should revoke the role.

Here is an example of how to acquire the SECADM_ROLE from a SQL*Plus local connection:

SQL> CONNECT SYS AS SYSDBA;

Enter password:
Connected.

SQL> ALTER SESSION SET ROLE = SECADM;

Session role changed.

SQL> SHOW ROLE;

ROLE
SECADM

Once you have acquired the SECADM_ROLE, you can perform any administrative tasks that are
allowed by the role. For example, you can create a new user:

SQL> CREATE USER new_user IDENTIFIED BY new_password;

User created.

SQL> GRANT DBA TO new_user;

Grant succeeded.

Once you have finished performing the administrative tasks, you should revoke the
SECADM_ROLE:
SQL> ALTER SESSION SET ROLE = NONE;
Session role changed.

You should also drop the new user if you no longer need it:
SQL> DROP USER new_user;
User dropped.
• There are always gotcha's, and here's one that will probably get you a few times if you use
SQL*Plus as your primary client: you can connect locally to the default instance while you are
sitting at a command prompt on the Oracle database.
• Do that by executing SQL*Plus without any arguments, like this:
Sqlplus
• You can connect then as secadm user by entering the username and the password.
• If you then attempt to execute the procedure, sys.p_check_secadm_access that sets secadm_role, it
will not succeed.
• Why does it not succeed? Our address should be that of localhost, which should be okay.
• Well, when connecting locally, SQL*Plus doesn’t use the network at all—it just talks directly to
the database.
• You can see the lack of IP address information by executing this command:
SELECT SYS_CONTEXT( 'USERENV', 'IP_ADDRESS' ) FROM DUAL;
• This has some implications for security.
• The commands you enter do not cross the network adapter when linked locally like this and have
no chance of leaking out to snooping devices on the network.
• So how, you might ask, are we supposed to connect as secadm and run sys.p_check_secadm_access
from SQL*Plus on the Oracle Database? There is a way, and it only requires that you act like you’re
not connecting locally by adding the arguments for user and instance name (orcl in this example) on
the command line. Actually orcl in this context is a TNS alias with the same name as the instance.
sqlplus secadm@orcl
• At that point, you have an IP address in the session context, and you can successfully set role
through the procedure:
SELECT SYS_CONTEXT( 'USERENV', 'IP_ADDRESS' ) FROM DUAL;
EXEC sys.p_check_secadm_access

2.5 TOGGLE BETWEEN ROLES

• You can see the effects of running SET ROLE by observing your current session roles as you
toggle back and forth between create_session_role and secadm_role.
• As secadm user, do this and observe the list of
roles when you do each SELECT query:
SELECT * FROM sys.session_roles;
SET ROLE create_session_role;
SELECT * FROM sys.session_roles;
EXECUTE sys.p_check_secadm_access;
SELECT * FROM sys.session_roles;
• You will see three roles when you execute the procedure and then select from SESSION_ROLES.
The procedure itself sets your role to secadm_role.
• To that role, we granted SELECT_CATALOG_ROLE. And the; SELECT _CATALOG_ROLE has
been granted HS_ADMIN_SELECT_ROLE.
• All of those will be listed as current roles of the session.
• If you have additional packages or different versions installed on your Oracle Database, you may
see additional roles related to those packages

2.6 CREATE AN APPLICATION SECURITY USER AND ROLES

• The first user is our Application Security user, appsec. She will own all the structures that make our
application security work.
• Please take note of the differentiation I am making between Oracle security, which we’ve delegated
to security administrator, and application security.
• The security administrator has been granted a number of system privileges so that he can create
users and do other tasks in Oracle
• The application security user, on the other hand, will own a number of procedures and structures
that are used for application security processes.
• The application security user will not connect as part of any particular application; rather, she will
grant access to her logic and data to application users.
GRANT create_session_role TO appsec IDENTIFIED BY password;

2.6.1 Application Security Role:

• Our application security user needs to create procedures, functions, Java stored
procedures, tables, and views.
• When creating those items, appsec requires the CREATE PROCEDURE, CREATE
TABLE, and CREATE VIEW system privileges.
• We will grant those privileges to a role named appsec_role, and grant that role to the
appsec user:
CREATE ROLE appsec_role NOT IDENTIFIED;
GRANT CREATE PROCEDURE TO appsec_role;
GRANT CREATE TABLE TO appsec_role;
GRANT CREATE VIEW TO appsec_role;
GRANT appsec_role TO appsec;
2.6.2 Non-Default Role:
• Our application Security user only requires these privileges (for example, CREATE
PROCEDURE) on occasion. Our preference would be for her to set her role to appsec_role
as needed, but currently it is a default role.
• In order to change the behavior for roles created as NOT IDENTIFIED from being default
roles to be non-default, we need to issue the ALTER USER command.
• In the following command, we ask Oracle to make all the roles granted to appsec user to be
DEFAULT except this one we want to exclude

•SET ROLE appsec_role;

SET ROLE ALL;
• The second command listed above will set the current session for appsec to enable ALL the
roles that have been granted to her, both default and non-default

2.7 CREATE AN APPLICATION USER

• As an example user for connecting to Oracle to run an application, we will create an application
user, appusr.
• For our purposes, appusr is not tied to a single person, but is what Oracle refers to as a “one big
application user” model user.
• In this model, numerous people will use an application, and the application will connect all of them
to Oracle as our one big application user.
• They do not need individual person accounts and passwords for this access.
GRANT create_session_role TO appusr IDENTIFIED BY password;
To create an application user, you can use the following steps:
1. Log in to SQL*Plus as a user with the CREATE USER system privilege.
2. Execute the following SQL statement:

CREATE USER <username> IDENTIFIED BY <password> DEFAULT TABLESPACE users

TEMPORARY TABLESPACE temp;

Replace <username> with the name of the application user you want to create, and replace
<password> with the password you want to assign to the user.

3. Grant the application user the necessary privileges.

For example, to grant the application user the privilege to connect to the database, you would execute
the following SQL statement:

GRANT CONNECT TO <username>;

You can also grant the application user other privileges, such as the privilege to create tables, views,
and procedures.

4. Assign the application user to an application role.

Application roles allow you to grant groups of users access to specific resources. To assign the
application user to an application role, you would execute the following SQL statement:
GRANT <role_name> TO <username>;
Replace <role_name> with the name of the application role you want to assign the user to.

5. Commit your changes.

Once you have created the application user and granted them the necessary privileges, you need to
commit your changes. To do this, you would execute the following SQL statement:
COMMIT;
Once you have committed your changes, the application user will be able to log in to the database
and use the resources they have been granted access to.

Here is an example of how to create an application user in Oracle:

CREATE

USER app_user IDENTIFIED BY password DEFAULT TABLESPACE users TEMPORARY

TABLESPACE temp;
GRANT
CONNECT
TO app_user;
GRANT app_role TO app_user;
COMMIT;
This would create an application user named app_user with the password password. The user would
be granted the CONNECT privilege and the app_role role.
2.8 CREATE HR VIEW ROLE

•We are going to begin securing access to the data in the Human Resources (HR) Sample Schema.

•We will create a role named hrview_role. Through that role we will grant access to the data needed
by a variety of applications that we plan to build.

•At the outset, we only want folks who are on our internal network to access this data, and only
during our normal office hours of 7 AM to 7 PM.

•We are going to begin securing access to the data in the Human Resources (HR) Sample Schema.

•We will create a role named hrview_role. Through that role we will grant access to the data needed
by a variety of applications that we plan to build.

•At the outset, we only want folks who are on our internal network to access this data, and only
during our normal office hours of 7 AM to 7 PM.

•To accomplish these constraints, we will create the role and require that it be verified by a
procedure. •Oracle calls this a secure application role because that is its function – it is a role that
gives access to application data, but it is secured by some encoded constraints.

•This is the same thing we did to secure secadm_role.

•CREATE ROLE hrview_role IDENTIFIED USING appsec.p_check_hrview_access;

2.8.1 Verify HR View Role by a Procedure:

• Just as we did previously for the secadm_role, we will create a procedure to protect access
to the hrview_role.

• At the end of the procedure, if the CURRENT_USER meets the requirements encoded in
this procedure, we will SET ROLE to the hrview_role.

• Create the procedure by executing the code in Listing 2-2 as secadm.

• Here, we are creating a procedure in another schema. Notice the schema name, appsec.
pretended on the procedure name.

•To do this requires secadm to have the CREATE ANY PROCEDURE system privilege.

p_check_hrview_access Procedure for Secure App Role

CREATE OR REPLACE PROCEDURE appsec.p_check_hrview_access
AUTHID CURRENT_USER
AS
BEGIN
 IF( ( SYS_CONTEXT( 'USERENV', 'IP_ADDRESS' ) LIKE '192.168.%' OR
SYS_CONTEXT( 'USERENV', 'IP_ADDRESS' ) = '127.0.0.1' )
AND
TO_CHAR( SYSDATE, 'HH24' ) BETWEEN 7 AND 18
)
THEN
EXECUTE IMMEDIATE 'SET ROLE hrview_role';
END IF;
END;

2.8.2 Permit Application User to Acquire HR View Role

• We will have to grant EXECUTE on this procedure to all users who need access to the
data.
• Alternatively, we could grant the EXECUTE privilege to PUBLIC, but we would only
want to do that if every user of the database required access to the HR data.
• Do not grant privileges to PUBLIC without considering the implications.

SELF ASSESSMENT QUESTIONS

1. In _________________ attacks, the attacker manages to get an application to execute an SQL

query created by the attacker.
a) SQL injection
b) SQL
c) Direct
d) Application

2. A Web site that allows users to enter text, such as a comment or a name, and then stores it
and later display it to other users, is potentially vulnerable to a kind of attack called a
___________________ attack.
a) Two-factor authentication
b) Cross-site request forgery
c) Cross-site scripting
d) Cross-site scoring scripting

3. _________ is an attack which forces an end user to execute unwanted actions on a web
application in which he/she is currently authenticated.
a) Two-factor authentication
b) Cross-site request forgery
c) Cross-site scripting
d) Cross-site scoring scripting

4. Many applications use _________________ where two independent factors are used to
identify a user.
a) Two-factor authentication
b) Cross-site request forgery
c) Cross-site scripting
d) Cross-site scoring scripting

5. Even with two-factor authentication, users may still be vulnerable to_____________attacks.

a) Radiant
b) Cross attack
c) scripting
d) Man-in-the-middle

6. A single ______________ further allows the user to be authenticated once, and multiple
applications can then verify the user’s identity through an authentication service without
requiring reauthentication.
a) OpenID
b) Sign-on system
c) Security Assertion Markup Language (SAML)
d) Virtual Private Database (VPD)

7. The ___________________ is a standard for exchanging authentication and authorization

information between different security domains, to provide cross-organization single sign-on.
a) OpenID
b) Sign-on system
c) Security Assertion Markup Language (SAML)
d) Virtual Private Database (VPD)

8. The __________ standard is an alternative for single sign-on across organizations, and has
seen increasing acceptance in recent years.
a) OpenID
b) Single-site system
c) Security Assertion Markup Language (SAML)
 d) Virtual Private Database (VPD)

9. _______________ allows a system administrator to associate a function with a relation; the

function returns a predicate that must be added to any query that uses the relation.
a) OpenID
b) Single-site system
c) Security Assertion Markup Language (SAML)
d) Virtual Private Database (VPD)

10. VPD provides authorization at the level of specific tuples, or rows, of a relation, and is
therefore said to be a _____________ mechanism.
a) Row-level authorization
b) Column-level authentication
c) Row-type authentication
d) Authorization security

11. The process of converting plaintext into cipher-text is known as:

a) Decryption
b) Authentication
c) Hashing
d) Encryption

TERMINAL QUESTIONS
1. What are the system privileges? Explain how these are granted to Administrator role?
2. What are some common system privileges? How can I grant or revoke system privileges?
3. What are some security best practices for system privileges?
4. What permissions does the application security role have to the application directory?
5. How do I remove the application security user from the dev role?
6. What are the required fields for creating an HR view role?
7. What are the best practices for creating HR view roles?
8. How do I restrict access to specific HR data within an HR view role?
9. How do I audit who has accessed which HR views?