Re: "here strings" and tmpfiles

[Greg Wooledge]

On Mon, Mar 18, 2019 at 05:18:10PM -0400, Daniel Kahn Gillmor wrote:
>     strace -o tmp/bash.herestring.strace -f bash -c 'cat <<<"hello there"'
> It turns out that this creates a temporary file, actually touching the
> underlying filesystem:

Yes, just like here documents do.  And have always done, in all shells.

> For example, sending a password or secret key material from the
> environment to stdin would be a typical way to use a herestring.

Note that the environment may also be visible to users on the system,
via "ps eww aux" or similar commands.  The availability of the BSD ps(1)
options and the details about who can see what are OS-specific.

> A few possible options for trying to improve the situation:

Don't put sensitive data in shell scripts?

In general:

1) Do not pass secrets as arguments to external commands.  The arguments
   of a command are generally visible in ps(1).

2) Do not pass secrets as environment variables.  The initial environment
   of a process is generally visible in ps(1).

3) Read the documentation of the thing you're trying to authenticate
   against.  Find out the various ways it can accept authentication
   secrets/tokens and choose the most appropriate.  This may mean using
   ssh keys stored in an ssh-agent, etc.

4) If something requires a password, let it prompt the user for the
   password by itself.  Just run it inside a terminal so that it can
   launch a dialog with the end user if required.  Do not try to "help"
   it by storing the password in your script and then trying to figure
   out how to circumvent its security in order to pass the password to it.

5) If you absolutely MUST store a password somewhere on disk, don't
   store it inside the shell script.  Shell scripts must have read
   permissions in order to be used.  Store the password in a separate
   file that doesn't have universal read permission, and let the
   appropriate process read that file.  The appropriate process may be
   your script in rare cases, but more often it'll be whatever program
   is actually going to use that password.

Thus, there is absolutely no reason you should ever have a secret password
inside a here document or here string.  That would mean the password
is hard-coded inside a shell script, which violates several of my points.

If the password has been read from a file and is now inside a shell
variable (NOT environment variable) in memory, and you want to pass it
on stdin to a process, you do that by running something like

printf %s\\n "$secret" | program

No here strings are wanted.  printf is a builtin, so you aren't violating
point 1.  $secret is not exported, so you aren't violating point 2.

https://mywiki.wooledge.org/BashFAQ/069 and
https://mywiki.wooledge.org/BashFAQ/078 also touch on this, but they
could both use some expansion/rewriting, I see.