Re: [PLUG] secure variables in bash

[Mark Bergman via plug <plug@lists.phillylinux.org>]

In the message dated: Wed, 10 Jan 2024 20:18:40 -0500,
The pithy ruminations from Rita via plug on 
[[PLUG] secure variables in bash] were:
=> I am hoping there is a clever, unix-y way to do this.
=> 
=> I have something like this,
=> 
=> secret=$(curl https://server/api/creds | jq .Secret)
=> process --secret=$secret
=> 
=> This works fine, but I was wondering if there was a better way to secure my
=> "secret" with tools like ssh, gpg, etc..

I'm assuming that you've simplified the example a great deal, because
in this case you aren't just vulnerable to someone seeing the contents
of $secret, you are vulnerable to anyone running the 'curl' command on
their own and getting your credentials directly from https://server.

=> 
=> My intention is to avoid seeing secret from `ps` or `bash -x`.  It seems
=> deceptively simple but quite hard to do.
=> 
=> Any ideas?

This is a FAQ (and has been for decades). In future, please look at
stackexchange, etc for lots and lots (and lots!) of similar questions
and a huge number of answers (of varying quality) to get an idea of the
history of this issue, then maybe post here with something more specific.

In short, no there is no way to really do this securely with BASH,
and few ways to do this securely at all.

From your question, it seems as if you are working on a multi-user
machine. If so, the first question to ask is ask yourself is, do you
feel lucky (https://www.youtube.com/watch?v=8Xjr2hnOHiM). Well, do you?

OK, the next question is, do you trust people with root access on that
machine? If not, then anything you do to secure your secret will be
fundamentally insecure, even if other [unprivileged] users can't easily
see what you're doing.

The next question to ask yourself is how important is the secret? If it's
exposed, will you get fired, go to jail, be liable for n*$10K in damages,
or will it an exposure just be mildly embarassing, such as letting other
people know that you regularly post to a Teletubbies fan site?



There are a few things you can do in BASH to make this common scenario
a little more secure.

If the executable "process" can read the secret from an environment
variable, rather than as an argument on the command line, then you could
do something like:

	secret=$(curl https://server/api/creds | jq .Secret)
	process 

without exposing the contents of $secret to "ps".

If you are running this interactively you can leverage things like gpg
keyrings, ssl, etc, something like:

	# get the encrypted string from https://server
	# then decrypt it using a key that's entered (or accessed) interactively
	secret=$(curl https://server/api/creds | jq .Encrypted_string_stored_externally | gpg -d)
	process		# that reads the value of $secret from the environment
	
If "process" absolutely requires the secret passed on command-line,
you can do things with Expect (tk/tcl), writing a wrapper in a that
overwrites the command line arguments after passing them to "process",
etc., but frankly all of those are hacks.

Again, if you don't trust root, all of this is insecure. Even for
non-root users there are a bunch of unavoidable (though usually very
small) timing windows due to use of BASH and pipelines and subshells that
expose a lot of info (the URI to the credentials, your encrypted string,
the method you are using for decryption).

If whole thing needs to be non-interactive (ie., in a cron job) then
this is all much more difficult.

Like anything in security, the degree of effort to keep something "secure"
should be consistent with the value of the information and the likelihood
of an exposure.

Mark

-- 
Mark Bergman    Biker, Rock Climber, SCUBA Diver, Unix mechanic, IATSE #1 Stagehand
'94 Yamaha GTS1000A^1					   2023 Triumph GT Explorer
	  		https://www.flickr.com/photos/rmsppu

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug