Bug 1070262 (JON3-40, PRODMGT-411)

*** Bug 1070279 has been marked as a duplicate of this bug. ***

it looks like this is going to require the user to configure the vault - because the secure web connector settings requires the values in standalone.xml. It can't be obfuscated in the way we do it in rhq-server.properties - if you don't want to put the key/truststore pw in clear text, you have to use the vault.

Perhaps we can automate the creation of a vault for the sole use of our secure web connector.

(In reply to John Mazzitelli from comment #2)
> it looks like this is going to require the user to configure the vault -
> because the secure web connector settings requires the values in
> standalone.xml. It can't be obfuscated in the way we do it in
> rhq-server.properties - if you don't want to put the key/truststore pw in
> clear text, you have to use the vault.
> 
> Perhaps we can automate the creation of a vault for the sole use of our
> secure web connector.

I just realized that this is also asking for obfuscation of agent-configuration.xml - which is agent-side only and thus doesn't even involve EAP so we can't use the vault for that.

In addition, the vault needs to be provided a keystore itself - and thus needs a keystore password that is then obfuscated to configure the vault. This would require manual steps since its the user providing the keystore password and running vault.sh to mask that password. So we would be just kicking the can down the road - to automate something like this we still need to know the keystore password in some fashion (even if its masked).

Still investigating a way to obfuscate these values on both server AND agent and how not to require manual user intervention but allow for automatic setup.

The only other alternative is just to be able to support the vault that the user manually sets up (in other words, we would just provide the steps on how to do this in the documentation, and support vault masked-passwords in rhq-server.properties). This still doesn't solve the agent problem since it doesn't have access to the EAP vault anyway.

*** Bug 577239 has been marked as a duplicate of this bug. ***

The obfuscation feature for agent and server for sensitive properties has been merged in master. The work was done via PR in github. The feature is backwards compatible with existing installations that do not have protection for sensitive fields.

PR link:
https://github.com/rhq-project/rhq/pull/75


A community wiki with the documenatin will be published shortly.

Last feature commit in master: https://github.com/rhq-project/rhq/commit/b7b7ed9b20fe86fb859a69b3b9e4239ea5345d80

Heiko Rupp <hrupp> updated the status of jira JON3-40 to Resolved

Moving to ON_QA as available to test with brew build of DR01: https://brewweb.devel.redhat.com//buildinfo?buildID=373993

This is the community wiki: https://docs.jboss.org/author/display/RHQ/Protect+Sensitive+Server+And+Agent+Configuration

As written in the BZ 1128929, I think the use case described in it is not valid and should not fail this BZ.

Dev, please revise the community wiki, Section 1.b.ii. Otherwise the use case in BZ 1128929 is valid. Thanks.

test run: 
https://tcms.engineering.redhat.com/run/167010/?from_plan=14896

mfoley user <mfoley> updated the status of jira JON3-40 to Reopened

Testing for this feature can resume since blocking bug has been resolved.

Moving to ON_QA as available for test with the following brew build:
https://brewweb.devel.redhat.com//buildinfo?buildID=381194

# COMMENT

Scenario 1:
Check following commands on installed JON 3.3 ER03
===
grep -E "truststore|keystore" ~/.java/.userPrefs/rhq-agent/default/prefs.xml
grep -E "truststore|keystore" ~/current-jon/bin/rhq-server.properties # server
grep -E "truststore|keystore" ~/.java/.userPrefs/rhq-server/default/prefs.xml # server
grep -E "truststore|keystore" ~/rhq-agent/conf/agent-configuration.xml
===

no plain text found on outputs.

Scenario 2:
Check command outputs above on JON 3.2.0 GA agent upgraded to JON 3.3 ER03

Scenario 3:
Check command outputs above on JON 3.2.0 GA server upgraded to JON 3.3 ER03

# REOPEN

doing upgrade of a server from 3.2.0.GA to 3.3.ER03 fails to mask those sensitive info:

scenario to reproduce:
1. install JON 3.2.0.GA
2. stop all services
3. take the 3.3 ER03 and unzip
4. run `./rhqctl upgrade --from-server-dir=/home/hudson/jon-server-3.2.0.GA`
5. refer to: grep -E "truststore|keystore" ~/jon-server-3.3.0.ER03/bin/rhq-server.properties

they are unmasked plain-text keystore info, etc.

release/jon3.3.x branch commits:

commit 2065651c5e7dfd7d0b390e65cf4e82928664b6e1
Author: Stefan Negrea <snegrea>
Date:   Mon Sep 29 09:15:24 2014 -0500

    [BZ 1070262] Few more changes to the agent config update to allow the agent to continue with the startup proce
    (cherry picked from commit 99d8ae11fc1cea26e4b3a116a127757b6be68846)
    
    Signed-off-by: John Mazzitelli <mazz>

commit c233a8d7c6134cd9a76bbe1eef608dce84dbda74
Author: Stefan Negrea <snegrea>
Date:   Fri Sep 26 19:40:47 2014 -0500

    [BZ 1070262] Obfuscate properties in agent-configuration.xml when the file originates from older agents.
    (cherry picked from commit 67f780ae17aa76164006a1af405cb12382952822)
    
    Signed-off-by: John Mazzitelli <mazz>

commit 27ba7a32aab8b2e99c8bd53057ccbc6ebe427837
Author: Stefan Negrea <snegrea>
Date:   Fri Sep 26 15:13:26 2014 -0500

    [BZ 1070262] Snip superfluous "public" access modifier.
    (cherry picked from commit 3ff036a33887fdc3cfa4463f2e1179d183e0c5e2)
    
    Signed-off-by: John Mazzitelli <mazz>

commit e3f67686ed6e4f2d0c1e9263bed51e32c5ff31d9
Author: Stefan Negrea <snegrea>
Date:   Fri Sep 26 11:19:59 2014 -0500

    [BZ 1070262] Updates to the configuration upgrade code for the server and the agent.
    
    This commit resolves the upgrade obfuscation for rhq-server.properties file and some minor tweaks for the agen
    (cherry picked from commit 4d27730aee50a12910e754157ce6e6d13556693a)
    
    Signed-off-by: John Mazzitelli <mazz>

Garik, please re-test both the server and agent upgrade process. On the agent upgrade you need to enable a few obfuscuted properties. By default they are commented out (not active) in the agent-configuration.xml.

Moving to ON_QA as available for test with build:
https://brewweb.devel.redhat.com/buildinfo?buildID=388959

# REOPEN

it is not working correct in case of agent-side "~/.java/.userPrefs/rhq-agent/default/prefs.xml"

I do have fresh/latest JON 3.3 ER04 and with ./rhq-agent.sh -l --advanced I did specified the keystore/trustsore passwords (both client and server side) - all those passwords were written as: "RESTRICTED::mysecretpassword" (plain word of the password i entered and not the hash-ed one).

scenario:
having agent installed from JON 3.3 ER04 jar, perform:
`./rhq-agent.sh -l --advanced`
provide password for the keystore files (and even if connection to the server is not well-configured) look at the default prefs.xml.

The problem from comment #25 has been resolved by commits from bug 1070262. Please retest with ER05.

Moving to CR01 as missed ER05 initial and extended cutoffs.

Just to clarify one more time, this bug has been fixed after ER4. New code was committed before ER5 release. Please retest.

Moving to ON_QA as available to test with the latest brew build:
https://brewweb.devel.redhat.com//buildinfo?buildID=394734

# REOPEN

the scenario of update 3.2.0.GA -> 3.3.0.ER05 not encrypting the passwords. It shows up: RESTRICTED::rhqpwd

the file is: .java/.userPrefs/rhq-agent/default/prefs.xml (agent configs)

This is referencing to the default keystore passwords:

rhq@rhqstorage:~/agent-bug/rhq-agent/bin$ grep password ~/.java/.userPrefs/rhq-agent/default/prefs.xml 
  <entry key="rhq.agent.client.security.keystore.key-password" value="RESTRICTED::rhqpwd"/>
  <entry key="rhq.agent.client.security.keystore.password" value="RESTRICTED::rhqpwd"/>
  <entry key="rhq.agent.client.security.truststore.password" value="RESTRICTED::null"/>
  <entry key="rhq.communications.connector.security.keystore.key-password" value="RESTRICTED::rhqpwd"/>
  <entry key="rhq.communications.connector.security.keystore.password" value="RESTRICTED::rhqpwd"/>
  <entry key="rhq.communications.connector.security.truststore.password" value=""/>
rhq@rhqstorage:~/agent-bug/rhq-agent/bin$

please consider agent update through RPM as well.

Scenario:
===
an 3.2.0.GA agent is being installed and configured to get 2-side certificates enabled.
yum update agent.rpm should take care to mask those password fields.
===

master branch commit that fixes the agent packaging issues:

commit 26fc58f042b8c4c4cfbdc44245b466ce63c33d50
Author: Stefan Negrea <snegrea>
Date:   Tue Oct 28 10:15:05 2014 -0500

    [BZ 1070262] Fix agent packaging to set the picketbox version for ant-run.xml script via ma

Moving to ON_QA as available to test with latest brew build:
https://brewweb.devel.redhat.com//buildinfo?buildID=396547

@Stefan:

now it looks pretty promising, but:

"<entry key="rhq.communications.connector.security.truststore.password" value="plaintext"/>" #(still plain text)

could you please also specify what is the current version of picketbox (and the one that would be updated to have this fixed) - and what is that file name, where is it located etc. (so I could next time investigate, include the version of that package in bug comment(s) as well). thanks

for now let me reopen this bug.

... (In reply to Garik Khachikyan from comment #48)
> @Stefan:
> 
> now it looks pretty promising, but:
> 
> "<entry key="rhq.communications.connector.security.truststore.password"
> value="plaintext"/>" #(still plain text)
> 
> could you please also specify what is the current version of picketbox (and
> the one that would be updated to have this fixed) - and what is that file
> name, where is it located etc. (so I could next time investigate, include
> the version of that package in bug comment(s) as well). thanks
> 
> for now let me reopen this bug.

and the file is: ~/.java/.userPrefs/rhq-agent/default/prefs.xml

note to myself: rpm-based agent has same property not masked too. (latest brew agent rpm).

Created attachment 953643 [details]
prefs.xml (with that property unmasked)

The property that was not encoded was missed from the list of properties to be encoded for the agent configuration. The fix was simple, I just added the property to the list.


master branch commit: 

commit 5807d59ed2186bc94927c3ee3929e96007457a60
Author: Stefan Negrea <snegrea>
Date:   Tue Nov 4 08:59:57 2014 -0600

    [BZ 1070262] Adding one missed property to the list of @RESTRICTED properties for the agent configuration file.

release/jon3.3.x commit 4a4f4e6fc1e0c92f55f679e616977f3d2f692669
Author: Stefan Negrea <snegrea>
Date:   Tue Nov 4 08:59:57 2014 -0600

    (cherry picked from commit 5807d59ed2186bc94927c3ee3929e96007457a60)
    Signed-off-by: Jay Shaughnessy <jshaughn>

Moving to ON_QA as available for test with build:
https://brewweb.devel.redhat.com//buildinfo?buildID=398756

# REOPEN

another "hidden" property left not masked during 3.2.0 -> 3.3 upgrade:
===

scenario:
1. install 3.2.0.GA; configure settings to enable 2-side certification
2. unzip the 3.3 zip
3. configure rhq-server.properties of 3.3 (with plain typed passwords) exactly with values from the current 3.2.0 setup
4. run the upgrade
5. check following:
---
grep -E "truststore|keystore" ~/.java/.userPrefs/rhq-server/default/prefs.xml # this is OK, ALL properties got masked (which is good)
grep -E "truststore|keystore" ~/jon-server-3.3.0.GA/bin/rhq-server.properties

here i do see 2 properties not masked still (rest of them are however):
---
rhq.server.tomcat.security.keystore.password=secret
rhq.server.tomcat.security.truststore.password=secret

I do keeping the reproducer server setup, ping me for the access pls.

Added all the tomcat password related properties to the server configuration constants file and the upgrade code. Both of these will be picked up by the upgrade and usage code automatically.



master branch commit:

commit b9bcae050c1613cfe9a300d8b5e465e072448a67
Author: Stefan Negrea <snegrea>
Date:   Fri Nov 14 09:07:11 2014 -0600

    [BZ 1070262] Added all the tomcat password related properties to the ServerConfigurationConstants file a

https://bugzilla.redhat.com/show_bug.cgi?id=1164299 prepared to track the #56

otherwise: verified.

mfoley user <mfoley> updated the status of jira JON3-40 to Resolved