Vanilla plugin uses hardcoded password for Oozie MySQL database user

i think the proper fix for this may be as simple as the following patch:

diff --git a/sahara/plugins/vanilla/hadoop2/oozie_helper.py b/sahara/plugins/vanilla/hadoop2/oozie_helper.py
index 734e99f..d51a2ea 100644
--- a/sahara/plugins/vanilla/hadoop2/oozie_helper.py
+++ b/sahara/plugins/vanilla/hadoop2/oozie_helper.py
@@ -13,6 +13,8 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.

+import uuid
+

 def get_oozie_required_xml_configs(hadoop_conf_dir):
     """Following configs differ from default configs in oozie-default.xml."""
@@ -45,5 +47,5 @@ def get_oozie_mysql_configs():
         'oozie.service.JPAService.jdbc.url':
         'jdbc:mysql://localhost:3306/oozie',
         'oozie.service.JPAService.jdbc.username': 'oozie',
- 'oozie.service.JPAService.jdbc.password': 'oozie'
+ 'oozie.service.JPAService.jdbc.password': uuid.uuid4().hex
     }

meant to attach this

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

Is this something a regular user can easily abuse, e.g.: is the oozie backend reachable from a job submitted by a regular users, or is it in the sahara control plane ?

Apologize for the dumb question, but do sahara user have direct access to the node of the cluster?

The oozie backend will be deployed into a tenant network that is specified when the cluster is created. In this respect the oozie node is accessible to anyone who can access that network, this is *not* on the control plane.

So, any user who is part of the project that contains a sahara cluster with an oozie node would, theoretically, be able to access the oozie mysql instance.

IIUC correctly, oozie backend is not shared between tenant and it is only accessible from the tenant's network. So the risk would be an user messing with its own deployment, without impact for other tenants.

Assuming a compromised oozie service can not escalate to the sahara service (e.g., by stalling operation from the api for example), then I think this is a class D type of bug according to VMT taxonomy ( https://security.openstack.org/vmt-process.html#incident-report-taxonomy )

@sahara-coresec, what do you think ?

your description of the networking issue is accurate Tristan.

i also concur that compromising the oozie mysql backend should not result in the capability for an attacker to escalate to the sahara service. a class D type bug sounds appropriate.

@sahara-coresec, any concern if we close the ossa task and make this bug public ?

no concerns from me, i think we can move forward Tristan

Agreed with Michael. Let's move forward

Fix proposed to branch: master
Review: https://review.openstack.org/312497

Change abandoned by Michael McCune (<email address hidden>) on branch: master
Review: https://review.openstack.org/312497

Change abandoned by Vitaly Gridnev (<email address hidden>) on branch: stable/liberty
Review: https://review.openstack.org/312500
Reason: It looks like this change should not be uploaded until actual fix merged to master, so I'm abandoning the change

Change abandoned by Vitaly Gridnev (<email address hidden>) on branch: stable/mitaka
Review: https://review.openstack.org/312499
Reason: It looks like this change should not be uploaded until actual fix merged to master, so I'm abandoning the change

Change abandoned by Michael McCune (<email address hidden>) on branch: master
Review: https://review.openstack.org/312497
Reason: abandoning this as there is a change coming from another author

Reviewed: https://review.openstack.org/325897
Committed: https://git.openstack.org/cgit/openstack/sahara/commit/?id=d29b4cfd04e201500e861086e86274a443243eba
Submitter: Jenkins
Branch: master

commit d29b4cfd04e201500e861086e86274a443243eba
Author: Mikhail Lelyakin <email address hidden>
Date: Mon Jun 6 15:49:40 2016 +0300

    Remove hardcoded password for Oozie service

    Change will correct the oozie configuration to use a random
    password instead of the hardcoded one currently in use.
    Closes-bug: 1541122
    Change-Id: I31c54aefc3c3ac65d928d9892be485ac754b6b10

This issue was fixed in the openstack/sahara 5.0.0.0b3 development milestone.