3

My script needs to call multiple times a program that needs a password, which can only be passed as an environment variable. As I want to ask the user for the password only once, I've done this :

read -s PASSPHRASE
export PASSPHRASE
program some_option
program some_other_option
program yet_another_option
PASSPHRASE=""

As I understand it, the content of the PASSPHRASE variable is only accessible to the current shell and the program during the three calls, then the variable is reset and the passphrase isn't accessible to anyone else.

Am I right, or am I doing it wrong ?

I'm concerned about the other users on the system (excluding root) and the other programs running on my user account.

1 Answer 1

6

Define "safe"

  1. Root can always read everything, so nothing is safe from root
  2. Env vars for User U are safe from other users
  3. Env vars for User U and Program P are not safe from Program Q run by User U

So, root can read that env var for a short period, and other programs run by the same user can read that env var for a short period

Solutions:

  1. Own root, or trust root
  2. Don't run other programs with the same user
  3. Run these programs as their own user

If you don't want to export the env var, you can call your commands like this:

PASSPHRASE="$PASSPHRASE" command-name -option

Might make things a little safer, but other programs run by same user can still probably see them with a little trickery (ktrace/strace, debugging)

6
  • 1
    Yes, better than my (deleted) answer. Point 2+3 is called "privilege separation".
    – Kusalananda
    Commented Feb 14, 2017 at 20:18
  • 1
    @YdobEmos other users cannot see another user's env vars, so you are safe in that regard. Other programs run by the same user can see exported env vars. I added a note to show how to avoid exporting them, but they can probably still be seen by other programs run as same user Commented Feb 14, 2017 at 20:31
  • 1
    @YdobEmos with various debugging tools, like ktrace or gdb Commented Feb 14, 2017 at 20:39
  • 3
    Or on Linux, since they are running under the same user, by inspecting /proc/<pid>/environ (for the PID of program, not the shell).
    – Kusalananda
    Commented Feb 14, 2017 at 20:50
  • 1
    @YdobEmos 1. don't install malicious programs 2. create a new user for this secure task Commented Feb 14, 2017 at 20:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .