Database Reference
In-Depth Information
SYS Account
We say an account like SYS is unconstrained for four main reasons:
It can modify its own audit trail using
UTL_FILE
to tamper with records or oradebug to turn
off audit trail, as follows:
1.
SQL> oradebug setmypid
Statement processed.
SQL> oradebug poke 0x60031bb0 1 0
BEFORE: [060031BB0, 060031BB4) = 00000001
AFTER: [060031BB0, 060031BB4) = 00000000
http://soonerorlater.hu/download/hacktivity_lt_2011_en.pdf
2.
It can carry out any action in a database, including turning off DB vault, using JAVA_
product/12.1.0/dbhome_2/bin/chopt disable dv');
3.
It is not tied to an individual so it is commonly shared.
It can be used without password from DBA Unix group or
"oracle"
Unix using
"/
as sysdba"
.
4.
In the 12c release, remote oradebug has been restricted so it can no longer run OS commands directly to delete
the tracefile record of oradebug actions, and all oradebug access can be controlled through the use of
_fifteenth_spare_parameter
, which can be set to “
all
,” “
restricted
,” or “
none
,” but the default setting is for
oradebug access to still be active.
There is still very little physical technical control over SYS by default, which partly explains why human controls
such as sitting together in a close group, with strong human leadership, is used to compensate. Team dynamics
in these situations can depend a lot on psychology, and there can be a tendency towards “pack” behavior. DBA
managers in my experience have studied psychology in order to understand how to read their employees and how
to control the team. This is sometimes done using out-of-work social interactions, such as the pub or card games, to
bond the team, so that trust and compliance are gained through consent, rather than control. Once an effective PAC
system is installed securely, the need for social consent should be reduced so DBA resource can be controlled.
Schema-Owning Accounts
Schema-owning accounts, i.e., DB accounts that own procedures, have “unconstrained” aspects too, because they
also own the data. Data ownership imparts special privileges. For instance, the schema owner is able to turn off
audit on their objects even if the schema owner does not have audit permissions. Additionally, the schema owner
can be the only user able to revoke privileges that they granted. This is why schema accounts are commonly locked,
and all access to the schema owner's powers is managed through stored procedures, in turn accessed by a separate
application account. But what about code releases that upgrade that schema owner's procedures? A human has
to have the password for that process, and once that human has accessed the DB they could turn off the audit and
tamper with the objects. This should update the timestamp on the object so a DBA would notice; perhaps not, as this
code demonstrates. See how easy it is to change the created timestamp on an object:
SQL> set serveroutput on
SQL> create or replace procedure time_test as
2 timevar varchar2(20);
