We have some Linux ETL DataStage servers
There is a dsjob api that is built in the tool to run the ETL jobs.

The dsjob api gets the parameters passed to it as an option and we are passing the decrypted passwords as parameters to it.

The passwords are showing up when we grep for the process using the ps.

The command we run is ps -ef |grep dsjob.

SLES-9 Linux instance output:

dstage@eccas703:/ford/thishost/u/dstage
$ps -ef |grep dsjob
dstage 2847 6705 0 09:42 pts/5 00:00:00 bin/dsjob -run -mode NORMAL -param t_ora_tablename a -param t_ora_cpm_uid b -param t_ora_cpm_pwd abc -param t_ora_cpm_sid d -wait sandbox HeapAllocError

dstage 2896 2784 0 09:42 pts/8 00:00:00 grep dsjob


We would like to know if there is a setting at the os level that prevents this scenario?

Unfortunately, the passing of command-line parameters is, by the fundamental design of the operating system, available to all processes (it lives in the /proc filesystem). Incidentally, one might try to circumvent this by passing important information in environment variables, but this info is also available in /proc. The only way (with linux) to circumvent this is to disable the mounting of /proc at boot. Alternately, you might make it available to a select group. Then, only that special group will get any information from ps.

yeah, like stated above, passing in as a environment variable won't work. the shell will resolve environment variables prior to executing your application...so the password will still show up on the ps listing...

example:
export TEST=100
sleep $TEST &
ps -ef

what do you see?

to use environment variables, the application would need to be written to use them. and eventhough they can be found in the proc filesystem, they are a little more hidden than your ps listing.

another long-shot is to see if your application will accept something from standard input. then you could put your password into a file and redirect it to the application.

can your application use a config file instead of command line arguments? if so, use a config file and lock down the file's permissions good.

another option is to change the permissions on the ps (& related commands) themselves. by default those apps are world executable, but you could make them so only owner and/or group can execute them. however, users could still go through the process ids in /proc and find the command line used...but that requires more work.

finally, you could change the permissions on /proc. its just a directory (or so it seems) & you could modify permissions so only root can enter. however, this will affect other apps that require information from /proc. for example, this will break ps.

Not by default, but the GRSecurity kernel patch allows for process separation, meaning only root and the user will have access to the user's process details, not other unprivileged users. It's not the only thing GRSecurity fortifies, see their website docs for details.