Oracle 12c - New SYS-level Administration Privileges

For a while now, Oracle has been moving its security model toward a more differentiated set of privileges than just SYSDBA and SYSOPER.  We saw this in 11g with the SYSASM privilege.  This is in response to the growing number of DBA shops that delineate permissions at a more granular level, even among DBAs.  Rather than saying, “Here’s my DBA team, everyone has SYSDBA,” more and more IT shops are defining DBA job roles at a lower level.  If an application DBA never has the job responsibility to shutdown or backup a database, then maybe they don’t need SYSDBA.  However, the lines aren’t always that clear, so Oracle has been adding new levels of admin privileges.  In 12c, they’ve added several.

The SYSBACKUP privilege allows a user to connect to the target database and run RMAN commands, without requiring SYSDBA.  Here’s what it looks like.

/home/oracle:test1:rman

Recovery Manager: Release 12.1.0.1.0 - Production on Tue Aug 13 14:57:41 2013

Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.

RMAN> connect target "altdotoracle@test1 as sysbackup"

target database Password:

connected to target database: TEST1 (DBID=1787845942)

RMAN> select user from dual;

using target database control file instead of recovery catalog

USER

------------------------------

SYSBACKUP

RMAN> backup tablespace users;

Starting backup at 13-AUG-13

allocated channel: ORA_DISK_1

…

Finished backup at 13-AUG-13

RMAN>

In truth, SYSBACKUP has a lot more rights than just those needed to do something like a hot backup, including startup and shutdown, creating tables and tablespaces and executing a number of supplied packages.  So from that perspective, I’m not exactly sure they hit the mark on this one.  Nevertheless, it does differentiate SYSBACKUP from the god-like SYSDBA admin privilege to some degree.  There are also the new admin privileges SYSDG, for administering Data Guard, and SYSKM to do Transparent Data Encryption (TDE) administration.  Consequently, there are new columns in v$pwfile_users to reflect these new privs.

SQL> desc v$pwfile_users

 Name                        Null?        Type

 --------------------------- --------     ---------------

 USERNAME                    VARCHAR2(30)

 SYSDBA                      VARCHAR2(5)

 SYSOPER                     VARCHAR2(5)

 SYSASM                      VARCHAR2(5)

 SYSBACKUP                   VARCHAR2(5)

 SYSDG                       VARCHAR2(5)

 SYSKM                       VARCHAR2(5)

 CON_ID                      NUMBER

If we examine the view itself, we see this in action.

SQL> select * from v$pwfile_users;

USERNAME          SYSDB SYSOP SYSAS SYSBA SYSDG SYSKM     CON_ID

----------------- ----- ----- ----- ----- ----- ----- ----------

SYS               TRUE  TRUE  FALSE FALSE FALSE FALSE          0

SYSDG             FALSE FALSE FALSE FALSE TRUE  FALSE          0

SYSBACKUP         FALSE FALSE FALSE TRUE  FALSE FALSE          0

SYSKM             FALSE FALSE FALSE FALSE FALSE TRUE           0

ALTDOTORACLE      FALSE FALSE FALSE TRUE  FALSE FALSE          0

Tightening Security with SELECT ANY DICTIONARY in Oracle 12c

Developers and users sometimes request the SELECT ANY DICTIONARY system privilege to enable them to view various data dictionary tables.  This may be fine for querying DBA_TABLES, etc, but the Oracle data dictionary contains a LOT of information.  Some of the views/tables are compromising from a security standpoint.  One of Oracle’s legendary gaffs in version 9i displayed cleartext passwords for database links in SYS.LINK$.  Yikes.  In version 12c, Oracle has locked down this type of access even further.  Here’s an example from version 11g.

SQL> create user altdotoracle identified by altdotoracle;

User created.

SQL> grant create session, select any dictionary to altdotoracle;

Grant succeeded.

SQL> conn altdotoracle/altdotoracle

SQL> select name, password from sys.user$ where password is not null;

NAME                           PASSWORD

------------------------------ ------------------------------

SYS                            AAJ125C9483Q017

SYSTEM                         W45825DFFFD37SE

OUTLN                          WW24Z1N6A8ED2E1

ALTDOTORACLE                   73NH15SG3Q2364W

Armed with these password hashes, password cracking tools can be used to compare these values to common dictionary passwords.  When a match is found on a non-complex password, your password is cracked.  (Don’t wear yourself out trying to crack the hashes above, I obfuscated them)  SELECT ANY DICTIONARY no longer allows access to dictionary objects like USER$, ENC$ and DEFAULT_PWD$. Let’s try it.

Connected to:

Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production

With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL> create user altdotoracle identified by altdotoracle;

User created.

SQL> grant create session, select any dictionary to altdotoracle;

Grant succeeded.

SQL> conn altdotoracle/altdotoracle

Connected.

SQL> select name, password from sys.user$ where password is not null;

select name, password from sys.user$ where password is not null

                               *

ERROR at line 1:

ORA-01031: insufficient privileges

SQL> select * from sys.enc$;

select * from sys.enc$

                  *

ERROR at line 1:

ORA-01031: insufficient privileges

SQL> select * from sys.default_pwd$;

select * from sys.default_pwd$

                  *

ERROR at line 1:

ORA-01031: insufficient privileges