1.4 Secure Other Executables
Background
Take a look at the other executables in the $ORACLE_HOME/bin directory; some may look familiar, such as sqlplus or lsnrctl (the utility to start the listener); others may not.
Some of these files—such as tnslsnr, the utility that the listener process runs, or dbsnmp, which was used in Oracle Intelligent Agent—are not directly touched by the end user. To properly secure them, you must understand what they do and take appropriate action.
Recall that if the SUID bit is set for a file, then regardless of who runs the file it runs under the privileges of the owner, not the executor. You also learned that setting the SUID can be dangerous and should be discouraged.
There are several other files that have the SUID set to on. Let's find them.
$ cd $ORACLE_HOME
$ find . -type f \( -perm -2000 -o -perm -4000 \) -exec ls -l {} \;
In Oracle Database 10g Release 1 and later, the above should return only the following executables (Oracle Database 11g should return only a subset of this):
-rwsr-s--x 1 orasoft dba 93300507 Jul 22 11:20 ./bin/oracleO
-r-sr-s--- 1 root dba 0 Jul 1 23:15 ./bin/oradism
-rwsr-s--x 1 orasoft dba 94492 Jul 22 11:22 ./bin/emtgtctl2
-rwsr-s--- 1 root dba 18944 Jul 22 11:22 ./bin/nmb
-rwsr-s--- 1 root dba 20110 Jul 22 11:22 ./bin/nmo
-r-sr-sr-x 1 nobody nobody 58302 Jul 22 11:23 ./bin/extjob
Let's see what these files are:
Program | Description |
./bin/oracle | This file is a copy of the executable oracle. When you recompile the oracle executable using the relink command, the old copy is saved as oracleO. This is a potential security hazard; most DBAs ignore it, and it can be an avenue for hackers. Therefore you should take action to remove the permissions. The best option is to have no permissions for it to anyone other than orasoft:
$ chmod 600 oracleO
Now, if you check the permissions:
$ ls -l oracleO
-rw------- 1 orasoft oinstall 248823320 Sep 15 13:27 oracleO |
./bin/oradism | Used for Dynamic Intimate Shared Memory. May be in use on your platform. May not be present in all cases. If present, leave as is. |
./bin/emtgtctl2 | Used for Oracle Enterprise Manager agent. There is no need for it to be set with SUID. The justification is the same as the oracle executable. Remove the permissions:
$ chmod 0700 emtgtctl2 |
./bin/nmb | Used for Oracle 10g Grid Control agent to collect statistics on the target server. Leave as is. |
./bin/nmo | Used for Oracle 10g Grid Control agent to collect statistics on the target server. Leave as is. |
./bin/extjob | This is the executable for the EXTJOB (External Jobs, which allow you to execute OS-based programs from within Oracle Enterprise Manager). This is something you should be careful about. Do you use external jobs a lot? If not, then you should not even have this executable. In such a case, you can leave it in the directory but change the permissions and the ownership. The owner can be the Oracle software owner (orasoft, in our case), and the permissions should be rwx------:
$ chown orasoft:oinstall extjob
$ chmod 0700 extjob
There may be another program present, extjobO, which was a previous compilation of the same program. Change the permissions of that too:
$ chown orasoft:oinstall extjobO
$ chmod 0600 extjobO |
In Oracle9i Database Release 2, you will find a different file, ./bin/dbsnmp, which is the Oracle Intelligent Agent executable file. The permissions are set as such:
-rwsr-s--- 1 root dba 2986836 Jan 26 2005 dbsnmp
The problem with this file is that it needs root privileges to work properly, hence the SUID bit must be set to on. However, because this file is owned by root, hackers typically exploit it to gain access as root. The best advice is to eliminate it, or make it owned by the Oracle software owner and set the permissions to 700. You will lose some functionality, but it's worth it to eliminate the risk.
The other executable to consider is tnslsnr, which is the Oracle Net Listener. There are two executables:
• tnslsnr—the actual listener executable
• lsnrctl—the utility that is used to manage the listener, such as starting, stopping, and so on
If you look at the permissions:
$ ls -l *lsnr*
-rwxr-x--x 1 orasoft oinstall 214720 Oct 25 01:23 lsnrctl
-rwxr-xr-x 1 orasoft oinstall 214720 Oct 1 18:50 lsnrctl0
-rwxr-x--x 1 orasoft oinstall 1118816 Oct 25 01:23 tnslsnr
-rwxr-xr-x 1 orasoft oinstall 1118816 Oct 1 18:50 tnslsnr0
the files have execute privileges for all. Like the executable oracleO, when a new file tnslsnr is created by relinking the Oracle software, the existing file tnslsnr is renamed to tnslsnr0. This is done because if the process needs to be rolled back, the old executable can be copied over the new one. Because it's the copy of the old executable, the file tnslsnr0 may contain the same functionality as the original tnslsnr. The same goes for lsnrctl0.
Strategy
Now that you understand the purpose of each executable, let's see how you can secure your database infrastructure. Most of the strategy has been discussed in the above section on background information. So, in essence, your strategic moves are all these actions
- Remove all permissions to others from the files that are not needed—for example, lsnrctl0.
- Restrict permissions for executables to Oracle software only.
Remove the SUID bit if the Oracle software owner starts the processes.
So, you want to change the permissions of the listener-related files as follows:
$ chmod 700 lsnrctl tnslsnr lsnrctl0 tnslsnr0
$ chmod 600 lsnrctl0 tnslsnr0
Verify the result:
$ ls -l *lsnr*
-rwx------ 1 orasoft oinstall 214720 Oct 25 01:23 lsnrctl
-rw------- 1 orasoft oinstall 214720 Oct 1 18:50 lsnrctl0
-rwx------ 1 orasoft oinstall 1118816 Oct 25 01:23 tnslsnr
-rw------- 1 orasoft oinstall 1118816 Oct 1 18:50 tnslsnr0
Implications
There are a few implications in this case:
- Changing the oracleO executable has no impact on the operation of the database. If you ever face an issue that points to a corrupt oracle executable, your best bet is to rename the oracleO file to "oracle." If you do so, make sure you reset to permissions to 700. The same goes for lsnrctl0 and tnslsnr0executables.
- Changing the emtgtctl2 permissions will have no impact if you use the Oracle software owner userid as the Oracle Enterprise Manager OS credentials. If you use a different userid (not orasoft, for example), the SUID must be reset to the old value and the permissions must be set as they were.
The executable dbnsmp is used by Oracle Enterprise Manager Intelligent Agent, but only up until Oracle9i Database Release 2. Again, if you use the Oracle software owner as the OS credentials, there is no impact from changing the permissions. If you use a different userid, you must reset the permissions to the previous value.
Action Plan
- Change permissions of oracleO, tnslsnr0, and lsnrctl0 to 0600.
- Change permissions for tnslsnr and lsnrctl to 0700.
Do you use external jobs in Oracle Enterprise Manager?
IF no THEN change the permissions of extjob to 0000
ELSE |
| Change the permissions of extjob to 0700 and change the owner and group to orasoft and oinstall (or whatever the user and group of the Oracle software owner are). |
END IF |
IF you are on Oracle9i Database THEN |
| Are you using Oracle Intelligent Agent? |
IF no THEN |
| Change ownership of dbsnmp to orasoft
Change permissions to 0700 |
ELSE |
| No change needed |
END IF |
Note: If you apply a patch or upgrade the database, the permissions will be reset, so you need to re-examine them after the upgrade.
1.5 Change DBSNMP Password
Background
As you may know, Oracle Intelligent Agent communicates with Oracle Enterprise Manager to pass on information about components such as the database, the listener, and the server itself. To get data about the database, it needs to connect to the database using some userid. By default, the userid used is DBSNMP.
When the database is created, the password of DBSNMP] is also set to dbsnmp. This user has some powerful privileges, such as UNLIMITED TABLESPACE, SELECT ANY DICTIONARY (which allows the user to select from dynamic performance views and data dictionary views), and ANALYZE ANY DICTIONARY (which allows analyze of the system objects). Many intruders use this userid and password for back-door entry into the database. Needless to say, this is a huge security hole.
Strategy
You have to change the password of this user to something other than dbsnmp. However, you can't just change the password at the database level, because that password is also stored in the agent configuration files. You need to update the configuration files to use the new password as well. Here's the procedure for Oracle Database 10g:
First change the password of the user DBSNMP to something else—for example, TopSecret:
SQL> alter user dbsnmp identified by topsecret;
- Go to the directory where the Oracle Agent Home is installed (not ORACLE_HOME)—for example, /u01/app/oracle/10.1/gridc.
- Go to directory <hostname>/sysman/emd , where <hostname> is the name of the host or server. For instance, if the name of the server is prolin1, then the directory should be prolin1/sysman/emd.
- Here you will find a file named targets.xml. Copy it under a new name (for example, targets.xml.old).
Open the file targets.xml and search for the word "dbsnmp"; the contents should be similar to:
<Target TYPE="oracle_database" NAME="PROPRD1_prolin1">
<Property NAME="MachineName" VALUE="192.168.101"/>
<Property NAME="OracleHome" VALUE="/u01/app/oracle/10.1/db1"/>
<Property NAME="Port" VALUE="1521"/>
<Property NAME="Role" VALUE="NORMAL"/>
<Property NAME="SID" VALUE="PROPRD1"/>
<Property NAME="ServiceName" VALUE="PROPRD"/>
<Property NAME="UserName" VALUE="dbsnmp"/>
<Property NAME="password" VALUE="3797cf30e7c4a9c6" ENCRYPTED="TRUE"/>
<CompositeMembership>
<MemberOf TYPE="rac_database" NAME="PROPRD" ASSOCIATION="cluster_member"/>
</CompositeMembership>
</Target>
Note this line (in bold type, above):
<Property NAME="password" VALUE="3797cf30e7c4a9c6" ENCRYPTED="TRUE"/>
This is where you will set the value of the password. Replace the above with
<Property NAME="password" VALUE="topsecret" ENCRYPTED="FALSE"/>
Note that you changed the value of ENCRYPTED to FALSE.
- If this is a RAC database, this line will occur twice in the file. Make sure you change both occurrences. Search the file for the word "password" to locate these two instances
Now stop the agent by issuing this command
/u01/app/oracle/10.1/gridc/bin/emctl stop agent
Restart the agent:
/u01/app/oracle/10.1/gridc/bin/emctl stop agent
When you restart the agent, the cleartext password in the configuration file is encrypted. If you check the above line in the targets.xml file again, you will see something similar to the following:
<Property NAME="password" VALUE="3797cf30e7c4a9c6" ENCRYPTED="TRUE"/>
Note how the cleartext value has been converted to an encrypted value.
- Now the agent is configured with the new password.
If you use the standalone Database Console instead of Oracle 10g Grid Control, then the procedure is similar—except that in Step 2, you would go to ORACLE_HOME, not where the Agent Home is located.
Implications
There are no user implications here.
Action Plan
1. Change the password of the user DBSNMP.
2. Update the agent files to reflect the new password.
