Unix Script Security

I have received a lot of questions about this area recently. Here are a couple of tips and tricks I use to provide security within shell scripts.

Note: The syntax I will use is for Bourne type shells. The same concepts apply to csh, but the syntax changes.

The first scripting security issue for DBAs that we need to address is the problem of passwords in scripts. Many scripts we write as DBAs, especially applications DBAs, need to connect to the Oracle database. Unfortunately, these scripts frequently contain hardcoded passwords. This has two major problems, security and maintenance. Fortunately, the solution can be simple. In a secure location, have the system administrators create a file belonging to root in the dba (or oinstall) group with permissions 660 (owner read/write, group read/write, everyone else no access). For example, /etc/sysconfig/SID is a good choice in Linux. In this file, put your passwords.

/etc/sysconfig/SID:

SYSTEM=manager
APPS=apps

Your scripts can source this file as part of the configuration at the start of the script. Then anywhere in the script that you need to use the password, you use the variable. In other words instead of sqlplus apps/apps, you use sqlplus apps/$APPS. Of course, that would still show the password with a ps command. An even better solution is to use i/o redirection inside the script:

#!/bin/bash
. /u01/app/oracle/db/tech_st/10.2.0/VIS_vis12.env
if [ -f /etc/sysconfig/$ORACLE_SID ]; then
  . /etc/sysconfig/$ORACLE_SID
else
  APPS=apps
fi
sqlplus /nologin <<EOF
connect apps/$APPS
select * from dual;
EOF

After making this change,  no one who sees the script will learn the apps password,  no one who happens to issue a ps command while the script is running will learn the password, and the act of changing the password in /etc/sysconfig/SID will update all of your scripts.

Now that we have solved the major security issue within our own scripts, let’s address scripts that need to be run as root. In a segregated environment, that is one where the DBAs do not have root, sudo can be a useful tool to allow this functionality.

For example to allow the oracle user to run root.sh from $ORACLE_HOME, you could make the following entry in /etc/sudoers (use visudo to edit this file):

oracle ALL = NOPASSWD: /u01/app/oracle/db/tech_st/10.2.0/root.sh

Of course, this is is now a major security violation.  Since this script is in a directory owned by oracle, anyone who can connect to the system as oracle, can run any command they want as root simply by editing root.sh.  Obviously, the DBA team will continue to have to call the system administrators to have root.sh run when needed.  However, there are other commands that it may be more convenient to have the dba team able to run.  Examples of this may include viewing the system log, mounting and unmounting a backup or stage disk, or if cloning is done using some form of snapshot or mirroring on a SAN or NAS device, merging and splitting the mirrors.  One way to allow this is to have the system administration team write scripts to accomplish these functions and place them in a directory owned by root.  You can take the security a step further and make the directory only accessible to root.

For example (as root):

mkdir /usr/local/superuser_scripts
chown 700 /usr/local/superuser_scripts

Only root can access this directory.  If we want to allow the DBA team access to view the last 100 entries in /var/log/messages, we create a script tail100msg in /usr/local/superuser_scripts:

#!/bin/bash
tail -100 /var/log/messages

In /etc/sudoers, the following line is added.

oracle ALL = NOPASSWD: /usr/local/superuser_scripts/tail100msg

If the oracle user, gives the command: sudo /usr/local/superuser_scripts/tail100msg, they will see the last 100 lines of /var/log/messages.  However, they have to know the script exists, because oracle cannot do an ls in /usr/local/superuser_scripts to see what is there.

You have to be extremely careful if you allow parameters to any scripts written for this purpose.  You have to follow all the same protections against attacks through substitution variables that are followed in sql scripts.

Do you have any other techniques you use to improve the security of the scripts you use?

Printer setup for the E-Business Suite in Oracle Enterprise Linux Part 2 Migrating

Now that we have the printers all added, the last thing we want to do is have to rekey them all on every server.  Every time you do a manual migration, you increase the chance for errors.

We can use system-config-printer to migrate our queues at the linux level and FNDLOAD to migrate the queues in the E-Business Suite.  However, there is one manual step you must go through if you added any PPD files.

The first step in our process is to download the printers.

For linux (as root), enter the command:

system-config-printer-tui –Xexport > printers.xml

