Attended a workshop about “Oracle database security” (by Frits Hoogland), though the subject  could also be named  like “O.S.-security of an Oracle Database”.  Most of the times the database will be installed by an ‘oracle’ account, and all the DBA’s are using this account for administrative purpose.

Nothing wrong with that, but logging/auditing of this oracle account is modifyable (=useless) and who did what on this machine?
So it’s quite understandable that an organization will choose for personalized, controlled accounts for DBA’s. Quite scary for a DBA by the way, his kingdom and freedom is vanishing…

What follows is a template to setup such personalized account.
Root – create users and groups
# groupadd -g 54321 oracle
# groupadd -g 54322 oinstall
# groupadd -g 54323 dba
# groupadd -g 54324 oper
# groupadd -g 54325 asm
# useradd -d /home/oracle -m -g oracle -G dba,asm,users,oinstall -s /bin/bash \
-u 54321 -c “Oracle software owner” oracle

For X-windows:
grep the X-cookie, from server console:
# env |grep XAUT
—> XAUTHORITY=/tmp/.gdmXXXXXX
Make this cookie accessable for other users:
# chmod 644 $XAUTHORITY

Become ‘oracle’
# su – oracle
Set XAUTHORITY again:
$ export XAUTHORITY=/tmp/.gdmXXXXXX

Install the software for the database:
$ /oracle/sw/db.10.2.01/database/runInstaller
–> group ‘DBA’  is UNIX DBA group.
–> group ‘oinstall’  is inventory group.

After installation, remove the world rights from ORACLE_HOME (10g)
# chmod -R o-rwx $ORACLE_HOME

Configuration SUDO:
Pass on ORACLE_HOME, by adding ORACLE_HOME to the ‘env_keep’ setting:
# visudo
—>
Defaults env_keep=”ORACLE_HOME COLORS DISPLAY…..
<—

Grant access to oracle executables as ‘oracle’:
# visudo
—>
# entries to enable the dba group to do dba activities
%dba ALL=(oracle) NOPASSWD: /oracle/db/*/bin/lsnrctl
%dba ALL=(oracle) NOPASSWD: /oracle/db/*/bin/dbca
%dba ALL=(oracle) NOPASSWD: /oracle/db/*/bin/netca
%dba ALL=(oracle) NOPASSWD: /oracle/db/*/bin/emctl
%dba ALL=(oracle) NOPASSWD: /oracle/db/*/bin/orapwd
%dba ALL=(oracle) NOPASSWD: /oracle/db/*/bin/netmgr
<—

Creating a personal account:
# useradd -g users -G oracle,dba testuser
Setting password:
# passwd testuser

Then logout as root, login as testuser.
‘oracle’ needs to have access to ‘testuser’s MT-MAGIC-COOKIE:
That’s different for console and ssh:
Console:
$ chmod 644 $XAUTHORITY
Ssh:
$ cat ~/.Xauthroity > /tmp/xauth.$$
$ export XAUTHORITY=/tmp/xauth.$$

Then create a database (e.g. ‘testdb’) as ‘testuser’:
$ sudo -u oracle /oracle/db/10.2.0.1/bin/dbca
After the installation the testuser is able to start and stop the database the ‘normal’ way:
$ export ORACLE_HOME=/oracle/db/10.2.0.1
$ export ORACLE_SID=testdb
$ /oracle/db/10.2.0.2/bin/sqlpuls / as sysdba
SQL> startup

But.. the listener has no SUID and/or GUID bits, so you have to use sudo:
$ sudo -u oracle /oracle/db/10.2.0.1/bin/lsnrctl start

Listener is updatable through ‘netca’.
Logfile is readonly for testuser, needs rotation and cleaning.

Auditing files needs cleaning too.
You may audit all sql of SYSDBA/SYSOPER through:
SQL> alter system set audit_sys_operations=true scope=spfile;

Beware: spfile and init.ora are READONLY.