From corey.wright at rackspace.com Mon May 2 03:21:12 2016 From: corey.wright at rackspace.com (Corey Wright) Date: Mon, 02 May 2016 03:21:12 -0000 Subject: [Openstack-security] [Bug 1483132] Re: ssh-keygen-to-Paramiko change breaks third-party tools References: <20150810064713.19114.43085.malonedeb@wampee.canonical.com> Message-ID: <20160502032112.24836.67355.malone@wampee.canonical.com> @marco-voelz as the current nova requirements on the "master" branch are "paramiko>=1.16.0" (see http://git.openstack.org/cgit/openstack/nova/tree/requirements.txt?id=5bafd5fba508174f557acfeddbf85de0438c51d7#n24) i believe paramiko 2.0.0 will be pulled in for all future releases (though this also means that unit tests will break / are breaking as they were changed to ber with the original commit (that prompted this "bug" report) and need to change back to the original der. @all for the record my PR (see https://github.com/paramiko/paramiko/pull/572) was not merged, but the larger pycrypto-to-cryptography PR (see https://github.com/paramiko/paramiko/pull/394), which obviated my PR, was merged and present in paramiko 2.0.0. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1483132 Title: ssh-keygen-to-Paramiko change breaks third-party tools Status in OpenStack Compute (nova): Won't Fix Bug description: Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko library [1][2] changed (unintentionally?) the ASN.1 encoding format of SSH private keys from DER to BER. (DER is a strict subset of BER, so anything that can read BER can read DER, but not necessarily the other way around.) Some third-party tools only support DER and this has created at least one issue [3] (specifically because Go's standard library only supports DER). I have provided Paramiko with a small change that makes its SSH private key output equal to OpenSSH's ssh-keygen output (and presumably DER formatted) [4]. Providing a change to Paramiko is just one method of addressing this backwards-incompatibility and interoperability issue. Should the Paramiko change be accepted the unit test output vectors will need to be changed, but should it not, is a reversion of or modification to Nova acceptable to maintain backwards-compatibility and interoperability? [1] https://review.openstack.org/157931 [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a [3] https://github.com/mitchellh/packer/issues/2526 [4] https://github.com/paramiko/paramiko/pull/572 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483132/+subscriptions From corey.wright at rackspace.com Mon May 2 03:38:47 2016 From: corey.wright at rackspace.com (Corey Wright) Date: Mon, 02 May 2016 03:38:47 -0000 Subject: [Openstack-security] [Bug 1483132] Re: ssh-keygen-to-Paramiko change breaks third-party tools References: <20150810064713.19114.43085.malonedeb@wampee.canonical.com> Message-ID: <20160502033847.17572.9253.malone@soybean.canonical.com> @marco-voelz nevermind, i'm an idiot: i forgot about the upper-constraints.txt referenced in tox.ini, which currently contains "paramiko===1.16.0" (see https://git.openstack.org/cgit/openstack/requirements/tree/upper- constraints.txt?id=5c1dcc21174c8fdc5e4e0fbde37ae9fb96dcdeb6#n236) and therefor needs a bump to 2.0.0 (as you requested) to resolve this bug. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1483132 Title: ssh-keygen-to-Paramiko change breaks third-party tools Status in OpenStack Compute (nova): Won't Fix Bug description: Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko library [1][2] changed (unintentionally?) the ASN.1 encoding format of SSH private keys from DER to BER. (DER is a strict subset of BER, so anything that can read BER can read DER, but not necessarily the other way around.) Some third-party tools only support DER and this has created at least one issue [3] (specifically because Go's standard library only supports DER). I have provided Paramiko with a small change that makes its SSH private key output equal to OpenSSH's ssh-keygen output (and presumably DER formatted) [4]. Providing a change to Paramiko is just one method of addressing this backwards-incompatibility and interoperability issue. Should the Paramiko change be accepted the unit test output vectors will need to be changed, but should it not, is a reversion of or modification to Nova acceptable to maintain backwards-compatibility and interoperability? [1] https://review.openstack.org/157931 [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a [3] https://github.com/mitchellh/packer/issues/2526 [4] https://github.com/paramiko/paramiko/pull/572 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483132/+subscriptions From major at mhtx.net Mon May 2 15:42:34 2016 From: major at mhtx.net (Major Hayden) Date: Mon, 02 May 2016 15:42:34 -0000 Subject: [Openstack-security] [Bug 1568027] Re: Security: Add docs for monitoring logs/notifications References: <20160408161603.3473.89222.malonedeb@gac.canonical.com> Message-ID: <20160502154235.23935.34952.launchpad@gac.canonical.com> ** Changed in: openstack-ansible Assignee: Major Hayden (rackerhacker) => Yasmine (yasmine-kandissounon) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1568027 Title: Security: Add docs for monitoring logs/notifications Status in openstack-ansible: Confirmed Bug description: The openstack-ansible-security docs talk about the AIDE and Auditd changes, but they don't talk much about what deployers should be doing with those notifications. Adding some friendly advice about how to handle these would be very useful. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1568027/+subscriptions From 1568029 at bugs.launchpad.net Tue May 3 10:53:46 2016 From: 1568029 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 03 May 2016 10:53:46 -0000 Subject: [Openstack-security] [Bug 1568029] Re: Security: Disable role during major version upgrades References: <20160408161908.32065.20657.malonedeb@chaenomeles.canonical.com> Message-ID: <20160503105347.5288.12037.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/311215 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible/commit/?id=51441fef44e69ef2e79926c86b9a8234214be6e2 Submitter: Jenkins Branch: master commit 51441fef44e69ef2e79926c86b9a8234214be6e2 Author: Jean-Philippe Evrard Date: Fri Apr 29 18:57:58 2016 +0100 Disable security role during major upgrades This commit disables the security hardening role during major upgrades by creating a temporary file. It removes the file after a sucessful upgrade. Change-Id: Ib32e0e317a84a443fb7fc9d3a364a16bd469b6e3 Closes-Bug: #1568029 ** Changed in: openstack-ansible Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1568029 Title: Security: Disable role during major version upgrades Status in openstack-ansible: Fix Released Bug description: Upgrading between major versions of OpenStack services, such as Kilo to Liberty, or Liberty to Mitaka, can be challenging. We should advise deployers to consider disabling the openstack-ansible-security role during an upgrade to reduce the domain of things to troubleshoot during an upgrade. This should be in the docs, the upgrade scripts, or both. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1568029/+subscriptions From davanum at gmail.com Tue May 3 12:29:31 2016 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Tue, 03 May 2016 12:29:31 -0000 Subject: [Openstack-security] [Bug 1556231] Fix included in openstack/openstack-ansible 12.0.11 References: <20160311182127.26542.80930.malonedeb@chaenomeles.canonical.com> Message-ID: <20160503122932.5288.77792.malone@chaenomeles.canonical.com> This issue was fixed in the openstack/openstack-ansible 12.0.11 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1556231 Title: Rootwrap configuration has incorrect ownership Status in openstack-ansible: Fix Released Status in openstack-ansible kilo series: Fix Released Status in openstack-ansible liberty series: Fix Released Status in openstack-ansible trunk series: Fix Released Bug description: The /etc//rootwrap.conf file and /etc//rootwrap.d directory and its contents created by the Nova, Neutron, Cinder and Ceilomer playbooks/roles are incorrectly owned by a user other than root. This is a security vulnerability inasmuch as it may allow users with lower privileges to modify the rootwrap configuration and escalate privileges. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1556231/+subscriptions From davanum at gmail.com Tue May 3 12:56:50 2016 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Tue, 03 May 2016 12:56:50 -0000 Subject: [Openstack-security] [Bug 1556231] Fix included in openstack/openstack-ansible 11.2.14 References: <20160311182127.26542.80930.malonedeb@chaenomeles.canonical.com> Message-ID: <20160503125650.5554.86845.malone@chaenomeles.canonical.com> This issue was fixed in the openstack/openstack-ansible 11.2.14 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1556231 Title: Rootwrap configuration has incorrect ownership Status in openstack-ansible: Fix Released Status in openstack-ansible kilo series: Fix Released Status in openstack-ansible liberty series: Fix Released Status in openstack-ansible trunk series: Fix Released Bug description: The /etc//rootwrap.conf file and /etc//rootwrap.d directory and its contents created by the Nova, Neutron, Cinder and Ceilomer playbooks/roles are incorrectly owned by a user other than root. This is a security vulnerability inasmuch as it may allow users with lower privileges to modify the rootwrap configuration and escalate privileges. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1556231/+subscriptions From davanum at gmail.com Tue May 3 12:59:26 2016 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Tue, 03 May 2016 12:59:26 -0000 Subject: [Openstack-security] [Bug 1498726] Fix included in openstack/openstack-ansible 11.2.14 References: <20150923022208.8903.73759.malonedeb@gac.canonical.com> Message-ID: <20160503125926.23902.71362.malone@gac.canonical.com> This issue was fixed in the openstack/openstack-ansible 11.2.14 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1498726 Title: Specify ciphers with HAProxy SSL frontends Status in openstack-ansible: Fix Released Bug description: For increased security, a specific cipher suite should be specified when configuring HAProxy SSL frontends. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1498726/+subscriptions From davanum at gmail.com Tue May 3 13:03:12 2016 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Tue, 03 May 2016 13:03:12 -0000 Subject: [Openstack-security] [Bug 1466216] Fix included in openstack/openstack-ansible 11.2.14 References: <20150617203545.4905.22166.malonedeb@wampee.canonical.com> Message-ID: <20160503130312.5658.37385.malone@chaenomeles.canonical.com> This issue was fixed in the openstack/openstack-ansible 11.2.14 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1466216 Title: Upgrade to ansible 1.9.2 when released Status in openstack-ansible: Fix Released Status in openstack-ansible kilo series: Fix Released Status in openstack-ansible trunk series: Fix Released Bug description: Ansible 1.9.2 (unreleased) fixed a CVE-2015-3908 that affected usage of get_url. The vulnerability is related to allowing an HTTPS connection to be MITM'd. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1466216/+subscriptions From vgridnev at mirantis.com Wed May 4 13:17:32 2016 From: vgridnev at mirantis.com (Vitaly Gridnev) Date: Wed, 04 May 2016 13:17:32 -0000 Subject: [Openstack-security] [Bug 1541122] Re: Vanilla plugin uses hardcoded password for Oozie MySQL database user References: <20160202222341.14647.37585.malonedeb@gac.canonical.com> Message-ID: <20160504131732.5514.53638.launchpad@chaenomeles.canonical.com> ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1541122 Title: Vanilla plugin uses hardcoded password for Oozie MySQL database user Status in OpenStack Security Advisory: Incomplete Status in Sahara: In Progress Status in Sahara liberty series: Confirmed Status in Sahara mitaka series: Confirmed Bug description: This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments. -- When deploying clusters with the vanilla plugin, the Oozie[1] application must be configured to use a database for storing data related to the scheduling, running, and processing of Hadoop jobs. Oozie is the primary scheduler for jobs entering the Hadoop ecosystem through the vanilla plugin. Sahara configures the credentials for Oozie to access its database, this can be seen in sahara/plugins/vanilla/hadoop2/oozie_helper.py [2]. These credentials are hardcoded, and use a weak password. An intruder with access to the nodes of a cluster that is created by sahara with the vanilla plugin will have access to the database that backs the Oozie installation. With this access, the intruder could change the operational effects of Oozie to produce results other than expected, for example inserting new jobs or altering configurations associated with currently running jobs. As sahara has ultimate control over the deployment and configuration of Oozie on nodes deployed in its clusters, this hardcoded password should be changed in favor of a random password that will be generated uniquely for each deployed cluster. Oozie uses the values associated with the configurations defined in [2] to create the credentials, this means that the change should be a matter of simply changing the source valueof the password for the Oozie user. [1]: https://oozie.apache.org/ [2]: https://github.com/openstack/sahara/blob/master/sahara/plugins/vanilla/hadoop2/oozie_helper.py#L41 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1541122/+subscriptions From msm at redhat.com Wed May 4 13:17:43 2016 From: msm at redhat.com (Michael McCune) Date: Wed, 04 May 2016 13:17:43 -0000 Subject: [Openstack-security] [Bug 1541122] Re: Vanilla plugin uses hardcoded password for Oozie MySQL database user References: <20160202222341.14647.37585.malonedeb@gac.canonical.com> Message-ID: <20160504131744.25434.94493.launchpad@wampee.canonical.com> ** Changed in: sahara Assignee: (unassigned) => Michael McCune (mimccune) ** Changed in: sahara Importance: Undecided => Critical -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1541122 Title: Vanilla plugin uses hardcoded password for Oozie MySQL database user Status in OpenStack Security Advisory: Incomplete Status in Sahara: In Progress Status in Sahara liberty series: Confirmed Status in Sahara mitaka series: Confirmed Bug description: This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments. -- When deploying clusters with the vanilla plugin, the Oozie[1] application must be configured to use a database for storing data related to the scheduling, running, and processing of Hadoop jobs. Oozie is the primary scheduler for jobs entering the Hadoop ecosystem through the vanilla plugin. Sahara configures the credentials for Oozie to access its database, this can be seen in sahara/plugins/vanilla/hadoop2/oozie_helper.py [2]. These credentials are hardcoded, and use a weak password. An intruder with access to the nodes of a cluster that is created by sahara with the vanilla plugin will have access to the database that backs the Oozie installation. With this access, the intruder could change the operational effects of Oozie to produce results other than expected, for example inserting new jobs or altering configurations associated with currently running jobs. As sahara has ultimate control over the deployment and configuration of Oozie on nodes deployed in its clusters, this hardcoded password should be changed in favor of a random password that will be generated uniquely for each deployed cluster. Oozie uses the values associated with the configurations defined in [2] to create the credentials, this means that the change should be a matter of simply changing the source valueof the password for the Oozie user. [1]: https://oozie.apache.org/ [2]: https://github.com/openstack/sahara/blob/master/sahara/plugins/vanilla/hadoop2/oozie_helper.py#L41 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1541122/+subscriptions From vgridnev at mirantis.com Wed May 4 13:18:19 2016 From: vgridnev at mirantis.com (Vitaly Gridnev) Date: Wed, 04 May 2016 13:18:19 -0000 Subject: [Openstack-security] [Bug 1541122] Re: Vanilla plugin uses hardcoded password for Oozie MySQL database user References: <20160202222341.14647.37585.malonedeb@gac.canonical.com> Message-ID: <20160504131820.17141.12263.launchpad@soybean.canonical.com> ** Changed in: sahara Milestone: None => newton-1 ** Also affects: sahara/mitaka Importance: Undecided Status: New ** Also affects: sahara/liberty Importance: Undecided Status: New ** Changed in: sahara Status: New => Confirmed ** Changed in: sahara/liberty Importance: Undecided => Critical ** Changed in: sahara/mitaka Importance: Undecided => Critical ** Changed in: sahara/liberty Status: New => Confirmed ** Changed in: sahara/mitaka Status: New => Confirmed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1541122 Title: Vanilla plugin uses hardcoded password for Oozie MySQL database user Status in OpenStack Security Advisory: Incomplete Status in Sahara: In Progress Status in Sahara liberty series: Confirmed Status in Sahara mitaka series: Confirmed Bug description: When deploying clusters with the vanilla plugin, the Oozie[1] application must be configured to use a database for storing data related to the scheduling, running, and processing of Hadoop jobs. Oozie is the primary scheduler for jobs entering the Hadoop ecosystem through the vanilla plugin. Sahara configures the credentials for Oozie to access its database, this can be seen in sahara/plugins/vanilla/hadoop2/oozie_helper.py [2]. These credentials are hardcoded, and use a weak password. An intruder with access to the nodes of a cluster that is created by sahara with the vanilla plugin will have access to the database that backs the Oozie installation. With this access, the intruder could change the operational effects of Oozie to produce results other than expected, for example inserting new jobs or altering configurations associated with currently running jobs. As sahara has ultimate control over the deployment and configuration of Oozie on nodes deployed in its clusters, this hardcoded password should be changed in favor of a random password that will be generated uniquely for each deployed cluster. Oozie uses the values associated with the configurations defined in [2] to create the credentials, this means that the change should be a matter of simply changing the source valueof the password for the Oozie user. [1]: https://oozie.apache.org/ [2]: https://github.com/openstack/sahara/blob/master/sahara/plugins/vanilla/hadoop2/oozie_helper.py#L41 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1541122/+subscriptions From 1541122 at bugs.launchpad.net Wed May 4 13:23:11 2016 From: 1541122 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 04 May 2016 13:23:11 -0000 Subject: [Openstack-security] [Bug 1541122] Re: Vanilla plugin uses hardcoded password for Oozie MySQL database user References: <20160202222341.14647.37585.malonedeb@gac.canonical.com> Message-ID: <20160504132311.25110.38199.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/312497 ** Changed in: sahara Status: Confirmed => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1541122 Title: Vanilla plugin uses hardcoded password for Oozie MySQL database user Status in OpenStack Security Advisory: Incomplete Status in Sahara: In Progress Status in Sahara liberty series: Confirmed Status in Sahara mitaka series: Confirmed Bug description: When deploying clusters with the vanilla plugin, the Oozie[1] application must be configured to use a database for storing data related to the scheduling, running, and processing of Hadoop jobs. Oozie is the primary scheduler for jobs entering the Hadoop ecosystem through the vanilla plugin. Sahara configures the credentials for Oozie to access its database, this can be seen in sahara/plugins/vanilla/hadoop2/oozie_helper.py [2]. These credentials are hardcoded, and use a weak password. An intruder with access to the nodes of a cluster that is created by sahara with the vanilla plugin will have access to the database that backs the Oozie installation. With this access, the intruder could change the operational effects of Oozie to produce results other than expected, for example inserting new jobs or altering configurations associated with currently running jobs. As sahara has ultimate control over the deployment and configuration of Oozie on nodes deployed in its clusters, this hardcoded password should be changed in favor of a random password that will be generated uniquely for each deployed cluster. Oozie uses the values associated with the configurations defined in [2] to create the credentials, this means that the change should be a matter of simply changing the source valueof the password for the Oozie user. [1]: https://oozie.apache.org/ [2]: https://github.com/openstack/sahara/blob/master/sahara/plugins/vanilla/hadoop2/oozie_helper.py#L41 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1541122/+subscriptions From tdecacqu at redhat.com Wed May 4 13:27:54 2016 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Wed, 04 May 2016 13:27:54 -0000 Subject: [Openstack-security] [Bug 1541122] Re: Vanilla plugin uses hardcoded password for Oozie MySQL database user References: <20160202222341.14647.37585.malonedeb@gac.canonical.com> Message-ID: <20160504132755.23968.39430.launchpad@gac.canonical.com> ** Description changed: - This issue is being treated as a potential security risk under embargo. - Please do not make any public mention of embargoed (private) security - vulnerabilities before their coordinated publication by the OpenStack - Vulnerability Management Team in the form of an official OpenStack - Security Advisory. This includes discussion of the bug or associated - fixes in public forums such as mailing lists, code review systems and - bug trackers. Please also avoid private disclosure to other individuals - not already approved for access to this information, and provide this - same reminder to those who are made aware of the issue prior to - publication. All discussion should remain confined to this private bug - report, and any proposed fixes should be added to the bug as - attachments. - - -- - When deploying clusters with the vanilla plugin, the Oozie[1] application must be configured to use a database for storing data related to the scheduling, running, and processing of Hadoop jobs. Oozie is the primary scheduler for jobs entering the Hadoop ecosystem through the vanilla plugin. Sahara configures the credentials for Oozie to access its database, this can be seen in sahara/plugins/vanilla/hadoop2/oozie_helper.py [2]. These credentials are hardcoded, and use a weak password. An intruder with access to the nodes of a cluster that is created by sahara with the vanilla plugin will have access to the database that backs the Oozie installation. With this access, the intruder could change the operational effects of Oozie to produce results other than expected, for example inserting new jobs or altering configurations associated with currently running jobs. As sahara has ultimate control over the deployment and configuration of Oozie on nodes deployed in its clusters, this hardcoded password should be changed in favor of a random password that will be generated uniquely for each deployed cluster. Oozie uses the values associated with the configurations defined in [2] to create the credentials, this means that the change should be a matter of simply changing the source valueof the password for the Oozie user. [1]: https://oozie.apache.org/ [2]: https://github.com/openstack/sahara/blob/master/sahara/plugins/vanilla/hadoop2/oozie_helper.py#L41 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1541122 Title: Vanilla plugin uses hardcoded password for Oozie MySQL database user Status in OpenStack Security Advisory: Incomplete Status in Sahara: In Progress Status in Sahara liberty series: Confirmed Status in Sahara mitaka series: In Progress Bug description: When deploying clusters with the vanilla plugin, the Oozie[1] application must be configured to use a database for storing data related to the scheduling, running, and processing of Hadoop jobs. Oozie is the primary scheduler for jobs entering the Hadoop ecosystem through the vanilla plugin. Sahara configures the credentials for Oozie to access its database, this can be seen in sahara/plugins/vanilla/hadoop2/oozie_helper.py [2]. These credentials are hardcoded, and use a weak password. An intruder with access to the nodes of a cluster that is created by sahara with the vanilla plugin will have access to the database that backs the Oozie installation. With this access, the intruder could change the operational effects of Oozie to produce results other than expected, for example inserting new jobs or altering configurations associated with currently running jobs. As sahara has ultimate control over the deployment and configuration of Oozie on nodes deployed in its clusters, this hardcoded password should be changed in favor of a random password that will be generated uniquely for each deployed cluster. Oozie uses the values associated with the configurations defined in [2] to create the credentials, this means that the change should be a matter of simply changing the source valueof the password for the Oozie user. [1]: https://oozie.apache.org/ [2]: https://github.com/openstack/sahara/blob/master/sahara/plugins/vanilla/hadoop2/oozie_helper.py#L41 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1541122/+subscriptions From msm at redhat.com Wed May 4 13:30:55 2016 From: msm at redhat.com (Michael McCune) Date: Wed, 04 May 2016 13:30:55 -0000 Subject: [Openstack-security] [Bug 1541122] Re: Vanilla plugin uses hardcoded password for Oozie MySQL database user References: <20160202222341.14647.37585.malonedeb@gac.canonical.com> Message-ID: <20160504133058.25401.29909.launchpad@wampee.canonical.com> ** Changed in: sahara/liberty Assignee: (unassigned) => Michael McCune (mimccune) ** Changed in: sahara/mitaka Assignee: (unassigned) => Michael McCune (mimccune) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1541122 Title: Vanilla plugin uses hardcoded password for Oozie MySQL database user Status in OpenStack Security Advisory: Incomplete Status in Sahara: In Progress Status in Sahara liberty series: Confirmed Status in Sahara mitaka series: In Progress Bug description: When deploying clusters with the vanilla plugin, the Oozie[1] application must be configured to use a database for storing data related to the scheduling, running, and processing of Hadoop jobs. Oozie is the primary scheduler for jobs entering the Hadoop ecosystem through the vanilla plugin. Sahara configures the credentials for Oozie to access its database, this can be seen in sahara/plugins/vanilla/hadoop2/oozie_helper.py [2]. These credentials are hardcoded, and use a weak password. An intruder with access to the nodes of a cluster that is created by sahara with the vanilla plugin will have access to the database that backs the Oozie installation. With this access, the intruder could change the operational effects of Oozie to produce results other than expected, for example inserting new jobs or altering configurations associated with currently running jobs. As sahara has ultimate control over the deployment and configuration of Oozie on nodes deployed in its clusters, this hardcoded password should be changed in favor of a random password that will be generated uniquely for each deployed cluster. Oozie uses the values associated with the configurations defined in [2] to create the credentials, this means that the change should be a matter of simply changing the source valueof the password for the Oozie user. [1]: https://oozie.apache.org/ [2]: https://github.com/openstack/sahara/blob/master/sahara/plugins/vanilla/hadoop2/oozie_helper.py#L41 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1541122/+subscriptions From 1541122 at bugs.launchpad.net Wed May 4 13:32:18 2016 From: 1541122 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 04 May 2016 13:32:18 -0000 Subject: [Openstack-security] [Bug 1541122] Change abandoned on sahara (master) References: <20160202222341.14647.37585.malonedeb@gac.canonical.com> Message-ID: <20160504133218.17289.8394.malone@soybean.canonical.com> Change abandoned by Michael McCune (msm at redhat.com) on branch: master Review: https://review.openstack.org/312497 ** Changed in: sahara/mitaka Status: Confirmed => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1541122 Title: Vanilla plugin uses hardcoded password for Oozie MySQL database user Status in OpenStack Security Advisory: Incomplete Status in Sahara: In Progress Status in Sahara liberty series: Confirmed Status in Sahara mitaka series: In Progress Bug description: When deploying clusters with the vanilla plugin, the Oozie[1] application must be configured to use a database for storing data related to the scheduling, running, and processing of Hadoop jobs. Oozie is the primary scheduler for jobs entering the Hadoop ecosystem through the vanilla plugin. Sahara configures the credentials for Oozie to access its database, this can be seen in sahara/plugins/vanilla/hadoop2/oozie_helper.py [2]. These credentials are hardcoded, and use a weak password. An intruder with access to the nodes of a cluster that is created by sahara with the vanilla plugin will have access to the database that backs the Oozie installation. With this access, the intruder could change the operational effects of Oozie to produce results other than expected, for example inserting new jobs or altering configurations associated with currently running jobs. As sahara has ultimate control over the deployment and configuration of Oozie on nodes deployed in its clusters, this hardcoded password should be changed in favor of a random password that will be generated uniquely for each deployed cluster. Oozie uses the values associated with the configurations defined in [2] to create the credentials, this means that the change should be a matter of simply changing the source valueof the password for the Oozie user. [1]: https://oozie.apache.org/ [2]: https://github.com/openstack/sahara/blob/master/sahara/plugins/vanilla/hadoop2/oozie_helper.py#L41 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1541122/+subscriptions From fungi at yuggoth.org Wed May 4 15:56:00 2016 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 04 May 2016 15:56:00 -0000 Subject: [Openstack-security] [Bug 1541122] Re: Vanilla plugin uses hardcoded password for Oozie MySQL database user References: <20160202222341.14647.37585.malonedeb@gac.canonical.com> Message-ID: <20160504155603.25370.70320.launchpad@wampee.canonical.com> ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1541122 Title: Vanilla plugin uses hardcoded password for Oozie MySQL database user Status in OpenStack Security Advisory: Won't Fix Status in Sahara: In Progress Status in Sahara liberty series: Confirmed Status in Sahara mitaka series: In Progress Bug description: When deploying clusters with the vanilla plugin, the Oozie[1] application must be configured to use a database for storing data related to the scheduling, running, and processing of Hadoop jobs. Oozie is the primary scheduler for jobs entering the Hadoop ecosystem through the vanilla plugin. Sahara configures the credentials for Oozie to access its database, this can be seen in sahara/plugins/vanilla/hadoop2/oozie_helper.py [2]. These credentials are hardcoded, and use a weak password. An intruder with access to the nodes of a cluster that is created by sahara with the vanilla plugin will have access to the database that backs the Oozie installation. With this access, the intruder could change the operational effects of Oozie to produce results other than expected, for example inserting new jobs or altering configurations associated with currently running jobs. As sahara has ultimate control over the deployment and configuration of Oozie on nodes deployed in its clusters, this hardcoded password should be changed in favor of a random password that will be generated uniquely for each deployed cluster. Oozie uses the values associated with the configurations defined in [2] to create the credentials, this means that the change should be a matter of simply changing the source valueof the password for the Oozie user. [1]: https://oozie.apache.org/ [2]: https://github.com/openstack/sahara/blob/master/sahara/plugins/vanilla/hadoop2/oozie_helper.py#L41 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1541122/+subscriptions From doug at doughellmann.com Thu May 5 16:07:55 2016 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 05 May 2016 16:07:55 -0000 Subject: [Openstack-security] [Bug 1556231] Fix included in openstack/openstack-ansible 11.2.15 References: <20160311182127.26542.80930.malonedeb@chaenomeles.canonical.com> Message-ID: <20160505160755.5256.64091.malone@chaenomeles.canonical.com> This issue was fixed in the openstack/openstack-ansible 11.2.15 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1556231 Title: Rootwrap configuration has incorrect ownership Status in openstack-ansible: Fix Released Status in openstack-ansible kilo series: Fix Released Status in openstack-ansible liberty series: Fix Released Status in openstack-ansible trunk series: Fix Released Bug description: The /etc//rootwrap.conf file and /etc//rootwrap.d directory and its contents created by the Nova, Neutron, Cinder and Ceilomer playbooks/roles are incorrectly owned by a user other than root. This is a security vulnerability inasmuch as it may allow users with lower privileges to modify the rootwrap configuration and escalate privileges. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1556231/+subscriptions From gerrit2 at review.openstack.org Fri May 6 02:31:13 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 06 May 2016 02:31:13 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I3835d7364cc3c96c38c917fc0fb1674a11447954 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/271595 Log: commit 3a11faf18a1e48b0b60d80e3a74cd80a09dd0063 Author: Wilson Liu Date: Sat Jan 23 10:25:15 2016 +0800 Huawei: Mask chap password in log Users won't see the chap password shown in the log for safety consideration, so we will mask it in the log. SecurityImpact Closes-Bug: #1535706 Change-Id: I3835d7364cc3c96c38c917fc0fb1674a11447954 From corey.wright at rackspace.com Fri May 6 13:27:11 2016 From: corey.wright at rackspace.com (Corey Wright) Date: Fri, 06 May 2016 13:27:11 -0000 Subject: [Openstack-security] [Bug 1483132] Re: ssh-keygen-to-Paramiko change breaks third-party tools References: <20150810064713.19114.43085.malonedeb@wampee.canonical.com> Message-ID: <20160506132711.20962.74207.malone@wampee.canonical.com> ** Patch added: "crypto: Add support for Paramiko 2.x" https://bugs.launchpad.net/nova/+bug/1483132/+attachment/4657281/+files/crypto-Add-support-for-Paramiko-2.x.patch -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1483132 Title: ssh-keygen-to-Paramiko change breaks third-party tools Status in OpenStack Compute (nova): Won't Fix Bug description: Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko library [1][2] changed (unintentionally?) the ASN.1 encoding format of SSH private keys from DER to BER. (DER is a strict subset of BER, so anything that can read BER can read DER, but not necessarily the other way around.) Some third-party tools only support DER and this has created at least one issue [3] (specifically because Go's standard library only supports DER). I have provided Paramiko with a small change that makes its SSH private key output equal to OpenSSH's ssh-keygen output (and presumably DER formatted) [4]. Providing a change to Paramiko is just one method of addressing this backwards-incompatibility and interoperability issue. Should the Paramiko change be accepted the unit test output vectors will need to be changed, but should it not, is a reversion of or modification to Nova acceptable to maintain backwards-compatibility and interoperability? [1] https://review.openstack.org/157931 [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a [3] https://github.com/mitchellh/packer/issues/2526 [4] https://github.com/paramiko/paramiko/pull/572 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483132/+subscriptions From corey.wright at rackspace.com Fri May 6 13:35:28 2016 From: corey.wright at rackspace.com (Corey Wright) Date: Fri, 06 May 2016 13:35:28 -0000 Subject: [Openstack-security] [Bug 1483132] Re: ssh-keygen-to-Paramiko change breaks third-party tools References: <20150810064713.19114.43085.malonedeb@wampee.canonical.com> Message-ID: <20160506133528.8943.25463.malone@soybean.canonical.com> The attached patch allows nova ("master" branch as of May 3 / HEAD commit 8185dcb57e55f7579b60040649fcd0588177d714) to pass unit tests with either Paramiko 1.x or 2.x. Nova will probably not support both Paramiko 1.x and 2.x simultaneously (due to upper-constraints.txt pinning Paramiko to a specific release; currently it is "1.16.0", but that will probably be changed to "2.0.0" or such), so my patch also includes comments on how to remove the Paramiko 1.x work-around and simply and directly use the appropriate and original Paramiko interface (ie revert change If88beeb3983705621fe736995939ac20b2daf1f3 / commit 1fd0f4f69b21cbd20c0eb0e2f8f4506061f4a211). -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1483132 Title: ssh-keygen-to-Paramiko change breaks third-party tools Status in OpenStack Compute (nova): Won't Fix Bug description: Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko library [1][2] changed (unintentionally?) the ASN.1 encoding format of SSH private keys from DER to BER. (DER is a strict subset of BER, so anything that can read BER can read DER, but not necessarily the other way around.) Some third-party tools only support DER and this has created at least one issue [3] (specifically because Go's standard library only supports DER). I have provided Paramiko with a small change that makes its SSH private key output equal to OpenSSH's ssh-keygen output (and presumably DER formatted) [4]. Providing a change to Paramiko is just one method of addressing this backwards-incompatibility and interoperability issue. Should the Paramiko change be accepted the unit test output vectors will need to be changed, but should it not, is a reversion of or modification to Nova acceptable to maintain backwards-compatibility and interoperability? [1] https://review.openstack.org/157931 [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a [3] https://github.com/mitchellh/packer/issues/2526 [4] https://github.com/paramiko/paramiko/pull/572 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483132/+subscriptions From corey.wright at rackspace.com Fri May 6 13:43:45 2016 From: corey.wright at rackspace.com (Corey Wright) Date: Fri, 06 May 2016 13:43:45 -0000 Subject: [Openstack-security] [Bug 1483132] Re: ssh-keygen-to-Paramiko change breaks third-party tools References: <20150810064713.19114.43085.malonedeb@wampee.canonical.com> Message-ID: <20160506134346.10274.32089.malone@gac.canonical.com> @marco-voelz I'm not familiar with how OpenStack manages the upper-constraint.txt file (as that file is doubtfully specific to Nova, but merely used by it). The best course of action is probably to ping sdague on IRC and ask him the best course of action (as he was the last Nova core reviewer to touch this bug), but any Nova core reviewer should suffice: 1. Open a new bug? 2. Merge the attached patch so that Nova supports both 1.x and 2.x independent of when Paramiko's constraint is upgraded? 3. Prepare a patch that is specific to only Paramiko 2.x (ignoring Paramiko 1.x) and will be merged immediately following the Paramiko constraint being "upgraded" from 1.x to 2.x? -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1483132 Title: ssh-keygen-to-Paramiko change breaks third-party tools Status in OpenStack Compute (nova): Won't Fix Bug description: Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko library [1][2] changed (unintentionally?) the ASN.1 encoding format of SSH private keys from DER to BER. (DER is a strict subset of BER, so anything that can read BER can read DER, but not necessarily the other way around.) Some third-party tools only support DER and this has created at least one issue [3] (specifically because Go's standard library only supports DER). I have provided Paramiko with a small change that makes its SSH private key output equal to OpenSSH's ssh-keygen output (and presumably DER formatted) [4]. Providing a change to Paramiko is just one method of addressing this backwards-incompatibility and interoperability issue. Should the Paramiko change be accepted the unit test output vectors will need to be changed, but should it not, is a reversion of or modification to Nova acceptable to maintain backwards-compatibility and interoperability? [1] https://review.openstack.org/157931 [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a [3] https://github.com/mitchellh/packer/issues/2526 [4] https://github.com/paramiko/paramiko/pull/572 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483132/+subscriptions From 1568029 at bugs.launchpad.net Fri May 6 18:33:40 2016 From: 1568029 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 06 May 2016 18:33:40 -0000 Subject: [Openstack-security] [Bug 1568029] Re: Security: Disable role during major version upgrades References: <20160408161908.32065.20657.malonedeb@chaenomeles.canonical.com> Message-ID: <20160506183341.8116.58334.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/311211 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible/commit/?id=11a270d99a7def6fb65047f2f6b08b8304d6200f Submitter: Jenkins Branch: liberty commit 11a270d99a7def6fb65047f2f6b08b8304d6200f Author: Jean-Philippe Evrard Date: Fri Apr 29 18:43:19 2016 +0100 Doc: Notice to disable security role during major upgrades This commit explains the process to disable the security hardening role for the major upgrades. Change-Id: I26f956d670343f66d06aa0266bfa5c7256231e2f Closes-Bug: #1568029 ** Tags added: in-liberty -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1568029 Title: Security: Disable role during major version upgrades Status in openstack-ansible: Fix Released Bug description: Upgrading between major versions of OpenStack services, such as Kilo to Liberty, or Liberty to Mitaka, can be challenging. We should advise deployers to consider disabling the openstack-ansible-security role during an upgrade to reduce the domain of things to troubleshoot during an upgrade. This should be in the docs, the upgrade scripts, or both. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1568029/+subscriptions From 1568029 at bugs.launchpad.net Sat May 7 17:50:09 2016 From: 1568029 at bugs.launchpad.net (OpenStack Infra) Date: Sat, 07 May 2016 17:50:09 -0000 Subject: [Openstack-security] [Bug 1568029] Fix merged to openstack-ansible (master) References: <20160408161908.32065.20657.malonedeb@chaenomeles.canonical.com> Message-ID: <20160507175009.9255.36492.malone@gac.canonical.com> Reviewed: https://review.openstack.org/311202 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible/commit/?id=12f0c6898312544294e477979053fcafc631e6da Submitter: Jenkins Branch: master commit 12f0c6898312544294e477979053fcafc631e6da Author: Jean-Philippe Evrard Date: Fri Apr 29 18:18:58 2016 +0100 Doc: Notice to disable security hardening role during minor upgrades Change-Id: I9d6adbe293543f953b0fd8b94b94cf21e914cc0b Closes-Bug: #1568029 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1568029 Title: Security: Disable role during major version upgrades Status in openstack-ansible: Fix Released Bug description: Upgrading between major versions of OpenStack services, such as Kilo to Liberty, or Liberty to Mitaka, can be challenging. We should advise deployers to consider disabling the openstack-ansible-security role during an upgrade to reduce the domain of things to troubleshoot during an upgrade. This should be in the docs, the upgrade scripts, or both. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1568029/+subscriptions From tdecacqu at redhat.com Mon May 9 15:21:17 2016 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Mon, 09 May 2016 15:21:17 -0000 Subject: [Openstack-security] [Bug 1576765] Re: Potential DOS: Keystone Extra Fields References: <20160429154657.5758.65558.malonedeb@chaenomeles.canonical.com> Message-ID: <20160509152117.9903.71984.malone@gac.canonical.com> Based on above comments, I've switch that bug to public and removed the OSSA task. ** Information type changed from Private Security to Public ** Description changed: - This issue is being treated as a potential security risk under embargo. - Please do not make any public mention of embargoed (private) security - vulnerabilities before their coordinated publication by the OpenStack - Vulnerability Management Team in the form of an official OpenStack - Security Advisory. This includes discussion of the bug or associated - fixes in public forums such as mailing lists, code review systems and - bug trackers. Please also avoid private disclosure to other individuals - not already approved for access to this information, and provide this - same reminder to those who are made aware of the issue prior to - publication. All discussion should remain confined to this private bug - report, and any proposed fixes should be added to the bug as - attachments. - - -- - A user that has rights to update a resource in Keystone (project, user, domain, etc) can inject extra data (near unlimited amounts) with data that is only limited by the maximum request size. The extra fields cannot be deleted (ever) in the current design (the value of the field can be set to ~1byte minimum). An update excluding the field leaves the field data intact as is. This means that a bad actor can update a keystone resource and do one of the following to DOS Keystone cluster, database replication, database traffic, etc: 1) Create endless numbers of fields with very little data, that will cause longer and longer json serialization/deserailization times due to the volume of elements. 2) Create endless numbers of fields with large data sets, increasing the delta of what is stored in the RDBMS and putting extra load on the replication/etc processes for the shared data. This potentially could be used as a vector to run the DB server out of ram/cache/buffers/disk. This also causes the issue itemized above (1). 3) With HMT, it is possible to duplicate (as a domain/user) the above listed items with more and more resources. Memcache/caching will offset some of these issues until the memcache server can no longer store the data from the keystone resource due to exceeding the slab size (1MB) which could cause excessive load on the memcached servers/caching servers. With caching enabled, it is possible to run the keystone processes out of memory/DOS due to the request_local cache in use to ensure that the resources are fetched from the backend a single time (using a msgpack of the data stored in memory) for a given HTTP request. --- PROPOSED FIX -- * Issue a security bug fix that by default disables the ability to store data in the extra fields for *ALL* keystone resources * Migrate any/all fields that keystone supports to first class-attributes (columns) in the SQL backend[s]. * 2-Cycle deprecation before removal of the support for "extra" field storage (toggled via config value) - in the P Cycle extra fields will no longer be supported. All non-standard data will need to be migrated to an external metadata storage. ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1576765 Title: Potential DOS: Keystone Extra Fields Status in OpenStack Identity (keystone): New Status in OpenStack Security Advisory: Won't Fix Bug description: A user that has rights to update a resource in Keystone (project, user, domain, etc) can inject extra data (near unlimited amounts) with data that is only limited by the maximum request size. The extra fields cannot be deleted (ever) in the current design (the value of the field can be set to ~1byte minimum). An update excluding the field leaves the field data intact as is. This means that a bad actor can update a keystone resource and do one of the following to DOS Keystone cluster, database replication, database traffic, etc: 1) Create endless numbers of fields with very little data, that will cause longer and longer json serialization/deserailization times due to the volume of elements. 2) Create endless numbers of fields with large data sets, increasing the delta of what is stored in the RDBMS and putting extra load on the replication/etc processes for the shared data. This potentially could be used as a vector to run the DB server out of ram/cache/buffers/disk. This also causes the issue itemized above (1). 3) With HMT, it is possible to duplicate (as a domain/user) the above listed items with more and more resources. Memcache/caching will offset some of these issues until the memcache server can no longer store the data from the keystone resource due to exceeding the slab size (1MB) which could cause excessive load on the memcached servers/caching servers. With caching enabled, it is possible to run the keystone processes out of memory/DOS due to the request_local cache in use to ensure that the resources are fetched from the backend a single time (using a msgpack of the data stored in memory) for a given HTTP request. --- PROPOSED FIX -- * Issue a security bug fix that by default disables the ability to store data in the extra fields for *ALL* keystone resources * Migrate any/all fields that keystone supports to first class-attributes (columns) in the SQL backend[s]. * 2-Cycle deprecation before removal of the support for "extra" field storage (toggled via config value) - in the P Cycle extra fields will no longer be supported. All non-standard data will need to be migrated to an external metadata storage. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1576765/+subscriptions From major at mhtx.net Mon May 9 20:54:42 2016 From: major at mhtx.net (Major Hayden) Date: Mon, 09 May 2016 20:54:42 -0000 Subject: [Openstack-security] [Bug 1579914] [NEW] Security role doesn't handle sshd_config with Match Message-ID: <20160509205442.981.10915.malonedeb@chaenomeles.canonical.com> Public bug reported: The security role makes several changes to the sshd_config file, but it doesn't handle situations where the configuration file might end with Match stanzas. There cannot be any general configuration options after any Match stanzas in the configuration file. The role should: * Handle Match stanzas properly * Validate the sshd_config with each change ** Affects: openstack-ansible Importance: Undecided Assignee: Major Hayden (rackerhacker) Status: New ** Tags: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1579914 Title: Security role doesn't handle sshd_config with Match Status in openstack-ansible: New Bug description: The security role makes several changes to the sshd_config file, but it doesn't handle situations where the configuration file might end with Match stanzas. There cannot be any general configuration options after any Match stanzas in the configuration file. The role should: * Handle Match stanzas properly * Validate the sshd_config with each change To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1579914/+subscriptions From 1579914 at bugs.launchpad.net Mon May 9 21:09:23 2016 From: 1579914 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 09 May 2016 21:09:23 -0000 Subject: [Openstack-security] [Bug 1579914] Re: Security role doesn't handle sshd_config with Match References: <20160509205442.981.10915.malonedeb@chaenomeles.canonical.com> Message-ID: <20160509210923.20886.46943.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/314282 ** Changed in: openstack-ansible Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1579914 Title: Security role doesn't handle sshd_config with Match Status in openstack-ansible: In Progress Bug description: The security role makes several changes to the sshd_config file, but it doesn't handle situations where the configuration file might end with Match stanzas. There cannot be any general configuration options after any Match stanzas in the configuration file. The role should: * Handle Match stanzas properly * Validate the sshd_config with each change To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1579914/+subscriptions From sean at dague.net Tue May 10 13:13:29 2016 From: sean at dague.net (Sean Dague) Date: Tue, 10 May 2016 13:13:29 -0000 Subject: [Openstack-security] [Bug 1483132] Re: ssh-keygen-to-Paramiko change breaks third-party tools References: <20150810064713.19114.43085.malonedeb@wampee.canonical.com> Message-ID: <20160510131331.9360.86506.launchpad@gac.canonical.com> ** Changed in: nova Status: Won't Fix => Confirmed ** Changed in: nova Importance: Undecided => Low -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1483132 Title: ssh-keygen-to-Paramiko change breaks third-party tools Status in OpenStack Compute (nova): Confirmed Bug description: Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko library [1][2] changed (unintentionally?) the ASN.1 encoding format of SSH private keys from DER to BER. (DER is a strict subset of BER, so anything that can read BER can read DER, but not necessarily the other way around.) Some third-party tools only support DER and this has created at least one issue [3] (specifically because Go's standard library only supports DER). I have provided Paramiko with a small change that makes its SSH private key output equal to OpenSSH's ssh-keygen output (and presumably DER formatted) [4]. Providing a change to Paramiko is just one method of addressing this backwards-incompatibility and interoperability issue. Should the Paramiko change be accepted the unit test output vectors will need to be changed, but should it not, is a reversion of or modification to Nova acceptable to maintain backwards-compatibility and interoperability? [1] https://review.openstack.org/157931 [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a [3] https://github.com/mitchellh/packer/issues/2526 [4] https://github.com/paramiko/paramiko/pull/572 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483132/+subscriptions From 1483132 at bugs.launchpad.net Tue May 10 14:12:01 2016 From: 1483132 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 10 May 2016 14:12:01 -0000 Subject: [Openstack-security] [Bug 1483132] Related fix proposed to nova (master) References: <20150810064713.19114.43085.malonedeb@wampee.canonical.com> Message-ID: <20160510141201.8720.72635.malone@gac.canonical.com> Related fix proposed to branch: master Review: https://review.openstack.org/314592 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1483132 Title: ssh-keygen-to-Paramiko change breaks third-party tools Status in OpenStack Compute (nova): Confirmed Bug description: Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko library [1][2] changed (unintentionally?) the ASN.1 encoding format of SSH private keys from DER to BER. (DER is a strict subset of BER, so anything that can read BER can read DER, but not necessarily the other way around.) Some third-party tools only support DER and this has created at least one issue [3] (specifically because Go's standard library only supports DER). I have provided Paramiko with a small change that makes its SSH private key output equal to OpenSSH's ssh-keygen output (and presumably DER formatted) [4]. Providing a change to Paramiko is just one method of addressing this backwards-incompatibility and interoperability issue. Should the Paramiko change be accepted the unit test output vectors will need to be changed, but should it not, is a reversion of or modification to Nova acceptable to maintain backwards-compatibility and interoperability? [1] https://review.openstack.org/157931 [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a [3] https://github.com/mitchellh/packer/issues/2526 [4] https://github.com/paramiko/paramiko/pull/572 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483132/+subscriptions From 1483132 at bugs.launchpad.net Tue May 10 15:41:24 2016 From: 1483132 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 10 May 2016 15:41:24 -0000 Subject: [Openstack-security] [Bug 1483132] Re: ssh-keygen-to-Paramiko change breaks third-party tools References: <20150810064713.19114.43085.malonedeb@wampee.canonical.com> Message-ID: <20160510154124.443.95871.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/314639 ** Changed in: nova Status: Confirmed => In Progress ** Changed in: nova Assignee: (unassigned) => Sean Dague (sdague) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1483132 Title: ssh-keygen-to-Paramiko change breaks third-party tools Status in OpenStack Compute (nova): In Progress Bug description: Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko library [1][2] changed (unintentionally?) the ASN.1 encoding format of SSH private keys from DER to BER. (DER is a strict subset of BER, so anything that can read BER can read DER, but not necessarily the other way around.) Some third-party tools only support DER and this has created at least one issue [3] (specifically because Go's standard library only supports DER). I have provided Paramiko with a small change that makes its SSH private key output equal to OpenSSH's ssh-keygen output (and presumably DER formatted) [4]. Providing a change to Paramiko is just one method of addressing this backwards-incompatibility and interoperability issue. Should the Paramiko change be accepted the unit test output vectors will need to be changed, but should it not, is a reversion of or modification to Nova acceptable to maintain backwards-compatibility and interoperability? [1] https://review.openstack.org/157931 [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a [3] https://github.com/mitchellh/packer/issues/2526 [4] https://github.com/paramiko/paramiko/pull/572 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483132/+subscriptions From 1483132 at bugs.launchpad.net Tue May 10 17:06:41 2016 From: 1483132 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 10 May 2016 17:06:41 -0000 Subject: [Openstack-security] [Bug 1483132] Re: ssh-keygen-to-Paramiko change breaks third-party tools References: <20150810064713.19114.43085.malonedeb@wampee.canonical.com> Message-ID: <20160510170644.511.59622.launchpad@chaenomeles.canonical.com> ** Changed in: nova Assignee: Sean Dague (sdague) => Corey Wright (coreywright) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1483132 Title: ssh-keygen-to-Paramiko change breaks third-party tools Status in OpenStack Compute (nova): In Progress Bug description: Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko library [1][2] changed (unintentionally?) the ASN.1 encoding format of SSH private keys from DER to BER. (DER is a strict subset of BER, so anything that can read BER can read DER, but not necessarily the other way around.) Some third-party tools only support DER and this has created at least one issue [3] (specifically because Go's standard library only supports DER). I have provided Paramiko with a small change that makes its SSH private key output equal to OpenSSH's ssh-keygen output (and presumably DER formatted) [4]. Providing a change to Paramiko is just one method of addressing this backwards-incompatibility and interoperability issue. Should the Paramiko change be accepted the unit test output vectors will need to be changed, but should it not, is a reversion of or modification to Nova acceptable to maintain backwards-compatibility and interoperability? [1] https://review.openstack.org/157931 [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a [3] https://github.com/mitchellh/packer/issues/2526 [4] https://github.com/paramiko/paramiko/pull/572 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483132/+subscriptions From 1483132 at bugs.launchpad.net Tue May 10 18:34:08 2016 From: 1483132 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 10 May 2016 18:34:08 -0000 Subject: [Openstack-security] [Bug 1483132] Related fix merged to nova (master) References: <20150810064713.19114.43085.malonedeb@wampee.canonical.com> Message-ID: <20160510183408.21028.23113.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/314592 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=c05b338f163e0bafbe564c6c7c593b819f2f2eac Submitter: Jenkins Branch: master commit c05b338f163e0bafbe564c6c7c593b819f2f2eac Author: Corey Wright Date: Tue May 3 23:13:24 2016 -0500 crypto: Add support for Paramiko 2.x Only use PyCrypto/PyCryptodome work-around with Paramiko 1.x and use straight-forward Paramiko interface with 2.x. TODO: Revert this and PyCrypto/PyCryptodome work-around when Paramiko is upgraded to 2.x (ie replace `generate_keys(bits)` call with `paramiko.RSAKey.generate(bits)`). Change If88beeb3983705621fe736995939ac20b2daf1f3 added a work-around for the partially-PyCrypto-compatible PyCryptodome causing Paramiko, which has a dependency on PyCrypto, to break. This work-around entails implementing Paramiko internals (ie how to generate a key) in Nova in a way compatible with both PyCrypto and PyCryptodom. This work-around is itself a source of failure with Paramiko 2 which has replaced the PyCrypto requirement with the cryptography Python package. As Paramiko no longer depends on PyCrypto, Nova doesn't have an explicit PyCrypto requirement, and there's no implicit dependency on PyCrypto, when Nova tries to import PyCrypto it fails. Even if PyCrypto was installed, the work-around would still fail because the Paramiko interface that Nova is using as part of the work-around changed with the major version change (ie 1.x => 2.x). Change-Id: I5d6543e690a3b4495476027fd8a4894ff8c42bf6 Related-Bug: #1483132 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1483132 Title: ssh-keygen-to-Paramiko change breaks third-party tools Status in OpenStack Compute (nova): In Progress Bug description: Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko library [1][2] changed (unintentionally?) the ASN.1 encoding format of SSH private keys from DER to BER. (DER is a strict subset of BER, so anything that can read BER can read DER, but not necessarily the other way around.) Some third-party tools only support DER and this has created at least one issue [3] (specifically because Go's standard library only supports DER). I have provided Paramiko with a small change that makes its SSH private key output equal to OpenSSH's ssh-keygen output (and presumably DER formatted) [4]. Providing a change to Paramiko is just one method of addressing this backwards-incompatibility and interoperability issue. Should the Paramiko change be accepted the unit test output vectors will need to be changed, but should it not, is a reversion of or modification to Nova acceptable to maintain backwards-compatibility and interoperability? [1] https://review.openstack.org/157931 [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a [3] https://github.com/mitchellh/packer/issues/2526 [4] https://github.com/paramiko/paramiko/pull/572 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483132/+subscriptions From gerrit2 at review.openstack.org Tue May 10 18:46:01 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 10 May 2016 18:46:01 +0000 Subject: [Openstack-security] [openstack/openstack-specs] SecurityImpact review request change I9fba938f4009d984a3a9c186de823315fd6de5df Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/314718 Log: commit 3b6b32faaaef0802b5bc0354b4beac76fa0bc0b6 Author: Joel Coffman Date: Wed Mar 9 10:51:38 2016 -0500 Add image signature verification specification This specification describes an ongoing effort to ensure the integrity of VM images via cryptographic operations. SecurityImpact Change-Id: I9fba938f4009d984a3a9c186de823315fd6de5df From gerrit2 at review.openstack.org Tue May 10 18:47:20 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 10 May 2016 18:47:20 +0000 Subject: [Openstack-security] [openstack/openstack-specs] SecurityImpact review request change I9fba938f4009d984a3a9c186de823315fd6de5df Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/314718 Log: commit 07f466cfc31a8a1c7e469c5266bfecd1d849c097 Author: Joel Coffman Date: Wed Mar 9 10:51:38 2016 -0500 Add image signature verification specification This specification describes an ongoing effort to ensure the integrity of VM images via cryptographic operations. SecurityImpact Co-Authored-By: Dane Fichter Change-Id: I9fba938f4009d984a3a9c186de823315fd6de5df From 1163569 at bugs.launchpad.net Wed May 11 04:17:42 2016 From: 1163569 at bugs.launchpad.net (Launchpad Bug Tracker) Date: Wed, 11 May 2016 04:17:42 -0000 Subject: [Openstack-security] [Bug 1163569] Re: security groups don't work with LBaaS vip and ovs plugin References: <20130402204346.20639.18981.malonedeb@wampee.canonical.com> Message-ID: <20160511041743.2032.30284.malone@loganberry.canonical.com> [Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1163569 Title: security groups don't work with LBaaS vip and ovs plugin Status in neutron: Expired Status in OpenStack Security Notes: Won't Fix Bug description: http://codepad.org/xU8G4s00 I pinged nachi and he suggested to try using: interface_driver = quantum.agent.linux.interface.BridgeInterfaceDriver But after setting this it seems like the vip does not work at all. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1163569/+subscriptions From lhinds at redhat.com Wed May 11 14:50:20 2016 From: lhinds at redhat.com (Luke Hinds) Date: Wed, 11 May 2016 15:50:20 +0100 Subject: [Openstack-security] OSSN-0068 Message-ID: Hi, I added OSSN for rate limiting: https://bugs.launchpad.net/ossn/+bug/1553324 https://review.openstack.org/#/c/313896/ I had a dumb moment and did a git review, without checking out to my own branch first. Is this an issue? I compared it to other reviews and it looks the same, but that might be as they are already merged into master. Should I abandon / reset and then do a branch checkout, or is it OK? I also noted that no reviewers are added. Should I add these manually? My plan is still to do a security docs guide on rate limiting, with text on the different end-points, but its going to take a while, so I pushed this for now to save the OSSN being held up. Regards, Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1483132 at bugs.launchpad.net Wed May 11 21:20:51 2016 From: 1483132 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 11 May 2016 21:20:51 -0000 Subject: [Openstack-security] [Bug 1483132] Re: ssh-keygen-to-Paramiko change breaks third-party tools References: <20150810064713.19114.43085.malonedeb@wampee.canonical.com> Message-ID: <20160511212051.8361.75661.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/314639 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=6b1293fd6f5bcb35f317f36c540f543b1192928c Submitter: Jenkins Branch: master commit 6b1293fd6f5bcb35f317f36c540f543b1192928c Author: Sean Dague Date: Tue May 10 11:39:11 2016 -0400 Drop paramiko < 2 compat code This drops the paramiko < 2 compatibility code so we only need to support one major version. Depends-On: I2369638282b4fefccd8484a5039fcfa9795069a7 (global requirements change) Change-Id: Ife4df9e64299e1182d77d568d1deed5ec3b608b3 Closes-Bug: #1483132 ** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1483132 Title: ssh-keygen-to-Paramiko change breaks third-party tools Status in OpenStack Compute (nova): Fix Released Bug description: Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko library [1][2] changed (unintentionally?) the ASN.1 encoding format of SSH private keys from DER to BER. (DER is a strict subset of BER, so anything that can read BER can read DER, but not necessarily the other way around.) Some third-party tools only support DER and this has created at least one issue [3] (specifically because Go's standard library only supports DER). I have provided Paramiko with a small change that makes its SSH private key output equal to OpenSSH's ssh-keygen output (and presumably DER formatted) [4]. Providing a change to Paramiko is just one method of addressing this backwards-incompatibility and interoperability issue. Should the Paramiko change be accepted the unit test output vectors will need to be changed, but should it not, is a reversion of or modification to Nova acceptable to maintain backwards-compatibility and interoperability? [1] https://review.openstack.org/157931 [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a [3] https://github.com/mitchellh/packer/issues/2526 [4] https://github.com/paramiko/paramiko/pull/572 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1483132/+subscriptions From ian.cordasco at RACKSPACE.COM Thu May 12 20:22:17 2016 From: ian.cordasco at RACKSPACE.COM (Ian Cordasco) Date: Thu, 12 May 2016 20:22:17 +0000 Subject: [Openstack-security] OSSN-0068 In-Reply-To: References: Message-ID: Hi Luke, You don't need to worry about branching first. Gerrit is fine with this. That workflow is more for your simplicity and ease of use than anything else. Reviewers will come along on their own. You don't need to add people. Also, this mailing list is really not used. We prefer to use openstack-dev with the [security] tag. Cheers, Ian P.S. Sorry for top-posting, I'm in a rush. On 5/11/16, 09:50, "Luke Hinds" wrote: >Hi, > > >I added OSSN for rate limiting: > > >https://bugs.launchpad.net/ossn/+bug/1553324 > > > >https://review.openstack.org/#/c/313896/ > > > > >I had a dumb moment and did a git review, without checking out to my own >branch first. Is this an issue? I compared it to other reviews and it >looks the same, but that might be as they are already merged into master. > > >Should I abandon / reset and then do a branch checkout, or is it OK? > > >I also noted that no reviewers are added. Should I add these manually? > > > >My plan is still to do a security docs guide on rate limiting, with text >on the different end-points, but its going to take a while, so I pushed >this for now to save the OSSN being held up. > > >Regards, >Luke > > > > > > From 1579914 at bugs.launchpad.net Mon May 16 03:21:02 2016 From: 1579914 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 16 May 2016 03:21:02 -0000 Subject: [Openstack-security] [Bug 1579914] Re: Security role doesn't handle sshd_config with Match References: <20160509205442.981.10915.malonedeb@chaenomeles.canonical.com> Message-ID: <20160516032102.8755.88319.malone@gac.canonical.com> Reviewed: https://review.openstack.org/314282 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=54de1b5734b6561b4f01efed91bb612ff26e8d40 Submitter: Jenkins Branch: master commit 54de1b5734b6561b4f01efed91bb612ff26e8d40 Author: Major Hayden Date: Mon May 9 16:07:39 2016 -0500 Handle Match properly in sshd_config The security role was not properly handling ssh configuration files that have Match stanzas. This patch ensures that all added configurations appear before the Match stanzas in the /etc/ssh/sshd_config file. Closes-bug: 1579914 Change-Id: Ic7575490cda2bdba880e860e2e400029a84d7d45 ** Changed in: openstack-ansible Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1579914 Title: Security role doesn't handle sshd_config with Match Status in openstack-ansible: Fix Released Bug description: The security role makes several changes to the sshd_config file, but it doesn't handle situations where the configuration file might end with Match stanzas. There cannot be any general configuration options after any Match stanzas in the configuration file. The role should: * Handle Match stanzas properly * Validate the sshd_config with each change To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1579914/+subscriptions From 1582185 at bugs.launchpad.net Mon May 16 13:27:49 2016 From: 1582185 at bugs.launchpad.net (Brian Haley) Date: Mon, 16 May 2016 13:27:49 -0000 Subject: [Openstack-security] [Bug 1582185] Re: when vm detaches security group with remote_group_id, vm's ip address don't be deleted from ipset member. References: <20160516111757.8981.38537.malonedeb@gac.canonical.com> Message-ID: <20160516132749.903.57121.malone@chaenomeles.canonical.com> What release of neutron is this? Could possibly already be fixed upstream. ** Changed in: neutron Status: New => Incomplete -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1582185 Title: when vm detaches security group with remote_group_id, vm's ip address don't be deleted from ipset member. Status in neutron: Incomplete Bug description: There is default security group, and have been attached two vms, the security group as below: | 204844ae-6939-44d3-a375-1999cd44c942 | default | egress, IPv4 | | | | egress, IPv4, 22/tcp, remote_group_id: 204844ae-6939-44d3-a375-1999cd44c942 | | | | egress, IPv6 | | | | ingress, IPv4, 22/tcp | | | | ingress, IPv4, 3389/tcp | | | | ingress, IPv4, icmp, remote_ip_prefix: 0.0.0.0/0 | | | | ingress, IPv4, remote_group_id: 204844ae-6939-44d3-a375-1999cd44c942 | | | | ingress, IPv6, 22/tcp | | | | ingress, IPv6, 3389/tcp | | | | ingress, IPv6, icmp | | | | ingress, IPv6, remote_group_id: 204844ae-6939-44d3-a375-1999cd44c942 | [root at openstack ~(keystone_admin)]# nova list +--------------------------------------+-------+--------+------------+-------------+-------------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+-------+--------+------------+-------------+-------------------+ | 4558881d-2784-40b8-a0fc-a8238196ca47 | vm1 | ACTIVE | - | Running | dddd=172.16.0.9 | | e67ba1de-305d-4915-a2bc-bb24b0389546 | vm2 | ACTIVE | - | Running | test=192.168.12.6 | +--------------------------------------+-------+--------+------------+-------------+-------------------+ Reproduce: step 1: vm1 attaches the default security group step 2: vm2 attaches the default security group, we can see the ipset member: [root at openstack ~]# ipset list NETIPv4204844ae-6939-44d3-a Name: NETIPv4204844ae-6939-44d3-a Type: hash:net Revision: 3 Header: family inet hashsize 1024 maxelem 65536 Size in memory: 16880 References: 6 Members: 192.168.12.6 172.16.0.9 step3: vm2 detaches the default, now we can see "192.168.12.6" still over there: [root at openstack ~]# ipset list NETIPv4204844ae-6939-44d3-a Name: NETIPv4204844ae-6939-44d3-a Type: hash:net Revision: 3 Header: family inet hashsize 1024 maxelem 65536 Size in memory: 16880 References: 5 Members: 192.168.12.6 172.16.0.9 Expected: "192.168.12.6" should be removed from ipset member. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1582185/+subscriptions From 1579914 at bugs.launchpad.net Mon May 16 14:10:03 2016 From: 1579914 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 16 May 2016 14:10:03 -0000 Subject: [Openstack-security] [Bug 1579914] Fix proposed to openstack-ansible-security (stable/mitaka) References: <20160509205442.981.10915.malonedeb@chaenomeles.canonical.com> Message-ID: <20160516141003.9086.64290.malone@gac.canonical.com> Fix proposed to branch: stable/mitaka Review: https://review.openstack.org/316868 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1579914 Title: Security role doesn't handle sshd_config with Match Status in openstack-ansible: Fix Released Bug description: The security role makes several changes to the sshd_config file, but it doesn't handle situations where the configuration file might end with Match stanzas. There cannot be any general configuration options after any Match stanzas in the configuration file. The role should: * Handle Match stanzas properly * Validate the sshd_config with each change To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1579914/+subscriptions From 1579914 at bugs.launchpad.net Mon May 16 14:10:18 2016 From: 1579914 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 16 May 2016 14:10:18 -0000 Subject: [Openstack-security] [Bug 1579914] Fix proposed to openstack-ansible-security (liberty) References: <20160509205442.981.10915.malonedeb@chaenomeles.canonical.com> Message-ID: <20160516141018.8887.2798.malone@gac.canonical.com> Fix proposed to branch: liberty Review: https://review.openstack.org/316869 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1579914 Title: Security role doesn't handle sshd_config with Match Status in openstack-ansible: Fix Released Bug description: The security role makes several changes to the sshd_config file, but it doesn't handle situations where the configuration file might end with Match stanzas. There cannot be any general configuration options after any Match stanzas in the configuration file. The role should: * Handle Match stanzas properly * Validate the sshd_config with each change To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1579914/+subscriptions From 1582185 at bugs.launchpad.net Tue May 17 09:11:39 2016 From: 1582185 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 17 May 2016 09:11:39 -0000 Subject: [Openstack-security] [Bug 1582185] Re: when vm detaches security group with remote_group_id, vm's ip address don't be deleted from ipset member. References: <20160516111757.8981.38537.malonedeb@gac.canonical.com> Message-ID: <20160517091139.9360.97042.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/317333 ** Changed in: neutron Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1582185 Title: when vm detaches security group with remote_group_id, vm's ip address don't be deleted from ipset member. Status in neutron: In Progress Bug description: There is default security group, and have been attached two vms, the security group as below: | 204844ae-6939-44d3-a375-1999cd44c942 | default | egress, IPv4 | | | | egress, IPv4, 22/tcp, remote_group_id: 204844ae-6939-44d3-a375-1999cd44c942 | | | | egress, IPv6 | | | | ingress, IPv4, 22/tcp | | | | ingress, IPv4, 3389/tcp | | | | ingress, IPv4, icmp, remote_ip_prefix: 0.0.0.0/0 | | | | ingress, IPv4, remote_group_id: 204844ae-6939-44d3-a375-1999cd44c942 | | | | ingress, IPv6, 22/tcp | | | | ingress, IPv6, 3389/tcp | | | | ingress, IPv6, icmp | | | | ingress, IPv6, remote_group_id: 204844ae-6939-44d3-a375-1999cd44c942 | [root at openstack ~(keystone_admin)]# nova list +--------------------------------------+-------+--------+------------+-------------+-------------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+-------+--------+------------+-------------+-------------------+ | 4558881d-2784-40b8-a0fc-a8238196ca47 | vm1 | ACTIVE | - | Running | dddd=172.16.0.9 | | e67ba1de-305d-4915-a2bc-bb24b0389546 | vm2 | ACTIVE | - | Running | test=192.168.12.6 | +--------------------------------------+-------+--------+------------+-------------+-------------------+ Reproduce: step 1: vm1 attaches the default security group step 2: vm2 attaches the default security group, we can see the ipset member: [root at openstack ~]# ipset list NETIPv4204844ae-6939-44d3-a Name: NETIPv4204844ae-6939-44d3-a Type: hash:net Revision: 3 Header: family inet hashsize 1024 maxelem 65536 Size in memory: 16880 References: 6 Members: 192.168.12.6 172.16.0.9 step3: vm2 detaches the default, now we can see "192.168.12.6" still over there: [root at openstack ~]# ipset list NETIPv4204844ae-6939-44d3-a Name: NETIPv4204844ae-6939-44d3-a Type: hash:net Revision: 3 Header: family inet hashsize 1024 maxelem 65536 Size in memory: 16880 References: 5 Members: 192.168.12.6 172.16.0.9 Expected: "192.168.12.6" should be removed from ipset member. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1582185/+subscriptions From 1579914 at bugs.launchpad.net Tue May 17 11:03:57 2016 From: 1579914 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 17 May 2016 11:03:57 -0000 Subject: [Openstack-security] [Bug 1579914] Re: Security role doesn't handle sshd_config with Match References: <20160509205442.981.10915.malonedeb@chaenomeles.canonical.com> Message-ID: <20160517110357.9734.36482.malone@gac.canonical.com> Reviewed: https://review.openstack.org/316869 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=d90908f0cc10301503bcae1a92ca69474746f517 Submitter: Jenkins Branch: liberty commit d90908f0cc10301503bcae1a92ca69474746f517 Author: Major Hayden Date: Mon May 9 16:07:39 2016 -0500 Handle Match properly in sshd_config The security role was not properly handling ssh configuration files that have Match stanzas. This patch ensures that all added configurations appear before the Match stanzas in the /etc/ssh/sshd_config file. Closes-bug: 1579914 Change-Id: Ic7575490cda2bdba880e860e2e400029a84d7d45 (cherry picked from commit 54de1b5734b6561b4f01efed91bb612ff26e8d40) ** Tags added: in-liberty -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1579914 Title: Security role doesn't handle sshd_config with Match Status in openstack-ansible: Fix Released Bug description: The security role makes several changes to the sshd_config file, but it doesn't handle situations where the configuration file might end with Match stanzas. There cannot be any general configuration options after any Match stanzas in the configuration file. The role should: * Handle Match stanzas properly * Validate the sshd_config with each change To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1579914/+subscriptions From gerrit2 at review.openstack.org Tue May 17 11:56:03 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 17 May 2016 11:56:03 +0000 Subject: [Openstack-security] [openstack/openstack-specs] SecurityImpact review request change I9fba938f4009d984a3a9c186de823315fd6de5df Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/314718 Log: commit 80095c90bc4fb90fd18c64a45833e37ff1014ca2 Author: Joel Coffman Date: Wed Mar 9 10:51:38 2016 -0500 Add image signature verification specification This specification describes an ongoing effort to ensure the integrity of VM images via cryptographic operations. SecurityImpact Co-Authored-By: Dane Fichter Change-Id: I9fba938f4009d984a3a9c186de823315fd6de5df From mzoeller at de.ibm.com Tue May 17 12:07:09 2016 From: mzoeller at de.ibm.com (Markus Zoeller (markus_z)) Date: Tue, 17 May 2016 12:07:09 -0000 Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota requests against Keystone References: <20130207064604.19234.83660.malonedeb@gac.canonical.com> Message-ID: <20160517120710.20886.82110.malone@wampee.canonical.com> see comments #26 + #22 This wishlist bug has been open a year without any activity. I'm going to move it to "Opinion / Wishlist", which is an easily-obtainable queue of older requests that have come on. This bug can be reopened (set back to "New") if someone decides to work on this. ** Changed in: nova Status: Confirmed => Opinion -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1118066 Title: Nova should confirm quota requests against Keystone Status in OpenStack Compute (nova): Opinion Bug description: os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/ against Keystone to ensure that :tenant does exist. POST requests to a non-existant tenant should fail with a 400 error code. GET requests to a non-existant tenant may fail with a 400 error code. Current behavior is to return 200 with the default quotas. A slightly incompatible change would be to return a 302 redirect to /v2/:tenant /os-quota-sets/defaults in this case. Edit (2014-01-22) Original Description -------------------- GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist returns 200 with the default quotas. Moreover POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist with updated quotas succeeds and that metadata is saved! I'm not sure if this is a bug or not. I cannot find any documentation on this interface. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions From gerrit2 at review.openstack.org Tue May 17 16:04:12 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 17 May 2016 16:04:12 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Id586b2558fd4c7ed0eda3d3555d51fcd019eb414 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/115483 Log: commit 4ddab3e11d4b05bc6783026692a42e744241e6a3 Author: Solly Ross Date: Tue Aug 19 18:48:00 2014 -0400 Introduce VNC Security Proxy Framework This commit introduces the security proxying framework for VNC. Which class is being used to do the security proxying can be set on a per-traffic-type basis by pointing the appropriate configuration option to an appropriate subclass. Currently, only VNC is supported, via the configuration option 'novncproxy_security_driver'. The workflow for adding a new VNC security proxy driver is to subclass the traffic-type-specific security proxy base classes (e.g. RFBSecurityProxyHelper), and implement the `choose_security_type` and `security_handshake` methods. DocImpact SecurityImpact Implements bp: websocket-proxy-to-host-security Change-Id: Id586b2558fd4c7ed0eda3d3555d51fcd019eb414 From gerrit2 at review.openstack.org Tue May 17 16:04:19 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 17 May 2016 16:04:19 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I64859ad01120782fb17308aac3abb125597c3ea2 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/115484 Log: commit dadd02c330878507934a15f5d3cdfec78aaaccf8 Author: Solly Ross Date: Tue Aug 19 19:21:52 2014 -0400 Add VeNCrypt (TLS/x509) Security Proxy Driver This adds support for using x509/TLS security between the compute node and websocket proxy when using websockify to proxy VNC traffic. In order to use this with x509, an operator would have to set up client keys and certificates, as well as CA certificates, and configure libvirt to pass the appropriate options to QEmu (this is configured globally for libvirt, not by Nova). This process is documented on the libvirt website. Then, the operator would enable this driver and set the following options in /etc/nova/nova.conf: [console_proxy_tls] client_key = /path/to/client/keyfile client_cert = /path/to/client/cert.pem ca_certs = /path/to/ca/cert.pem SecurityImpact DocImpact Implements bp: websocket-proxy-to-host-security Change-Id: I64859ad01120782fb17308aac3abb125597c3ea2 From 1541122 at bugs.launchpad.net Tue May 17 16:03:27 2016 From: 1541122 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 17 May 2016 16:03:27 -0000 Subject: [Openstack-security] [Bug 1541122] Change abandoned on sahara (stable/liberty) References: <20160202222341.14647.37585.malonedeb@gac.canonical.com> Message-ID: <20160517160327.8821.23248.malone@gac.canonical.com> Change abandoned by Vitaly Gridnev (vgridnev at mirantis.com) 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 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1541122 Title: Vanilla plugin uses hardcoded password for Oozie MySQL database user Status in OpenStack Security Advisory: Won't Fix Status in Sahara: In Progress Status in Sahara liberty series: Confirmed Status in Sahara mitaka series: In Progress Bug description: When deploying clusters with the vanilla plugin, the Oozie[1] application must be configured to use a database for storing data related to the scheduling, running, and processing of Hadoop jobs. Oozie is the primary scheduler for jobs entering the Hadoop ecosystem through the vanilla plugin. Sahara configures the credentials for Oozie to access its database, this can be seen in sahara/plugins/vanilla/hadoop2/oozie_helper.py [2]. These credentials are hardcoded, and use a weak password. An intruder with access to the nodes of a cluster that is created by sahara with the vanilla plugin will have access to the database that backs the Oozie installation. With this access, the intruder could change the operational effects of Oozie to produce results other than expected, for example inserting new jobs or altering configurations associated with currently running jobs. As sahara has ultimate control over the deployment and configuration of Oozie on nodes deployed in its clusters, this hardcoded password should be changed in favor of a random password that will be generated uniquely for each deployed cluster. Oozie uses the values associated with the configurations defined in [2] to create the credentials, this means that the change should be a matter of simply changing the source valueof the password for the Oozie user. [1]: https://oozie.apache.org/ [2]: https://github.com/openstack/sahara/blob/master/sahara/plugins/vanilla/hadoop2/oozie_helper.py#L41 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1541122/+subscriptions From 1541122 at bugs.launchpad.net Tue May 17 16:03:49 2016 From: 1541122 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 17 May 2016 16:03:49 -0000 Subject: [Openstack-security] [Bug 1541122] Change abandoned on sahara (stable/mitaka) References: <20160202222341.14647.37585.malonedeb@gac.canonical.com> Message-ID: <20160517160349.21378.41756.malone@wampee.canonical.com> Change abandoned by Vitaly Gridnev (vgridnev at mirantis.com) 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 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1541122 Title: Vanilla plugin uses hardcoded password for Oozie MySQL database user Status in OpenStack Security Advisory: Won't Fix Status in Sahara: In Progress Status in Sahara liberty series: Confirmed Status in Sahara mitaka series: In Progress Bug description: When deploying clusters with the vanilla plugin, the Oozie[1] application must be configured to use a database for storing data related to the scheduling, running, and processing of Hadoop jobs. Oozie is the primary scheduler for jobs entering the Hadoop ecosystem through the vanilla plugin. Sahara configures the credentials for Oozie to access its database, this can be seen in sahara/plugins/vanilla/hadoop2/oozie_helper.py [2]. These credentials are hardcoded, and use a weak password. An intruder with access to the nodes of a cluster that is created by sahara with the vanilla plugin will have access to the database that backs the Oozie installation. With this access, the intruder could change the operational effects of Oozie to produce results other than expected, for example inserting new jobs or altering configurations associated with currently running jobs. As sahara has ultimate control over the deployment and configuration of Oozie on nodes deployed in its clusters, this hardcoded password should be changed in favor of a random password that will be generated uniquely for each deployed cluster. Oozie uses the values associated with the configurations defined in [2] to create the credentials, this means that the change should be a matter of simply changing the source valueof the password for the Oozie user. [1]: https://oozie.apache.org/ [2]: https://github.com/openstack/sahara/blob/master/sahara/plugins/vanilla/hadoop2/oozie_helper.py#L41 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1541122/+subscriptions From mzoeller at de.ibm.com Tue May 17 16:13:21 2016 From: mzoeller at de.ibm.com (Markus Zoeller (markus_z)) Date: Tue, 17 May 2016 16:13:21 -0000 Subject: [Openstack-security] [Bug 1319640] Re: Console to instance persists even after logging out of Horizon References: <20140515051902.16303.85738.malonedeb@gac.canonical.com> Message-ID: <20160517161321.10380.3474.malone@gac.canonical.com> This wishlist bug has been open a year without any activity. I'm going to move it to "Opinion / Wishlist", which is an easily-obtainable queue of older requests that have come on. In case you want to work on that, consider writing a blueprints [1] and spec [2]. I'll recommend to read [3] if not yet done. The effort to implement the requested feature is then driven only by the blueprint (and spec). References: [1] https://blueprints.launchpad.net/nova/ [2] https://github.com/openstack/nova-specs [3] https://wiki.openstack.org/wiki/Blueprints ** Changed in: nova Status: Confirmed => Opinion -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1319640 Title: Console to instance persists even after logging out of Horizon Status in OpenStack Compute (nova): Opinion Bug description: Steps to Recreate the bug 1. Log in through Horizon dashboard 2. Create an instance and wait till it is running 3. Console the VM from drop down menu for the instance 4. Open Console on new window. 5. Now log out of the dashboard 6. Scenario 1 : Now you can see that Instance console session still persists 7. Copy the URL of console window. 8. Close the Console window 9. Scenario 2 : Reopen the window (In my case CTRL+SHIFT+T) on the browser - Will get access to the Instance Console. 10. Scenario 3: Pass on the copied URL to other LAN users and ask them to use it - Will get access to the Instance Console I assume it must have been like, Session for the console must exit once the console is closed. Must not allow multiple sessions (Refering to Scenario 3) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1319640/+subscriptions From major at mhtx.net Tue May 17 17:47:07 2016 From: major at mhtx.net (Major Hayden) Date: Tue, 17 May 2016 17:47:07 -0000 Subject: [Openstack-security] [Bug 1582832] [NEW] Security configurations for sshd should be configurable Message-ID: <20160517174708.7858.20385.malonedeb@soybean.canonical.com> Public bug reported: Very few of the sshd-related configurations in openstack-ansible- security are configurable. All of these should be configurable via Ansible variables. ** Affects: openstack-ansible Importance: Low Assignee: Major Hayden (rackerhacker) Status: New ** Tags: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1582832 Title: Security configurations for sshd should be configurable Status in openstack-ansible: New Bug description: Very few of the sshd-related configurations in openstack-ansible- security are configurable. All of these should be configurable via Ansible variables. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1582832/+subscriptions From major at mhtx.net Tue May 17 18:38:45 2016 From: major at mhtx.net (Major Hayden) Date: Tue, 17 May 2016 18:38:45 -0000 Subject: [Openstack-security] [Bug 1582832] Re: Security configurations for sshd should be configurable References: <20160517174708.7858.20385.malonedeb@soybean.canonical.com> Message-ID: <20160517183845.9255.52210.malone@gac.canonical.com> Disregard this one. ** Changed in: openstack-ansible Status: New => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1582832 Title: Security configurations for sshd should be configurable Status in openstack-ansible: Won't Fix Bug description: Very few of the sshd-related configurations in openstack-ansible- security are configurable. All of these should be configurable via Ansible variables. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1582832/+subscriptions From 1579914 at bugs.launchpad.net Wed May 18 09:07:16 2016 From: 1579914 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 18 May 2016 09:07:16 -0000 Subject: [Openstack-security] [Bug 1579914] Re: Security role doesn't handle sshd_config with Match References: <20160509205442.981.10915.malonedeb@chaenomeles.canonical.com> Message-ID: <20160518090716.9734.50658.malone@gac.canonical.com> Reviewed: https://review.openstack.org/316868 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=b1db632ce6ac13ae3b17dee7eaa31d33ddf19442 Submitter: Jenkins Branch: stable/mitaka commit b1db632ce6ac13ae3b17dee7eaa31d33ddf19442 Author: Major Hayden Date: Mon May 9 16:07:39 2016 -0500 Handle Match properly in sshd_config The security role was not properly handling ssh configuration files that have Match stanzas. This patch ensures that all added configurations appear before the Match stanzas in the /etc/ssh/sshd_config file. Closes-bug: 1579914 Change-Id: Ic7575490cda2bdba880e860e2e400029a84d7d45 (cherry picked from commit 54de1b5734b6561b4f01efed91bb612ff26e8d40) ** Tags added: in-stable-mitaka -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1579914 Title: Security role doesn't handle sshd_config with Match Status in openstack-ansible: Fix Released Bug description: The security role makes several changes to the sshd_config file, but it doesn't handle situations where the configuration file might end with Match stanzas. There cannot be any general configuration options after any Match stanzas in the configuration file. The role should: * Handle Match stanzas properly * Validate the sshd_config with each change To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1579914/+subscriptions From gerrit2 at review.openstack.org Thu May 19 10:55:18 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 19 May 2016 10:55:18 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Id586b2558fd4c7ed0eda3d3555d51fcd019eb414 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/115483 Log: commit 44b62dd61f05844f61bad8a3405f3ac87b0a30ec Author: Solly Ross Date: Tue Aug 19 18:48:00 2014 -0400 Introduce VNC Security Proxy Framework This commit introduces the security proxying framework for VNC. Which class is being used to do the security proxying can be set on a per-traffic-type basis by pointing the appropriate configuration option to an appropriate subclass. Currently, only VNC is supported, via the configuration option 'novncproxy_security_driver'. The workflow for adding a new VNC security proxy driver is to subclass the traffic-type-specific security proxy base classes (e.g. RFBSecurityProxyHelper), and implement the `choose_security_type` and `security_handshake` methods. DocImpact SecurityImpact Implements bp: websocket-proxy-to-host-security Change-Id: Id586b2558fd4c7ed0eda3d3555d51fcd019eb414 From gerrit2 at review.openstack.org Thu May 19 10:55:25 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 19 May 2016 10:55:25 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I64859ad01120782fb17308aac3abb125597c3ea2 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/115484 Log: commit 98a8eace68923039e5aa089106f6d2dda8d5da3b Author: Solly Ross Date: Tue Aug 19 19:21:52 2014 -0400 Add VeNCrypt (TLS/x509) Security Proxy Driver This adds support for using x509/TLS security between the compute node and websocket proxy when using websockify to proxy VNC traffic. In order to use this with x509, an operator would have to set up client keys and certificates, as well as CA certificates, and configure libvirt to pass the appropriate options to QEmu (this is configured globally for libvirt, not by Nova). This process is documented on the libvirt website. Then, the operator would enable this driver and set the following options in /etc/nova/nova.conf: [console_proxy_tls] client_key = /path/to/client/keyfile client_cert = /path/to/client/cert.pem ca_certs = /path/to/ca/cert.pem SecurityImpact DocImpact Implements bp: websocket-proxy-to-host-security Change-Id: I64859ad01120782fb17308aac3abb125597c3ea2 From major at mhtx.net Thu May 19 18:44:46 2016 From: major at mhtx.net (Major Hayden) Date: Thu, 19 May 2016 18:44:46 -0000 Subject: [Openstack-security] [Bug 1583744] [NEW] Security role docs need updates for Xenial/CentOS Message-ID: <20160519184446.8326.17404.malonedeb@soybean.canonical.com> Public bug reported: The security role now supports Xenial and CentOS, but the documentation now needs updates. ** Affects: openstack-ansible Importance: Low Assignee: Major Hayden (rackerhacker) Status: Confirmed ** Tags: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1583744 Title: Security role docs need updates for Xenial/CentOS Status in openstack-ansible: Confirmed Bug description: The security role now supports Xenial and CentOS, but the documentation now needs updates. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1583744/+subscriptions From major at mhtx.net Thu May 19 19:09:18 2016 From: major at mhtx.net (Major Hayden) Date: Thu, 19 May 2016 19:09:18 -0000 Subject: [Openstack-security] [Bug 1583752] [NEW] Security role doesn't handle nullok for CentOS properly (V-38497) Message-ID: <20160519190918.21523.53336.malonedeb@wampee.canonical.com> Public bug reported: In the checks for V-38497, the task looks for nullok_secure and removes it from the pam configuration. This works okay for Ubuntu, but it doesn't help with CentOS since it uses just 'nullok'. ** Affects: openstack-ansible Importance: Low Assignee: Major Hayden (rackerhacker) Status: New ** Tags: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1583752 Title: Security role doesn't handle nullok for CentOS properly (V-38497) Status in openstack-ansible: New Bug description: In the checks for V-38497, the task looks for nullok_secure and removes it from the pam configuration. This works okay for Ubuntu, but it doesn't help with CentOS since it uses just 'nullok'. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1583752/+subscriptions From 1583752 at bugs.launchpad.net Thu May 19 19:18:19 2016 From: 1583752 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 19 May 2016 19:18:19 -0000 Subject: [Openstack-security] [Bug 1583752] Re: Security role doesn't handle nullok for CentOS properly (V-38497) References: <20160519190918.21523.53336.malonedeb@wampee.canonical.com> Message-ID: <20160519191819.1018.27047.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/318888 ** Changed in: openstack-ansible Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1583752 Title: Security role doesn't handle nullok for CentOS properly (V-38497) Status in openstack-ansible: In Progress Bug description: In the checks for V-38497, the task looks for nullok_secure and removes it from the pam configuration. This works okay for Ubuntu, but it doesn't help with CentOS since it uses just 'nullok'. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1583752/+subscriptions From 1583744 at bugs.launchpad.net Thu May 19 19:39:42 2016 From: 1583744 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 19 May 2016 19:39:42 -0000 Subject: [Openstack-security] [Bug 1583744] Re: Security role docs need updates for Xenial/CentOS References: <20160519184446.8326.17404.malonedeb@soybean.canonical.com> Message-ID: <20160519193942.1051.42285.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/318905 ** Changed in: openstack-ansible Status: Confirmed => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1583744 Title: Security role docs need updates for Xenial/CentOS Status in openstack-ansible: In Progress Bug description: The security role now supports Xenial and CentOS, but the documentation now needs updates. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1583744/+subscriptions From major at mhtx.net Thu May 19 20:48:31 2016 From: major at mhtx.net (Major Hayden) Date: Thu, 19 May 2016 20:48:31 -0000 Subject: [Openstack-security] [Bug 1583788] [NEW] Security role should use pam_faillock for V-38501 on CentOS Message-ID: <20160519204832.823.4874.malonedeb@chaenomeles.canonical.com> Public bug reported: Ubuntu doesn't package pam_faillock, so fail2ban was used to satisfy the requirements in V-38501. CentOS 7 has pam_faillock and it should be used on CentOS 7 to more closely align with the STIG's requirements. ** Affects: openstack-ansible Importance: Wishlist Assignee: Major Hayden (rackerhacker) Status: New ** Tags: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1583788 Title: Security role should use pam_faillock for V-38501 on CentOS Status in openstack-ansible: New Bug description: Ubuntu doesn't package pam_faillock, so fail2ban was used to satisfy the requirements in V-38501. CentOS 7 has pam_faillock and it should be used on CentOS 7 to more closely align with the STIG's requirements. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1583788/+subscriptions From major at mhtx.net Thu May 19 21:30:08 2016 From: major at mhtx.net (Major Hayden) Date: Thu, 19 May 2016 21:30:08 -0000 Subject: [Openstack-security] [Bug 1583804] [NEW] Security role should require an email to receive root's mail Message-ID: <20160519213008.8116.80335.malonedeb@soybean.canonical.com> Public bug reported: V-38680 requires that someone must receive root's email. There is not a hard requirement at the moment to set security_root_forward_email prior to running the security hardening role. There should be a pre-flight check that ensures this value is set. ** Affects: openstack-ansible Importance: Wishlist Status: New ** Tags: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1583804 Title: Security role should require an email to receive root's mail Status in openstack-ansible: New Bug description: V-38680 requires that someone must receive root's email. There is not a hard requirement at the moment to set security_root_forward_email prior to running the security hardening role. There should be a pre- flight check that ensures this value is set. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1583804/+subscriptions From 1583744 at bugs.launchpad.net Thu May 19 21:38:47 2016 From: 1583744 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 19 May 2016 21:38:47 -0000 Subject: [Openstack-security] [Bug 1583744] Fix proposed to openstack-ansible-security (master) References: <20160519184446.8326.17404.malonedeb@soybean.canonical.com> Message-ID: <20160519213847.679.27199.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/318954 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1583744 Title: Security role docs need updates for Xenial/CentOS Status in openstack-ansible: In Progress Bug description: The security role now supports Xenial and CentOS, but the documentation now needs updates. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1583744/+subscriptions From major at mhtx.net Fri May 20 19:22:59 2016 From: major at mhtx.net (Major Hayden) Date: Fri, 20 May 2016 19:22:59 -0000 Subject: [Openstack-security] [Bug 1584187] [NEW] Security role should set audit rules for SELinux Message-ID: <20160520192300.511.16353.malonedeb@chaenomeles.canonical.com> Public bug reported: V-38541 requires that SELinux modifications are audited. This was configured for Ubuntu, but not for CentOS. ** Affects: openstack-ansible Importance: Low Assignee: Major Hayden (rackerhacker) Status: New ** Tags: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1584187 Title: Security role should set audit rules for SELinux Status in openstack-ansible: New Bug description: V-38541 requires that SELinux modifications are audited. This was configured for Ubuntu, but not for CentOS. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1584187/+subscriptions From major at mhtx.net Fri May 20 19:38:41 2016 From: major at mhtx.net (Major Hayden) Date: Fri, 20 May 2016 19:38:41 -0000 Subject: [Openstack-security] [Bug 1584191] [NEW] Security role should disable rdisc service on CentOS Message-ID: <20160520193841.9222.38896.malonedeb@gac.canonical.com> Public bug reported: V-38650 was skipped in Ubuntu since the rdisc daemon didn't exist in any packages. In CentOS, the iputils-sysvinit package contains the rdisc daemon and we should ensure that it is stopped if it exists. ** Affects: openstack-ansible Importance: Low Assignee: Major Hayden (rackerhacker) Status: New ** Tags: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1584191 Title: Security role should disable rdisc service on CentOS Status in openstack-ansible: New Bug description: V-38650 was skipped in Ubuntu since the rdisc daemon didn't exist in any packages. In CentOS, the iputils-sysvinit package contains the rdisc daemon and we should ensure that it is stopped if it exists. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1584191/+subscriptions From major at mhtx.net Fri May 20 19:44:48 2016 From: major at mhtx.net (Major Hayden) Date: Fri, 20 May 2016 19:44:48 -0000 Subject: [Openstack-security] [Bug 1584194] [NEW] Secure role should disable the netconsole service in CentOS Message-ID: <20160520194448.10380.52421.malonedeb@gac.canonical.com> Public bug reported: V-38672 requires that the netconsole service is disabled. This service doesn't exist on Ubuntu, and we're not checking for it in CentOS. ** Affects: openstack-ansible Importance: Low Assignee: Major Hayden (rackerhacker) Status: New ** Tags: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1584194 Title: Secure role should disable the netconsole service in CentOS Status in openstack-ansible: New Bug description: V-38672 requires that the netconsole service is disabled. This service doesn't exist on Ubuntu, and we're not checking for it in CentOS. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1584194/+subscriptions From major at mhtx.net Fri May 20 19:51:09 2016 From: major at mhtx.net (Major Hayden) Date: Fri, 20 May 2016 19:51:09 -0000 Subject: [Openstack-security] [Bug 1584196] [NEW] Security role should look for unlabeled devices Message-ID: <20160520195109.636.50703.malonedeb@chaenomeles.canonical.com> Public bug reported: V-51379 requires that no unlabeled devices exist on the system. This doesn't apply for AppArmor, so it was skipped in Ubuntu. However, these devices ought to be checked in CentOS. ** Affects: openstack-ansible Importance: Wishlist Assignee: Major Hayden (rackerhacker) Status: New ** Tags: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1584196 Title: Security role should look for unlabeled devices Status in openstack-ansible: New Bug description: V-51379 requires that no unlabeled devices exist on the system. This doesn't apply for AppArmor, so it was skipped in Ubuntu. However, these devices ought to be checked in CentOS. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1584196/+subscriptions From 1583744 at bugs.launchpad.net Fri May 20 19:52:44 2016 From: 1583744 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 20 May 2016 19:52:44 -0000 Subject: [Openstack-security] [Bug 1583744] Fix proposed to openstack-ansible-security (master) References: <20160519184446.8326.17404.malonedeb@soybean.canonical.com> Message-ID: <20160520195244.941.89853.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/319429 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1583744 Title: Security role docs need updates for Xenial/CentOS Status in openstack-ansible: In Progress Bug description: The security role now supports Xenial and CentOS, but the documentation now needs updates. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1583744/+subscriptions From 1584187 at bugs.launchpad.net Fri May 20 20:10:35 2016 From: 1584187 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 20 May 2016 20:10:35 -0000 Subject: [Openstack-security] [Bug 1584187] Re: Security role should set audit rules for SELinux References: <20160520192300.511.16353.malonedeb@chaenomeles.canonical.com> Message-ID: <20160520201035.1141.27557.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/319438 ** Changed in: openstack-ansible Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1584187 Title: Security role should set audit rules for SELinux Status in openstack-ansible: In Progress Bug description: V-38541 requires that SELinux modifications are audited. This was configured for Ubuntu, but not for CentOS. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1584187/+subscriptions From major at mhtx.net Fri May 20 20:18:43 2016 From: major at mhtx.net (Major Hayden) Date: Fri, 20 May 2016 20:18:43 -0000 Subject: [Openstack-security] [Bug 1584194] Re: Security role should disable the netconsole service in CentOS References: <20160520194448.10380.52421.malonedeb@gac.canonical.com> Message-ID: <20160520201843.863.52062.launchpad@chaenomeles.canonical.com> ** Summary changed: - Secure role should disable the netconsole service in CentOS + Security role should disable the netconsole service in CentOS -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1584194 Title: Security role should disable the netconsole service in CentOS Status in openstack-ansible: New Bug description: V-38672 requires that the netconsole service is disabled. This service doesn't exist on Ubuntu, and we're not checking for it in CentOS. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1584194/+subscriptions From 1584191 at bugs.launchpad.net Fri May 20 20:18:49 2016 From: 1584191 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 20 May 2016 20:18:49 -0000 Subject: [Openstack-security] [Bug 1584191] Re: Security role should disable rdisc service on CentOS References: <20160520193841.9222.38896.malonedeb@gac.canonical.com> Message-ID: <20160520201849.21455.72340.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/319442 ** Changed in: openstack-ansible Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1584191 Title: Security role should disable rdisc service on CentOS Status in openstack-ansible: In Progress Bug description: V-38650 was skipped in Ubuntu since the rdisc daemon didn't exist in any packages. In CentOS, the iputils-sysvinit package contains the rdisc daemon and we should ensure that it is stopped if it exists. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1584191/+subscriptions From 1584194 at bugs.launchpad.net Fri May 20 20:26:25 2016 From: 1584194 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 20 May 2016 20:26:25 -0000 Subject: [Openstack-security] [Bug 1584194] Re: Security role should disable the netconsole service in CentOS References: <20160520194448.10380.52421.malonedeb@gac.canonical.com> Message-ID: <20160520202627.9255.31836.launchpad@gac.canonical.com> ** Changed in: openstack-ansible Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1584194 Title: Security role should disable the netconsole service in CentOS Status in openstack-ansible: In Progress Bug description: V-38672 requires that the netconsole service is disabled. This service doesn't exist on Ubuntu, and we're not checking for it in CentOS. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1584194/+subscriptions From 1584196 at bugs.launchpad.net Fri May 20 20:41:40 2016 From: 1584196 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 20 May 2016 20:41:40 -0000 Subject: [Openstack-security] [Bug 1584196] Re: Security role should look for unlabeled devices References: <20160520195109.636.50703.malonedeb@chaenomeles.canonical.com> Message-ID: <20160520204140.9903.85842.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/319448 ** Changed in: openstack-ansible Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1584196 Title: Security role should look for unlabeled devices Status in openstack-ansible: In Progress Bug description: V-51379 requires that no unlabeled devices exist on the system. This doesn't apply for AppArmor, so it was skipped in Ubuntu. However, these devices ought to be checked in CentOS. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1584196/+subscriptions From major at mhtx.net Fri May 20 20:53:14 2016 From: major at mhtx.net (Major Hayden) Date: Fri, 20 May 2016 20:53:14 -0000 Subject: [Openstack-security] [Bug 1583804] Re: Security role should require an email to receive root's mail References: <20160519213008.8116.80335.malonedeb@soybean.canonical.com> Message-ID: <20160520205315.589.43943.launchpad@chaenomeles.canonical.com> ** Description changed: V-38680 requires that someone must receive root's email. There is not a hard requirement at the moment to set security_root_forward_email prior to running the security hardening role. There should be a pre-flight check that ensures this value is set. + + I'd like some more input on how we can handle this without halting the + playbook run since users might not understand that this is a required + configuration item. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1583804 Title: Security role should require an email to receive root's mail Status in openstack-ansible: New Bug description: V-38680 requires that someone must receive root's email. There is not a hard requirement at the moment to set security_root_forward_email prior to running the security hardening role. There should be a pre- flight check that ensures this value is set. I'd like some more input on how we can handle this without halting the playbook run since users might not understand that this is a required configuration item. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1583804/+subscriptions From gerrit2 at review.openstack.org Mon May 23 10:56:39 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 23 May 2016 10:56:39 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I3835d7364cc3c96c38c917fc0fb1674a11447954 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/271595 Log: commit cd8f575a6055194a6fce0f035d0251b46806a149 Author: Wilson Liu Date: Sat Jan 23 10:25:15 2016 +0800 Huawei: Mask chap password in log Users won't see the chap password shown in the log for safety consideration, so we will mask it in the log. SecurityImpact Closes-Bug: #1535706 Change-Id: I3835d7364cc3c96c38c917fc0fb1674a11447954 From gerrit2 at review.openstack.org Mon May 23 12:48:00 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 23 May 2016 12:48:00 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I3835d7364cc3c96c38c917fc0fb1674a11447954 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/271595 Log: commit ac0da6b215fd59291cb0e33b8433b3755fb26a7d Author: Wilson Liu Date: Sat Jan 23 10:25:15 2016 +0800 Huawei: Mask chap password in log Users won't see the chap password shown in the log for safety consideration, so we will mask it in the log. SecurityImpact Closes-Bug: #1535706 Change-Id: I3835d7364cc3c96c38c917fc0fb1674a11447954 From major at mhtx.net Mon May 23 20:15:22 2016 From: major at mhtx.net (Major Hayden) Date: Mon, 23 May 2016 20:15:22 -0000 Subject: [Openstack-security] [Bug 1584942] [NEW] Security role sets incorrect permissions on auditd logs Message-ID: <20160523201522.476.31063.malonedeb@chaenomeles.canonical.com> Public bug reported: The security role sets the permissions on all audit logs to 0400, but this is incorrect. The active log that is being written to should be set to 0600 and the rotated ones should be 0400. This causes auditd to fail on startup. ** Affects: openstack-ansible Importance: High Assignee: Major Hayden (rackerhacker) Status: New ** Tags: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1584942 Title: Security role sets incorrect permissions on auditd logs Status in openstack-ansible: New Bug description: The security role sets the permissions on all audit logs to 0400, but this is incorrect. The active log that is being written to should be set to 0600 and the rotated ones should be 0400. This causes auditd to fail on startup. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1584942/+subscriptions From 1584942 at bugs.launchpad.net Mon May 23 20:36:07 2016 From: 1584942 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 23 May 2016 20:36:07 -0000 Subject: [Openstack-security] [Bug 1584942] Re: Security role sets incorrect permissions on auditd logs References: <20160523201522.476.31063.malonedeb@chaenomeles.canonical.com> Message-ID: <20160523203607.21455.3847.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/320131 ** Changed in: openstack-ansible Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1584942 Title: Security role sets incorrect permissions on auditd logs Status in openstack-ansible: In Progress Bug description: The security role sets the permissions on all audit logs to 0400, but this is incorrect. The active log that is being written to should be set to 0600 and the rotated ones should be 0400. This causes auditd to fail on startup. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1584942/+subscriptions From 1582185 at bugs.launchpad.net Tue May 24 08:21:22 2016 From: 1582185 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 24 May 2016 08:21:22 -0000 Subject: [Openstack-security] [Bug 1582185] Change abandoned on neutron (master) References: <20160516111757.8981.38537.malonedeb@gac.canonical.com> Message-ID: <20160524082122.18171.19827.malone@soybean.canonical.com> Change abandoned by Zhengguang Ou (zhengguangou at gmail.com) on branch: master Review: https://review.openstack.org/317333 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1582185 Title: when vm detaches security group with remote_group_id, vm's ip address don't be deleted from ipset member. Status in neutron: Incomplete Bug description: There is default security group, and have been attached two vms, the security group as below: | 204844ae-6939-44d3-a375-1999cd44c942 | default | egress, IPv4 | | | | egress, IPv4, 22/tcp, remote_group_id: 204844ae-6939-44d3-a375-1999cd44c942 | | | | egress, IPv6 | | | | ingress, IPv4, 22/tcp | | | | ingress, IPv4, 3389/tcp | | | | ingress, IPv4, icmp, remote_ip_prefix: 0.0.0.0/0 | | | | ingress, IPv4, remote_group_id: 204844ae-6939-44d3-a375-1999cd44c942 | | | | ingress, IPv6, 22/tcp | | | | ingress, IPv6, 3389/tcp | | | | ingress, IPv6, icmp | | | | ingress, IPv6, remote_group_id: 204844ae-6939-44d3-a375-1999cd44c942 | [root at openstack ~(keystone_admin)]# nova list +--------------------------------------+-------+--------+------------+-------------+-------------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+-------+--------+------------+-------------+-------------------+ | 4558881d-2784-40b8-a0fc-a8238196ca47 | vm1 | ACTIVE | - | Running | dddd=172.16.0.9 | | e67ba1de-305d-4915-a2bc-bb24b0389546 | vm2 | ACTIVE | - | Running | test=192.168.12.6 | +--------------------------------------+-------+--------+------------+-------------+-------------------+ Reproduce: step 1: vm1 attaches the default security group step 2: vm2 attaches the default security group, we can see the ipset member: [root at openstack ~]# ipset list NETIPv4204844ae-6939-44d3-a Name: NETIPv4204844ae-6939-44d3-a Type: hash:net Revision: 3 Header: family inet hashsize 1024 maxelem 65536 Size in memory: 16880 References: 6 Members: 192.168.12.6 172.16.0.9 step3: vm2 detaches the default, now we can see "192.168.12.6" still over there: [root at openstack ~]# ipset list NETIPv4204844ae-6939-44d3-a Name: NETIPv4204844ae-6939-44d3-a Type: hash:net Revision: 3 Header: family inet hashsize 1024 maxelem 65536 Size in memory: 16880 References: 5 Members: 192.168.12.6 172.16.0.9 Expected: "192.168.12.6" should be removed from ipset member. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1582185/+subscriptions From 1584942 at bugs.launchpad.net Tue May 24 14:41:55 2016 From: 1584942 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 24 May 2016 14:41:55 -0000 Subject: [Openstack-security] [Bug 1584942] Re: Security role sets incorrect permissions on auditd logs References: <20160523201522.476.31063.malonedeb@chaenomeles.canonical.com> Message-ID: <20160524144155.27292.86305.malone@gac.canonical.com> Reviewed: https://review.openstack.org/320131 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=490d2f4bd8078c8550e0ce13ee282948c49e6945 Submitter: Jenkins Branch: master commit 490d2f4bd8078c8550e0ce13ee282948c49e6945 Author: Major Hayden Date: Mon May 23 16:02:36 2016 -0500 Fix auditd log permission bug The tasks for handling auditd log permissions incorrectly set all log files in /var/log/audit to 0400, which prevents auditd from writing to the active log file. This prevents auditd from starting and restarting. The task now removes any permissions explicitly disallowed by V-38498. Any files meeting/exceeding the STIG requirements will not be modified. Closes-bug: 1584942 Change-Id: I1bb2b91ae8a78b1f0304bd4ce0f9a774d65245bd ** Changed in: openstack-ansible Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1584942 Title: Security role sets incorrect permissions on auditd logs Status in openstack-ansible: Fix Released Bug description: The security role sets the permissions on all audit logs to 0400, but this is incorrect. The active log that is being written to should be set to 0600 and the rotated ones should be 0400. This causes auditd to fail on startup. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1584942/+subscriptions From 1584942 at bugs.launchpad.net Tue May 24 16:17:21 2016 From: 1584942 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 24 May 2016 16:17:21 -0000 Subject: [Openstack-security] [Bug 1584942] Fix proposed to openstack-ansible-security (stable/mitaka) References: <20160523201522.476.31063.malonedeb@chaenomeles.canonical.com> Message-ID: <20160524161721.22205.84472.malone@wampee.canonical.com> Fix proposed to branch: stable/mitaka Review: https://review.openstack.org/320559 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1584942 Title: Security role sets incorrect permissions on auditd logs Status in openstack-ansible: Fix Released Bug description: The security role sets the permissions on all audit logs to 0400, but this is incorrect. The active log that is being written to should be set to 0600 and the rotated ones should be 0400. This causes auditd to fail on startup. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1584942/+subscriptions From 1584942 at bugs.launchpad.net Tue May 24 16:17:38 2016 From: 1584942 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 24 May 2016 16:17:38 -0000 Subject: [Openstack-security] [Bug 1584942] Fix proposed to openstack-ansible-security (liberty) References: <20160523201522.476.31063.malonedeb@chaenomeles.canonical.com> Message-ID: <20160524161738.28295.75827.malone@gac.canonical.com> Fix proposed to branch: liberty Review: https://review.openstack.org/320560 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1584942 Title: Security role sets incorrect permissions on auditd logs Status in openstack-ansible: Fix Released Bug description: The security role sets the permissions on all audit logs to 0400, but this is incorrect. The active log that is being written to should be set to 0600 and the rotated ones should be 0400. This causes auditd to fail on startup. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1584942/+subscriptions From major at mhtx.net Tue May 24 19:53:44 2016 From: major at mhtx.net (Major Hayden) Date: Tue, 24 May 2016 19:53:44 -0000 Subject: [Openstack-security] [Bug 1585349] [NEW] Security role fails on unlocked accounts in Ansible 2.2 Message-ID: <20160524195344.25918.65100.malonedeb@chaenomeles.canonical.com> Public bug reported: The security role fails on the unlocked accounts check when using Ansible 2.2: TASK [openstack-ansible-security : debug] ************************************** ok: [logs.cloud-ci.ibmcis.com] => { "v38496_violations": "\n" } The tasks end up returning a non-empty violations list even though no unlocked accounts exist on the system. Thanks to phschwartz for reporting this in IRC. ** Affects: openstack-ansible Importance: Low Assignee: Major Hayden (rackerhacker) Status: In Progress ** Tags: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1585349 Title: Security role fails on unlocked accounts in Ansible 2.2 Status in openstack-ansible: In Progress Bug description: The security role fails on the unlocked accounts check when using Ansible 2.2: TASK [openstack-ansible-security : debug] ************************************** ok: [logs.cloud-ci.ibmcis.com] => { "v38496_violations": "\n" } The tasks end up returning a non-empty violations list even though no unlocked accounts exist on the system. Thanks to phschwartz for reporting this in IRC. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1585349/+subscriptions From 1585349 at bugs.launchpad.net Tue May 24 19:59:12 2016 From: 1585349 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 24 May 2016 19:59:12 -0000 Subject: [Openstack-security] [Bug 1585349] Re: Security role fails on unlocked accounts in Ansible 2.2 References: <20160524195344.25918.65100.malonedeb@chaenomeles.canonical.com> Message-ID: <20160524195913.25752.50525.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/320637 ** Changed in: openstack-ansible Status: Confirmed => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1585349 Title: Security role fails on unlocked accounts in Ansible 2.2 Status in openstack-ansible: In Progress Bug description: The security role fails on the unlocked accounts check when using Ansible 2.2: TASK [openstack-ansible-security : debug] ************************************** ok: [logs.cloud-ci.ibmcis.com] => { "v38496_violations": "\n" } The tasks end up returning a non-empty violations list even though no unlocked accounts exist on the system. Thanks to phschwartz for reporting this in IRC. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1585349/+subscriptions From 1583752 at bugs.launchpad.net Wed May 25 08:20:50 2016 From: 1583752 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 25 May 2016 08:20:50 -0000 Subject: [Openstack-security] [Bug 1583752] Re: Security role doesn't handle nullok for CentOS properly (V-38497) References: <20160519190918.21523.53336.malonedeb@wampee.canonical.com> Message-ID: <20160525082050.26031.14947.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/318888 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=a972b4f60ff27b856cb820a1cf4078cb11e01ccb Submitter: Jenkins Branch: master commit a972b4f60ff27b856cb820a1cf4078cb11e01ccb Author: Major Hayden Date: Mon May 23 13:18:32 2016 -0500 Fix null password auth in CentOS The task for V-38497 works well for Ubuntu, but CentOS uses a different string for enabling null password logins in PAM. This patch splits the existing task into two so that each case is handled properly. Closes-bug: 1583752 Change-Id: I4c3bde487308270d43b52eba183bb9137b4c4d6b ** Changed in: openstack-ansible Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1583752 Title: Security role doesn't handle nullok for CentOS properly (V-38497) Status in openstack-ansible: Fix Released Bug description: In the checks for V-38497, the task looks for nullok_secure and removes it from the pam configuration. This works okay for Ubuntu, but it doesn't help with CentOS since it uses just 'nullok'. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1583752/+subscriptions From 1584191 at bugs.launchpad.net Wed May 25 14:51:43 2016 From: 1584191 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 25 May 2016 14:51:43 -0000 Subject: [Openstack-security] [Bug 1584191] Re: Security role should disable rdisc service on CentOS References: <20160520193841.9222.38896.malonedeb@gac.canonical.com> Message-ID: <20160525145143.17521.72638.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/319442 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=2459cb4e07f52d652b240aeb74b547794e96cf61 Submitter: Jenkins Branch: master commit 2459cb4e07f52d652b240aeb74b547794e96cf61 Author: Major Hayden Date: Mon May 23 07:49:59 2016 -0500 Disable the rdisc service (if present) This patch checks for the rdisc service on a host and disables the service, if the service is installed. The service will be stopped immediately if it is found to be running. Documentation and release notes are included. Closes-bug: 1584191 Change-Id: Ieeb2d25ecf1920448701c33d4ea623d3f65becf6 ** Changed in: openstack-ansible Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1584191 Title: Security role should disable rdisc service on CentOS Status in openstack-ansible: Fix Released Bug description: V-38650 was skipped in Ubuntu since the rdisc daemon didn't exist in any packages. In CentOS, the iputils-sysvinit package contains the rdisc daemon and we should ensure that it is stopped if it exists. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1584191/+subscriptions From 1583744 at bugs.launchpad.net Wed May 25 15:53:24 2016 From: 1583744 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 25 May 2016 15:53:24 -0000 Subject: [Openstack-security] [Bug 1583744] Fix merged to openstack-ansible-security (master) References: <20160519184446.8326.17404.malonedeb@soybean.canonical.com> Message-ID: <20160525155324.28152.37013.malone@gac.canonical.com> Reviewed: https://review.openstack.org/319429 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=e954ff5c64fe4228903df740c387cbabeb385ffd Submitter: Jenkins Branch: master commit e954ff5c64fe4228903df740c387cbabeb385ffd Author: Major Hayden Date: Fri May 20 14:52:09 2016 -0500 Docs: Update dev notes for Cat 1 controls This patch updates the documentation for the developer notes associated with the Cat 1 (Low) controls applied by the security role. Partial-bug: 1583744 Change-Id: I19cab15d1bc7ce6e8604d63bf8184b9569207991 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1583744 Title: Security role docs need updates for Xenial/CentOS Status in openstack-ansible: In Progress Bug description: The security role now supports Xenial and CentOS, but the documentation now needs updates. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1583744/+subscriptions From 1584942 at bugs.launchpad.net Wed May 25 21:06:36 2016 From: 1584942 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 25 May 2016 21:06:36 -0000 Subject: [Openstack-security] [Bug 1584942] Re: Security role sets incorrect permissions on auditd logs References: <20160523201522.476.31063.malonedeb@chaenomeles.canonical.com> Message-ID: <20160525210636.22775.4509.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/320559 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=00ad8d3b571974d17028c84823ca62647a0e4b34 Submitter: Jenkins Branch: stable/mitaka commit 00ad8d3b571974d17028c84823ca62647a0e4b34 Author: Major Hayden Date: Mon May 23 16:02:36 2016 -0500 Fix auditd log permission bug The tasks for handling auditd log permissions incorrectly set all log files in /var/log/audit to 0400, which prevents auditd from writing to the active log file. This prevents auditd from starting and restarting. The task now removes any permissions explicitly disallowed by V-38498. Any files meeting/exceeding the STIG requirements will not be modified. This is a manual backport of I1bb2b91ae8a78b1f0304bd4ce0f9a774d65245bd from master. Closes-bug: 1584942 Change-Id: I1bb2b91ae8a78b1f0304bd4ce0f9a774d65245bd ** Tags added: in-stable-mitaka -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1584942 Title: Security role sets incorrect permissions on auditd logs Status in openstack-ansible: Fix Released Bug description: The security role sets the permissions on all audit logs to 0400, but this is incorrect. The active log that is being written to should be set to 0600 and the rotated ones should be 0400. This causes auditd to fail on startup. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1584942/+subscriptions From 1584194 at bugs.launchpad.net Wed May 25 21:39:56 2016 From: 1584194 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 25 May 2016 21:39:56 -0000 Subject: [Openstack-security] [Bug 1584194] Re: Security role should disable the netconsole service in CentOS References: <20160520194448.10380.52421.malonedeb@gac.canonical.com> Message-ID: <20160525213956.27325.66613.malone@gac.canonical.com> Reviewed: https://review.openstack.org/319445 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=3107e7cc9d637ceb592eae807a38769a7b4994c6 Submitter: Jenkins Branch: master commit 3107e7cc9d637ceb592eae807a38769a7b4994c6 Author: Major Hayden Date: Fri May 20 15:41:10 2016 -0500 Disable the netconsole service (if present) This patch checks for the netconsole service on a host and disables the service, if the service is installed. The service will be stopped immediately if it is found to be running. Documentation and release notes are included. Closes-bug: 1584194 Change-Id: If779af67c2a66e7b56d170f1f12744aef75ff27b ** Changed in: openstack-ansible Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1584194 Title: Security role should disable the netconsole service in CentOS Status in openstack-ansible: Fix Released Bug description: V-38672 requires that the netconsole service is disabled. This service doesn't exist on Ubuntu, and we're not checking for it in CentOS. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1584194/+subscriptions From 1583744 at bugs.launchpad.net Wed May 25 21:38:35 2016 From: 1583744 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 25 May 2016 21:38:35 -0000 Subject: [Openstack-security] [Bug 1583744] Fix merged to openstack-ansible-security (master) References: <20160519184446.8326.17404.malonedeb@soybean.canonical.com> Message-ID: <20160525213835.18249.58623.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/318954 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=a841e184dec7e4023e0ea3e963d1ac4edf4fe41a Submitter: Jenkins Branch: master commit a841e184dec7e4023e0ea3e963d1ac4edf4fe41a Author: Major Hayden Date: Thu May 19 16:37:53 2016 -0500 Docs: Update dev notes for Cat 2 controls This patch updates the documentation for the developer notes associated with the Cat 2 (Medium) controls applied by the security role. Partial-bug: 1583744 Change-Id: Ic342f33942521db009185585a21208a4688f6ed3 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1583744 Title: Security role docs need updates for Xenial/CentOS Status in openstack-ansible: In Progress Bug description: The security role now supports Xenial and CentOS, but the documentation now needs updates. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1583744/+subscriptions From doug at doughellmann.com Thu May 26 12:37:50 2016 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 26 May 2016 12:37:50 -0000 Subject: [Openstack-security] [Bug 1579914] Fix included in openstack/openstack-ansible-security 12.0.13 References: <20160509205442.981.10915.malonedeb@chaenomeles.canonical.com> Message-ID: <20160526123750.25752.83475.malone@chaenomeles.canonical.com> This issue was fixed in the openstack/openstack-ansible-security 12.0.13 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1579914 Title: Security role doesn't handle sshd_config with Match Status in openstack-ansible: Fix Released Bug description: The security role makes several changes to the sshd_config file, but it doesn't handle situations where the configuration file might end with Match stanzas. There cannot be any general configuration options after any Match stanzas in the configuration file. The role should: * Handle Match stanzas properly * Validate the sshd_config with each change To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1579914/+subscriptions From doug at doughellmann.com Thu May 26 12:37:35 2016 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 26 May 2016 12:37:35 -0000 Subject: [Openstack-security] [Bug 1568029] Fix included in openstack/openstack-ansible 12.0.13 References: <20160408161908.32065.20657.malonedeb@chaenomeles.canonical.com> Message-ID: <20160526123735.19337.11566.malone@soybean.canonical.com> This issue was fixed in the openstack/openstack-ansible 12.0.13 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1568029 Title: Security: Disable role during major version upgrades Status in openstack-ansible: Fix Released Bug description: Upgrading between major versions of OpenStack services, such as Kilo to Liberty, or Liberty to Mitaka, can be challenging. We should advise deployers to consider disabling the openstack-ansible-security role during an upgrade to reduce the domain of things to troubleshoot during an upgrade. This should be in the docs, the upgrade scripts, or both. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1568029/+subscriptions From vgridnev at mirantis.com Tue May 31 11:14:18 2016 From: vgridnev at mirantis.com (Vitaly Gridnev) Date: Tue, 31 May 2016 11:14:18 -0000 Subject: [Openstack-security] [Bug 1541122] Re: Vanilla plugin uses hardcoded password for Oozie MySQL database user References: <20160202222341.14647.37585.malonedeb@gac.canonical.com> Message-ID: <20160531111420.22666.2514.launchpad@wampee.canonical.com> ** Changed in: sahara Milestone: newton-1 => newton-2 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1541122 Title: Vanilla plugin uses hardcoded password for Oozie MySQL database user Status in OpenStack Security Advisory: Won't Fix Status in Sahara: In Progress Status in Sahara liberty series: Confirmed Status in Sahara mitaka series: In Progress Bug description: When deploying clusters with the vanilla plugin, the Oozie[1] application must be configured to use a database for storing data related to the scheduling, running, and processing of Hadoop jobs. Oozie is the primary scheduler for jobs entering the Hadoop ecosystem through the vanilla plugin. Sahara configures the credentials for Oozie to access its database, this can be seen in sahara/plugins/vanilla/hadoop2/oozie_helper.py [2]. These credentials are hardcoded, and use a weak password. An intruder with access to the nodes of a cluster that is created by sahara with the vanilla plugin will have access to the database that backs the Oozie installation. With this access, the intruder could change the operational effects of Oozie to produce results other than expected, for example inserting new jobs or altering configurations associated with currently running jobs. As sahara has ultimate control over the deployment and configuration of Oozie on nodes deployed in its clusters, this hardcoded password should be changed in favor of a random password that will be generated uniquely for each deployed cluster. Oozie uses the values associated with the configurations defined in [2] to create the credentials, this means that the change should be a matter of simply changing the source valueof the password for the Oozie user. [1]: https://oozie.apache.org/ [2]: https://github.com/openstack/sahara/blob/master/sahara/plugins/vanilla/hadoop2/oozie_helper.py#L41 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1541122/+subscriptions From vgridnev at mirantis.com Tue May 31 11:33:34 2016 From: vgridnev at mirantis.com (Vitaly Gridnev) Date: Tue, 31 May 2016 11:33:34 -0000 Subject: [Openstack-security] [Bug 1541122] Re: Vanilla plugin uses hardcoded password for Oozie MySQL database user References: <20160202222341.14647.37585.malonedeb@gac.canonical.com> Message-ID: <20160531113336.17591.78463.launchpad@soybean.canonical.com> ** Changed in: sahara Importance: Critical => High ** Changed in: sahara/liberty Importance: Critical => High ** Changed in: sahara/mitaka Importance: Critical => High -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1541122 Title: Vanilla plugin uses hardcoded password for Oozie MySQL database user Status in OpenStack Security Advisory: Won't Fix Status in Sahara: In Progress Status in Sahara liberty series: Confirmed Status in Sahara mitaka series: In Progress Bug description: When deploying clusters with the vanilla plugin, the Oozie[1] application must be configured to use a database for storing data related to the scheduling, running, and processing of Hadoop jobs. Oozie is the primary scheduler for jobs entering the Hadoop ecosystem through the vanilla plugin. Sahara configures the credentials for Oozie to access its database, this can be seen in sahara/plugins/vanilla/hadoop2/oozie_helper.py [2]. These credentials are hardcoded, and use a weak password. An intruder with access to the nodes of a cluster that is created by sahara with the vanilla plugin will have access to the database that backs the Oozie installation. With this access, the intruder could change the operational effects of Oozie to produce results other than expected, for example inserting new jobs or altering configurations associated with currently running jobs. As sahara has ultimate control over the deployment and configuration of Oozie on nodes deployed in its clusters, this hardcoded password should be changed in favor of a random password that will be generated uniquely for each deployed cluster. Oozie uses the values associated with the configurations defined in [2] to create the credentials, this means that the change should be a matter of simply changing the source valueof the password for the Oozie user. [1]: https://oozie.apache.org/ [2]: https://github.com/openstack/sahara/blob/master/sahara/plugins/vanilla/hadoop2/oozie_helper.py#L41 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1541122/+subscriptions From 1584942 at bugs.launchpad.net Tue May 31 17:36:10 2016 From: 1584942 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 31 May 2016 17:36:10 -0000 Subject: [Openstack-security] [Bug 1584942] Re: Security role sets incorrect permissions on auditd logs References: <20160523201522.476.31063.malonedeb@chaenomeles.canonical.com> Message-ID: <20160531173610.27261.46432.malone@gac.canonical.com> Reviewed: https://review.openstack.org/320560 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=991650505c65c9d52de6c0a55a73e9fd7881addf Submitter: Jenkins Branch: liberty commit 991650505c65c9d52de6c0a55a73e9fd7881addf Author: Major Hayden Date: Mon May 23 16:02:36 2016 -0500 Fix auditd log permission bug The tasks for handling auditd log permissions incorrectly set all log files in /var/log/audit to 0400, which prevents auditd from writing to the active log file. This prevents auditd from starting and restarting. The task now removes any permissions explicitly disallowed by V-38498. Any files meeting/exceeding the STIG requirements will not be modified. This is a manual backport of I1bb2b91ae8a78b1f0304bd4ce0f9a774d65245bd from master. Closes-bug: 1584942 Change-Id: I1bb2b91ae8a78b1f0304bd4ce0f9a774d65245bd ** Tags added: in-liberty -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1584942 Title: Security role sets incorrect permissions on auditd logs Status in openstack-ansible: Fix Released Bug description: The security role sets the permissions on all audit logs to 0400, but this is incorrect. The active log that is being written to should be set to 0600 and the rotated ones should be 0400. This causes auditd to fail on startup. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1584942/+subscriptions From 1585349 at bugs.launchpad.net Tue May 31 18:43:48 2016 From: 1585349 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 31 May 2016 18:43:48 -0000 Subject: [Openstack-security] [Bug 1585349] Re: Security role fails on unlocked accounts in Ansible 2.2 References: <20160524195344.25918.65100.malonedeb@chaenomeles.canonical.com> Message-ID: <20160531184348.22544.75054.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/320637 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=9fbe88ab28cf6b546325d4821e543e73b1a04324 Submitter: Jenkins Branch: master commit 9fbe88ab28cf6b546325d4821e543e73b1a04324 Author: Major Hayden Date: Tue May 24 14:53:59 2016 -0500 Fix unlocked account check on Ansible 2.2 The unlocked account check for V-34896 always fails in Ansible 2.2, even when there are no unlocked accounts on the system. This patch simplifies the jinja loop and rejects any empty lines. Closes-bug: 1585349 Change-Id: I11728e24f341ec696da3a761f02087266341cf2a ** Changed in: openstack-ansible Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1585349 Title: Security role fails on unlocked accounts in Ansible 2.2 Status in openstack-ansible: Fix Released Bug description: The security role fails on the unlocked accounts check when using Ansible 2.2: TASK [openstack-ansible-security : debug] ************************************** ok: [logs.cloud-ci.ibmcis.com] => { "v38496_violations": "\n" } The tasks end up returning a non-empty violations list even though no unlocked accounts exist on the system. Thanks to phschwartz for reporting this in IRC. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1585349/+subscriptions From 1585349 at bugs.launchpad.net Tue May 31 18:58:21 2016 From: 1585349 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 31 May 2016 18:58:21 -0000 Subject: [Openstack-security] [Bug 1585349] Fix proposed to openstack-ansible-security (stable/mitaka) References: <20160524195344.25918.65100.malonedeb@chaenomeles.canonical.com> Message-ID: <20160531185821.27092.29516.malone@gac.canonical.com> Fix proposed to branch: stable/mitaka Review: https://review.openstack.org/323536 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1585349 Title: Security role fails on unlocked accounts in Ansible 2.2 Status in openstack-ansible: Fix Released Bug description: The security role fails on the unlocked accounts check when using Ansible 2.2: TASK [openstack-ansible-security : debug] ************************************** ok: [logs.cloud-ci.ibmcis.com] => { "v38496_violations": "\n" } The tasks end up returning a non-empty violations list even though no unlocked accounts exist on the system. Thanks to phschwartz for reporting this in IRC. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1585349/+subscriptions From 1585349 at bugs.launchpad.net Tue May 31 18:59:51 2016 From: 1585349 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 31 May 2016 18:59:51 -0000 Subject: [Openstack-security] [Bug 1585349] Fix proposed to openstack-ansible-security (liberty) References: <20160524195344.25918.65100.malonedeb@chaenomeles.canonical.com> Message-ID: <20160531185951.26031.49279.malone@chaenomeles.canonical.com> Fix proposed to branch: liberty Review: https://review.openstack.org/323537 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1585349 Title: Security role fails on unlocked accounts in Ansible 2.2 Status in openstack-ansible: Fix Released Bug description: The security role fails on the unlocked accounts check when using Ansible 2.2: TASK [openstack-ansible-security : debug] ************************************** ok: [logs.cloud-ci.ibmcis.com] => { "v38496_violations": "\n" } The tasks end up returning a non-empty violations list even though no unlocked accounts exist on the system. Thanks to phschwartz for reporting this in IRC. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1585349/+subscriptions