[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "here strings" and tmpfiles
From: |
Greg Wooledge |
Subject: |
Re: "here strings" and tmpfiles |
Date: |
Tue, 19 Mar 2019 08:25:50 -0400 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
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.
Re: "here strings" and tmpfiles, Daniel Kahn Gillmor, 2019/03/19
Re: "here strings" and tmpfiles, Robert Elz, 2019/03/19