I am currently formulating security best practices and requirements for ongoing Java software development in my department and have settled with a recommendation of using the Jasypt framework for encryption/decryption of service account credentials stored in application property files on the system. The general parent requirement from our Cyber Security team is that confidential data at rest must be protected through encryption, however there are no specifics provided on proper key management.
The appropriate scheme provided by Jasypt is to use a PBE algorithm that takes a secret passphrase as input and uses this to decrypt protected information in application properties files. You can provide the secret passphrase in a number of ways, and the most appropriate universal way that seems to balance convenience, supportability and security is to obtain this secret through a runtime user environment variable.
Setting a global environment variable is clearly not secure, and our system administrator claims we can't set it at the user level because he claims it would only be loaded as part of the bash profile, and that would mean the application would require being launched from a shell, which precludes it being run as a daemon process.
I was thinking that I could execute the application from a bash shell script where the necessary environment variable is set within the scope of the script before the Java application command is executed. I could then read protect that shell script file only to the runtime user of the daemon process.
The OS in question is RHEL 6.5 running on virtualized servers within our private intranet.
My question is, are there any noticeable exploits here where an attacker could derive the environment variable value somehow? For instance, by running bash history, grepping running processes, peeking at shared memory, etc?
In general are there are any major noticeable flaws with this approach?
