ALTER USER system privilege in Oracle 12cR2

In Oracle 12cR2 a new security enhancement has been introduced, the “alter user” system privilege when granted to an account….this account won’t be able to change “SYS” password anymore.

Let us explore “ALTER USER” system privilege in Oracle 12cR1 first:

1

2

 

3

 

4

while in Oracle 12cR2:

i have granted SYSTEM account the “ALTER USER” system privilege:

SQL> SELECT * FROM DBA_SYS_PRIVS where grantee=’SYSTEM’;

11

As a SYSTEM user I can’t alter the SYS user password as shown below:

12

The oracle error raised is:

ORA-01031: insufficient privileges

Not only you can’t change the password, you can’t change any activity that is related to the “ALTER USER” command such as changing the “profile”, “quota” ….etc

This feature will be very helpful if you have a segregation of duties in your database infrastructure  where account management is maintained by different entity which will definitely be granted “ALTER USER” system privilege for password management and reset….in this case they wont have the power to change the “SYS” user password.

Is there any workaround to go over this security restriction ?

Yes.

Under SYS schema create the following procedure:

SQL> create procedure sys.sys_pass_change(my_pass in varchar2) as

begin

execute immediate ‘alter user sys identified by ‘||my_pass;

end;

/

SQL> grant execute on sys.sys_pass_change to system;

Then, accessing the database as “SYSTEM” user:

SQL> exec sys.sys_pass_change(‘yarn_9ns’);

33

in this example The SYSTEM account will execute the procedure with “definer’s” right.

 

 

 

 

 

 

 

 

 

 

Secure Oracle database binaries by updating JDK

One of the things that gets unnoticed or (overlooked) when securing Oracle Database Infrastructure is securing oracle database binaries by updating JDK build or updating SQL Developer.

When installing Oracle database binaries the version in a database install is always going to be behind the latest JDK so you should update to the latest version since latest version will include security fixes.

to check your current JDK build:

cd $ORACLE_HOME/jdk/bin

java –version

Procedure to replace JDK:

shutdown your oracle database and listener.

cd $ORACLE_HOME

mv jdk jdk.orig

//  you can download the Latest Java SE Patches/Update Releases on MOS (Doc ID 1414485.1) OR All Java SE Downloads on MOS (Doc ID 1439822.1)

//  copy the downloaded JDK to $ORACLE_HOME

scp jdk-6u181-linux-x64.bin $ORACLE_HOME

cd $ORACLE_HOME

./jdk-6u181-linux-x64.bin

cd $ORACLE_HOME

mv jdk1.6.0_181 jdk

rm -rf jdk-6u181-linux-x64.bin

To verify: 

cd $ORACLE_HOME/jdk/bin

java –version

Startup the database and listener.

Run utlrp.sql script and check that all database components are valid:

SQL> @?/rdbms/admin/utlrp.sql

SQL> select * from dba_registry;

Also, check database alert log file …just in case.

If the database has “JAVA” component you can follow the steps described in this procedure for “verification”

How To Determine The JDK Version Used by the Oracle JVM in the Database (Doc ID 131872.1)

ACCESSIBLE BY in Oracle 12c PL/SQL

New security enhancement has been introduced in Oracle 12c that will implement “white listing” on the PL/SQL code that will provide an isolation level.

The new keyword ACCESSIBLE BY can be used with the following database objects only:  function, package, procedure, and type.

To illustrate… I have created the following 2 packages under DUMMY_TEST schema:

CREATE OR REPLACE PACKAGE dummy1_pkg

IS

PROCEDURE do_action1;

END;

/

CREATE OR REPLACE PACKAGE BODY dummy1_pkg

IS

PROCEDURE do_action1

IS

BEGIN

dummy2_pkg.do_action2;

dummy2_pkg.do_action3;

END;

END;

/

 

CREATE OR REPLACE PACKAGE dummy_test.dummy2_pkg  

ACCESSIBLE BY (dummy1_pkg)

IS

PROCEDURE do_action2;

 

PROCEDURE do_action3;

END;

/

 

CREATE OR REPLACE PACKAGE BODY

dummy2_pkg

IS

PROCEDURE do_action2

IS

BEGIN

DBMS_OUTPUT.put_line (‘Hi Action 2’);

END;

 

PROCEDURE do_action3

IS

BEGIN

DBMS_OUTPUT.put_line (‘Hi Action 3’);

END;

END;

/

 

sqlplus

sql-account

I was able to execute dummy1 package with no problems as shown below, by executing:

BEGIN

dummy1_pkg.do_action1;

END;

/

execute-package-1

 

When I try to directly execute the other package dummy2_pckg by executing the query:

BEGIN

dummy2_pkg.do_action2;

END;

/

The following error is thrown: PLS-00904: insufficient privilege to access object DUMMY2_PKG

execute package 2 error.jpg

Remark: you can specify a package or a procedure in the accessible by clause while even if this package/procedure is not yet created, so you will not face any errors at compilation time.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

USE GRANT READ instead of GRANT SELECT in Oracle 12c

Normally when we want to grant an oracle database account access to read records form certain tables, we use the SQL command (GRANT SELECT), however this is found to be not the best security practice. And, new security feature has been introduced in Oracle 12c which is GRANT READ.

To illustrate more,

I have created a dummy account named “dummy_test” with the following basic privileges:

dummy account

And created a dummy table with random values called “DUMMY_RECORDS”, and executed the below SQL statement to grant the user access to read records from the table:

SQL> grant select on DUMMY_RECORDS to dummy_test ;

Now….the interesting part is the following…..i will be able to exclusively LOCK the table !!!

either by executing the following:

SQL> lock table DUMMY_RECORDS in exclusive mode;

OR

SQL> select * from DUMMY_RECORDS for update;

exclusive lock.jpg

Now, let us revoke (GRANT SELECT) and use (GRANT READ) on the table

grant read 1

grant read 2

as shown above, after logging with the account we were not able to exclusively  lock the table and ORA-01031 was thrown.

Important Remarks:

  • this security feature is only available in 12c release.

 

  • some applications could frequently use (select* from table for update) frequently so you need to test the consequences of using the GRANT READ permission.

 

  • the purpose of this security feature is that it will prevent the hacker who stole the credentials of the account to lock the table which will block transactions and impact the running the application ! (denial of service)

 

 

 

 

TDE in Oracle 11g

What is TDE ?

TDE stands for “transparent data encryption”. TDE is part of Oracle Advanced Security Option for Enterprise Edition. Data at rest are encrypted and ONLY authorized users who have access control privilege will read de-crypted data. So, TDE protects your from direct access to the database host server or backup media that has copies of your data files.

TDE Master Key encryption can be managed through Oracle Wallet Manager.

Example of column data encryption:

The following table will be created with column “salary_information”

SQL> create table EMPLOYEE.EMPLOYEE_INFORMATION(first_name varchar2(20),last_name varchar2(30), EMPLOYEE_ID char(18), salary_information number(10,2) ENCRYPT using ‘AES256’ NO SALT);

 

For Tablespace Encryption:

  • You cannot encrypt an existing tablespace.
  • You can use” Data Pump” method OR “alter table move” to move data to newly encrypted tablespace.

 

Example of creating encrypted tablespace :

CREATE TABLESPACE tablespace_new

DATAFILE  ‘/app/oracle/oradata/tablespace2.ORA’  SIZE 200M

ENCRYPTION USING ‘AES25’ DEFAULT STORAGE (ENCRYPT);