For the E-Business Suite (as oracle with the environment set for your apps tier), enter the command:

FNDLOAD apps/$APPS 0 Y DOWNLOAD $FND_TOP/patch/115/import/afcppinf.lct source_printer_def.ldt FND_PRINTER

FNDLOAD apps/apps_password 0 Y DOWNLOAD $FND_TOP/patch/115/import/afcppinf.lct source_printer_def.ldt FND_PRINTER

If you read the first part of this post on adding custom printers, you will recall that I said to keep track of the order that you added the PPD files.  You need to repeat the load of the PPD files in the same order on every system to which you are migrating the printers.  If you did not record the order, look in printers.xml for the printer_id tags, the custom ppd entries will be ppd#, e.g. ppd2.  The surrounding tag will be the name of the queue, so you should be able to reconstruct the order to add the PPD files.
On each system to which you wish to migrate these queues,

copy printers.xml and source_printer_def.ldt

For linux (as root):

system-config-printer-tui ==Xexport > backup-printers.xml
system-config-printer-tui –Ximport < printers.xml
service cups restart

Note: You are interrupting print services, make sure that you are doing it an appropriate time.
After you have completed this step, the queues will be the same on both systems.

For the E-Business Suite (as oracle with the environment set for the apps tier):

FNDLOAD apps/apps_password 0 Y DOWNLOAD $FND_TOP/patch/115/import/afcppinf.lct ${TWO_TASK}_printer_def.ldt FND_PRINTER

FNDLOAD apps/apps_password 0 Y UPLOAD $FND_TOP/patch/115/import/afcppinf.lct source_printer_def.ldt FND_PRINTER

This will merge the printers from the source to the new system.  Any printers that already exist on the new system should still be there, but you may have wiped out the linux queue in the previous step.

Printer setup for the E-Business Suite in Oracle Enterprise Linux Part 1 New Printer Types

Unfortunately, the list of printers available to Enterprise Linux distros is missing many printers used in the real world.  You can find drivers for most printers and information about how to install them at openprinting.org.

However, many of the drivers available there are for LSB 3.2 and many Enterprise Linux distros are not LSB 3.2 compliant (LSB certification provides a standard, but it moves faster than Enterprise Linux distros).

Many printers can be used as long as the correct PPD file is installed.  At openprinting.org, you can download the correct custom PPD file, and you will find the instructions for installing new drivers in cups.  Do not follow these instructions.  You need to add the PPD file through system-config-printer.  The only way I have found to do this is in the GUI version.

Run system-config-printer, click on the Action Menu and choose Import PPD.

system-config-printer
system-config-printer

Make sure you pay attention to the order that you add PPD files.  These PPD files are added sequentially rather than with the model named.  This means that if you want to migrate the queues to another server, you need to add the PPDs in the same order or you will have to edit the printers after adding them.

After the PPD file has been added, the printer model will show up under the appropriate manufacturer containing a driver of type PPD.

Accessing My Oracle Support from Oracle Enterprise Linux 4 x86-64 Part 2

Oracle has now updated note 848202.1, Installing and Troubleshooting Adobe Flash Player on Linux

This is a little bit cleaner than the workaround I posted yesterday since you do not need to replace the /usr/bin/firefox with a shell script.

However, it uses the nspluginwrapper which Oracle does not support.  The previous workaround was done using products covered by a linux support contract from Oracle (the bash script is a convenience to set the LD_LIBRARY_PATH).

Starting with Oracle Enterprise Linux 4 x86_64 with firefox installed.

  1. download Adobe Flash Player 9 (32-bit) from http://kb2.adobe.com/cps/406/kb406791.html
  2. download the nspluginwrapper plugin and viewer from http://gwenole.beauchesne.info//en/projects/nspluginwrapper
  3. tar zxvf install_flash_player_9.tar.gz
  4. cd install_flash_player_9_linux/
  5. cp libflashplayer.so /usr/lib/mozilla/plugins  –The install script will not work, you have to copy manually
  6. rpm -i nspluginwrapper-i386-1.2.2-1.x86_64.rpm
  7. rpm -i nspluginwrapper-1.2.2-1.x86_64.rpm
  8. nspluginwrapper -l
  9. Check the output from the last command, it should include libflashplayer.so
You should now be able to access My Oracle Support