Secure Other executables

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 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 Database10g Release 1 and later, the above should return only the following executables:

-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/oracleO 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 oracle0. 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:

$ chmod 0000 oracleO

Now, if you see the permissions:

$ ls -l oracleO -- 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 Enterprise Manager Agent. There is no need for it to be set with SUID. The justification is 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 it as is. ./bin/nmo Used for Oracle 10g Grid Control agent to collect statistics on the target server. Leave it as is. ./bin/extjob This is the executable for the EXTJOB (External Jobs, which allow you to execute OS-based programs from within 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 0000 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, as 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 setting 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, etc.

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 exdcutable, 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:

Remove all permissions from the files that are not needed—e.g., lsnrctl0. Restrict permissions for executables to Oracle software only. Remove the SUID bit on 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 $ chmod 000 lsnrctl0

Verify the result.

$ ls -l *lsnr* -rwx--  1 orasoft    oinstall    214720 Oct 25 01:23 lsnrctl --  1 orasoft    oinstall    214720 Oct  1 18:50 lsnrctl0 -rwx--  1 orasoft    oinstall   1118816 Oct 25 01:23 tnslsnr --  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 tnslsnrctl0 files. Changing the emtgtctl2 permissions will have no impact if you use the Oracle software owner userid as the Enterprise Manager operating system 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 operating system 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 0000. Change permissions for tnslsnr and lsnrctl to 0700. Do you use external jobs in 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