Bug 535601 (RHQ-227)
Summary: | Obfuscate DB password stored in rhq-server.properties | ||
---|---|---|---|
Product: | [Other] RHQ Project | Reporter: | Ian Springer <ian.springer> |
Component: | Core Server | Assignee: | Heiko W. Rupp <hrupp> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Corey Welton <cwelton> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 1.0 | CC: | ccrouch, cwelton, herrold, hrupp, loleary, mazz, tao |
Target Milestone: | --- | Keywords: | Improvement |
Target Release: | --- | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://jira.rhq-project.org/browse/RHQ-227 | ||
Whiteboard: | |||
Fixed In Version: | 2.4 | Doc Type: | Enhancement |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-08-12 16:51:21 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 577033 |
Description
Ian Springer
2008-04-03 16:26:00 UTC
This was the case in 1.4 right? At a minimum we need to doc this so people know to control access to this file This page shows how this could work: http://wiki.jboss.org/wiki/EncryptingDataSourcePasswords But at the end, when the password to encrypt is stored with in a Java class, it is only obsfuscating the password for the casual lurker. Those that really want to get access to the db via that password and access to RHQ will also be able to read that above Wiki page ... We discussed not to implement it, as it is security by obscurity and rather document the behaviour and to secure access the rhq-server.properties file. Documented. Reopening this, so we can address it in a future release. Not going to make the 1.1 release This bug was previously known as http://jira.rhq-project.org/browse/RHQ-227 I think we need to avoid doing anything if all we are going to do is implement "security by obscurity" which everyone knows is worse than no security because it lulls people into a sense of "false security". rhq-server.properties needs to be locked down by the people that install the software. Mazz, the idea is to make it harder for casual viewers of the rhq-server.properties file to immediately have access to the RHQ database, i.e. an extract hoop for someone to jump through which also may indicate to them they are doing something they shouldn't. Somebody determined to attack the system will still be able to gain access to the db if they have read access to the rhq-server.properties but obfuscating the password will prevent casual users from wondering into the RHQ database just because they can. I'm changing the title of this jira to make it clearer we're only going to support obfuscation. First cut is in a32db89465af384df8d30b3667f4f545d9893105 in master Additional fix in 1e8fb58 Release note: from RHQ 3.0.0.B05 on passwords for db access will always be encrypted when installing the server. The encrypted password is stored in bin/rhq-server.properties in the property rhq.server.database.password If the database password is upgraded, it also needs to be changed in this property. To generate a new password, the provided scripts $RHQ_SERVER_BIN/generate-db-password.{sh,bat} can be used by giving the db-password as argument like this: $ bin/generate-db-password.sh test Encoded password: 5..6b8b45e01...e > $ bin/generate-db-password.sh test
Passing the password as a command-line arg has a couple security issues:
1) Someone looking over the user's shoulder could see the password.
2) Someone could run "ps" and see the password.
I'd suggest adding support to the script for reading the password from stdin, e.g.:
if [ $# -eq 0 ]; then
read -p "Enter the DB password: " -s DB_PASSWORD
# 2) may be an issue here too - depends how you're encrypting the password
# encrypt $DB_PASSWORD
fi
(In reply to comment #17) > > $ bin/generate-db-password.sh test > > Passing the password as a command-line arg has a couple security issues: > > 1) Someone looking over the user's shoulder could see the password. > 2) Someone could run "ps" and see the password. > > I'd suggest adding support to the script for reading the password from stdin, Reading the password from stdin won't fix 2) with the current implementation as it is just passed into the JVM and would still be exposed on the command line. There are a couple ways around this: 2a) Use a Java class to do the prompting 2b) Offer the option to store the plain-text password in a file and have a Java class read the file and delete it when it is done In either case, it will require the plain-text password to be handled in the JVM and not within the shell/command environment. Of course, this is a common issue with password handling. As the process is short lived, it has become an acceptable practice to just pass it in as an argument and simply realize the associated security risk. An alternative would be nice though for use within those untrusted environments. Windows bat script fix in b0140c2 QA Verified. Moving this back to ON_QA as there's a few more tests I want to consider. QA Verifying. I think it is safe to close this out at this point. Mass-closure of verified bugs against JON. |