storing a password in an environment variable

irey · 07-27-2011, 04:30 PM

Hi,

I'm developing a shell script that will read a username and a password from an environment variable. I prefer this rather than the command line to prevent the password from being visible to other users via the 'ps' command.

Yes, I know this is insecure. The password will be readable via /proc/<pid>/environ, but only to the same user and root. That's way better than the command line. Besides, the password is already stored in cleartext in a plain file (readable only by owner), so anything I do needn't be more secure than that.

Question: Will I be facing other security issues not mentioned here? If you can prevent me from making a stupid decision then please do it

Thanks

SL00b · 07-27-2011, 05:00 PM

Depends on what you're doing with it. For example, if you're using it as a command-line argument to launch a process, it could show up in ps -ef, and anyone can execute that.

chrism01 · 07-27-2011, 11:49 PM

As far as the local user goes, there's also 'env' & 'set' ....
If you had the shell script read the var from the file, then it won't appear in ps ...

David the H. · 07-28-2011, 01:45 AM

That's not just insecure, it's foolish. Once something is set in the environment, it's available to everyone and everything in that environment. There's no way to properly hide it.

Some programs use a "credentials" file for storing password info. This is nothing more than a small text file with permissions limited so that read access is available only to the user launching the command. Here's an example:

http://anothersysadmin.wordpress.com...edential-file/

Your script can, and I say should, use a similar system. Just set the lines in the file up as "variable=value", give it restricted access, and have the script source it directly. The variable definitions in it will then be available to that script's environment, but not that of the the launching shell.

irey · 07-28-2011, 08:11 AM

Thanks everyone for the replies.

As I said, I am reading the password from a secure file (well, secure up to a certain point, since it is root-readable anyway). It's just that I want to avoid parsing the file multiple times so that code is more maintainable.

Quote:

Once something is set in the environment, it's available to everyone and everything in that environment.

Right. I know the environment is inherited by subprocesses, and if I export a variable in the shell then every successive command will have access to it. But if I set the environment inside a script so that another script (as a subprocess) can read it, then the environment should be destroyed when the master script terminates. It shouldn't be available to the parent process. Isn't that right?

No worries about ps -ef since I'm never passing it as a command line argument for any command launched by the scripts.

Thanks again.

David the H. · 07-29-2011, 08:45 AM

Quote:

Originally Posted by irey

But if I set the environment inside a script so that another script (as a subprocess) can read it, then the environment should be destroyed when the master script terminates. It shouldn't be available to the parent process. Isn't that right?

That's correct. No process can ever alter the environment of its parent. Changes only affect the current level, and sometimes subprocesses, which can inherit them if exported.

So you're already most of the way there. As I suggested before, simply arrange for your top-level script to source the file and you're set. Its contents will be imported into the script and evaluated as shell commands.

So simply make your password file like this:

Code:

name=username
pass=password

Then near the top of your main script add something like this:

Code:

#!/bin/bash

passfile=/path/to/passwordfile.txt

if [[ -r $passfile ]] ; then
     . "$passfile"
else
     echo "Password file not found or not readable."
     exit 1
fi

#for testing only:
echo "$name"
echo "$pass"

If the variables need to be read by subprocesses of the master script, you may need to add a line to export them as well.

irey · 07-29-2011, 08:59 AM

Ok, that works

. I'll also add a check so that the master script can only be executed as a standalone process (i.e. no "source script.sh"). That will ensure the environment is properly destroyed at the end.

Thank you!

devnull10 · 07-29-2011, 12:35 PM

Oracle uses this method for executing scripts via concurrent requests in E-Business Suite. Three is a slight flaw though in that if you cause the request to fail then view the log, it dumps the environment vars into there - including the apps password! ooops...