There is a lot of misconceptions about the purpose
of the UNIX/Linux "Oracle" user and the need for the "dba" UNIX group.
At Oracle install time, the dba group and the
oracle user are created. This user is created as part of the the
dba group and the oracle user. This user and group, in turn, will
create all of the administrative directories within the $ORACLE_BASE
directory.
Security problems arise when the OS user id defined
with external authentication, such that anybody with the password for
the OS oracle user ID, may enter the Oracle database without internal
authentication:
Two very important init.ora parameters need to be set for all
databases in the SQL*Net environment:
- remote_os_authent (default is false) – This is
a very important parameter because it can allow external Oracle
users to connect to the database without supplying a password.
This value is set to “false”, meaning that Oracle will require a
password, or “true”, meaning that Oracle will assume that the user
has been pre-authenticated by the operating system.
- os_authent_prefix (default is ops$) – This
specifies a group of Oracle users who will be able to connect
remotely without supplying a password when remote_os_authent=”true”.
Normally, this is set to null “” meaning that all users may connect
without a password, or “ops$”, meaning that any user ID that begins
with ops$ will be able to connect without supplying a password.
The reason for preventing external identification from Oracle SQL*Net
clients should be clear. Anyone with administrative privileges on
a Windows or UNIX/Linux server could easily create a user ID with the
same name as the one that is identified on the remote servers.
They could then breach security by connecting without a password.
- You are allowed to implement external authentication via either
ops$ or IDENTIFIED EXTERNALLY.
- External authentication only works from non-PC clients. If
you want external identification between non-PC servers and access
to the PC GUY tools, you must define the user as ops$ and specify a
password.
UNIX/Linux OS user management
UNIX users are controlled by a special file called
/etc/passwd. This file contains a series of strings separated by
colons “:”. The values are:
username :
password : user_nbr : group_nbr : default shell
root> cat /etc/passwd
oracle:x:108:102::/export/home/oracle:/bin/ksh
oradev:x:109:102::/export/home/oradev:/bin/ksh
From the above listing we can determine that the
oracle user has a encrypted password in /etc/shadow, that they are user
108, and they are in group 102. The oracle user has
/export/home/oracle for a home directory, and they are using the Korn
shell as a default shell.
UNIX passwords on Oracle servers
UNIX passwords are notoriously vulnerable to hacking.
In UNIX, users can change their passwords by invoking the passwd
command. Note that the listing of /etc/passwd above does not
contain the encrypted passwords for the user IDs, and the password
column is denoted with an “x”. This indicates that the system
administrator is storing the passwords in another special file called
/etc/shadow.
Unfortunately, protecting passwords in a /etc/shadow
file is not always enough to ensure security. Several tools such
as John the Ripper can be used to easily crack into these UNIX files,
stealing access to the Oracle server, and all database data. To
learn how to protect yourself from UNIX password hacking, see the UNIX
password cracker at http://www.openwall.com/john/.
The power of root
In UNIX, the “super user” is always called root.
The root user may sign-on as any UNIX user without supplying a password
by using the super user (su) command. For example, the root user
can sign-on as the oracle user by entering su – oracle.
The root user may also change any password in the
system by entering passwd command followed by the userid. For
example, the root user could change in oracle password by entering
passwd oracle.
UNIX connectivity for Oracle
When the Oracle DBA creates their tnsnames.ora file to
define remote databases they often specify the host name of the foreign
server that contains the remote Oracle database. For example, a
entry in the tnsnames.ora file for a remote database might look like
this:
berlin =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(COMMUNITY = TCP)
(PROTOCOL = TCP)
(HOST = hun)
(PORT = 1521)
)
)
(CONNECT_DATA
= (SID = kraut))
)
Here we see a TNS service name of berlin, which
defines a connection to a remote server named hun that contains an
Oracle database named kraut. When a remote connection request is made
from the UNIX server, the /etc/host file is accessed to get the IP
address for the hum server.
From the listing below, we see that the hun server is
located at 192.133.13.12. In sum, the /etc/host file is used to
isolate the IP address from the tnsnames.ora file. If the IP
address should ever change, the UNIX systems administrator only needs to
change the IP address in one place.
root> cat /etc/hosts
192.133.13.22 hun hun.com
192.144.13.22
dopey dopey.com
