Database Reference
In-Depth Information
2EEB4B0E86F503127850EA09ABB9F5EA6A2D8C6D ~ CDC_DROP_CTABLE_BEFORE
01C69F6F073D542B53A96D9A40971D3FDCF5C64F ~ OLAPISHUTDOWNTRIGGER
C59C0EE44E255744DDF757CC4A8576AD6E8AF556 ~ OLAPISTARTUPTRIGGER
C59C0EE44E255744DDF757CC4A8576AD6E8AF556 ~ OLAPISTARTUPTRIGGER
But what about if a user with SYS privilege tampered with
DBMS_CRYPTO
and
DBMS_METADATA
? In that case we can
do a state check on the SYS schema, as follows:
SQL> SELECT AVG(dbms_utility.get_hash_value(text,1000000000,power(2,30))) FROM DBA_SOURCE WHERE
OWNER='SYS';
AVG(DBMS_UTILITY.GET_HASH_VALUE(TEXT,1000000000,POWER(2,30)))
————————————————————-
1564889684
So
DBMS_UTILITY
verifies the state of SYS to be the same checksum as before. That's good news, but how sure is
this verification? Let's take a look.
Handling Compromised Checksummer
What if
DBMS_UTILITY
PL/SQL has been compromised? Our checksummer could be giving a good checksum when
actually the object was tampered with. In that scenario we need to checksum
DBMS_UTILITY
from the data file at the
OS level. But what if
"oracle"
Unix has been compromised? We shouldn't do automated state checks from
"oracle"
if an attacker could have
"oracle"
access (remembering that any process exiting the DB programmatically
is
'oracle'
). In that case
"root"
Unix has to go into the data files and check the Oracle DB objects directly.
Segregation of Duty (SoD)
From the previous scenario we can see that the power privilege hierarchy is such that:
root
watches/controls “oracle”
“
oracle"
watches/controls SYS
SYS
watches/controls application accounts like schema owners
Applications
watches/controls end
users
So the ability to verify state in the Oracle DB relies on the segregation of duty (SoD) between these groups.
If
"oracle"
users get
"root"
then the monitoring and control is lost. Table
13-1
lists the main privileged account
categories for Oracle DB in ascending order of privilege, which follows the OSI 7 layer model (note low priv
individualised report-read accounts not included).
