I have a script that downloads bank transactions to store in a database. To get these transactions requires a password for each account. The database is encrypted and requires a key to access it. All these keys and passwords are themselves encrypted and require a master key to retreive. The script prompts for the master key, uses this to retrieve all the necessary passwords and keys, and then does its work.
Right now this script is being called manually. Automating it to run periodically is easy, except for the part of securing the master key. Simply storing it in a file in plaintext does not seem very secure, as anybody who manages to get read access to the file now has wide open access to a lot of sensitive information. Storing it in a way that the script has it (for example obfuscating it in a binary called by the script) won't work either, because then anyone who can execute the script has an attack vector there.
I have read this question, the answer there appears to be "store it in a file" with added comments suggesting not in plain text. But even if the password is not plain text, it still seems like we have to communicate to the script how to read the file somehow, such as a decryption key or something, and we are back at square one.
Best Answer
Here is how I wound up solving the problem.
First, I created a separate key server that starts up at the same time as the main server. Its sole purpose is to hand out keys to authorized processes. It does this by running an md5sum on the calling binary, then seeing which keys that binary is allowed to access. The calling binary (in this case, the script, which has been compiled to an executable) requests the keys from this server and then proceeds as normal.
The key server runs all the time and maintains a keychain password in its own memory. On startup, it does not have the keychain password, and thus cannot respond to requests for keys. So before it can do this, it requires that the keychain password gets set. This can be done via a web interface or the command line and requires user interaction. This secures the system by requiring that somebody physically enter the correct password. This generally only needs to be done once per reboot, since the key server never terminates.