Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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
Click here to see the post LQ members have rated as the most helpful post in this thread.
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.
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:
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.
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.
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.
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.
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...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.