From gerrit2 at review.openstack.org  Fri Jul  1 02:23:22 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 01 Jul 2016 02:23:22 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I3835d7364cc3c96c38c917fc0fb1674a11447954
Message-ID: <E1bIo70-000Pjz-1T@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/271595

Log:
commit b79fa8e438b7b40ea5716383d980c864dee78100
Author: Wilson Liu <liuxinguo at huawei.com>
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 doug at doughellmann.com  Tue Jul  5 14:33:26 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Tue, 05 Jul 2016 14:33:26 -0000
Subject: [Openstack-security] [Bug 1590916] Fix included in
 openstack/openstack-ansible-security 13.1.4
References: <20160609183045.31455.50670.malonedeb@soybean.canonical.com>
Message-ID: <20160705143326.30849.17931.malone@chaenomeles.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security 13.1.4
release.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1590916

Title:
  Running augenrules should trigger an auditd restart

Status in openstack-ansible:
  Fix Released

Bug description:
  The security role runs augenrules to create the main audit rules file
  whenever the rules template changes, but the handlers weren't set up
  to restart the audit daemon right after.  We should chain the handlers
  so that the augenrules handler will trigger a restart of auditd.

  This bug exists in master, mitaka, and liberty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1590916/+subscriptions



From doug at doughellmann.com  Tue Jul  5 14:33:24 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Tue, 05 Jul 2016 14:33:24 -0000
Subject: [Openstack-security] [Bug 1590911] Fix included in
 openstack/openstack-ansible-security 13.1.4
References: <20160609181317.31455.73339.malonedeb@soybean.canonical.com>
Message-ID: <20160705143324.30675.58357.malone@chaenomeles.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security 13.1.4
release.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1590911

Title:
  Security role audit rules should have key fields

Status in openstack-ansible:
  Fix Released

Bug description:
  The audit rules added by the security role should have a key field
  added so that it's easier to figure out which rule caused something to
  be audited.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1590911/+subscriptions



From doug at doughellmann.com  Tue Jul  5 14:33:28 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Tue, 05 Jul 2016 14:33:28 -0000
Subject: [Openstack-security] [Bug 1590086] Fix included in
 openstack/openstack-ansible-security 13.1.4
References: <20160607171245.24975.77161.malonedeb@gac.canonical.com>
Message-ID: <20160705143328.18142.29314.malone@wampee.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security 13.1.4
release.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1590086

Title:
  check_mode not set when using tags with security role

Status in openstack-ansible:
  Fix Released

Bug description:
  If a tag is provided with the security role in check mode, the
  check_mode variable is not set. This causes any tasks that depend on
  that variable to fail.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1590086/+subscriptions



From doug at doughellmann.com  Tue Jul  5 14:49:26 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Tue, 05 Jul 2016 14:49:26 -0000
Subject: [Openstack-security] [Bug 1590916] Fix included in
 openstack/openstack-ansible-security 12.0.16
References: <20160609183045.31455.50670.malonedeb@soybean.canonical.com>
Message-ID: <20160705144926.23996.64888.malone@gac.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security 12.0.16
release.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1590916

Title:
  Running augenrules should trigger an auditd restart

Status in openstack-ansible:
  Fix Released

Bug description:
  The security role runs augenrules to create the main audit rules file
  whenever the rules template changes, but the handlers weren't set up
  to restart the audit daemon right after.  We should chain the handlers
  so that the augenrules handler will trigger a restart of auditd.

  This bug exists in master, mitaka, and liberty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1590916/+subscriptions



From doug at doughellmann.com  Tue Jul  5 14:49:25 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Tue, 05 Jul 2016 14:49:25 -0000
Subject: [Openstack-security] [Bug 1590911] Fix included in
 openstack/openstack-ansible-security 12.0.16
References: <20160609181317.31455.73339.malonedeb@soybean.canonical.com>
Message-ID: <20160705144925.30466.56107.malone@chaenomeles.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security 12.0.16
release.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1590911

Title:
  Security role audit rules should have key fields

Status in openstack-ansible:
  Fix Released

Bug description:
  The audit rules added by the security role should have a key field
  added so that it's easier to figure out which rule caused something to
  be audited.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1590911/+subscriptions



From doug at doughellmann.com  Tue Jul  5 14:49:27 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Tue, 05 Jul 2016 14:49:27 -0000
Subject: [Openstack-security] [Bug 1590086] Fix included in
 openstack/openstack-ansible-security 12.0.16
References: <20160607171245.24975.77161.malonedeb@gac.canonical.com>
Message-ID: <20160705144927.18342.36299.malone@wampee.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security 12.0.16
release.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1590086

Title:
  check_mode not set when using tags with security role

Status in openstack-ansible:
  Fix Released

Bug description:
  If a tag is provided with the security role in check mode, the
  check_mode variable is not set. This causes any tasks that depend on
  that variable to fail.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1590086/+subscriptions



From 1595669 at bugs.launchpad.net  Tue Jul  5 16:47:28 2016
From: 1595669 at bugs.launchpad.net (Jean-Philippe Evrard)
Date: Tue, 05 Jul 2016 16:47:28 -0000
Subject: [Openstack-security] [Bug 1595669] Re: Separate documentation for
 STIGs that aren't in Ansible
References: <20160623190721.1729.88002.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160705164730.30602.39966.launchpad@chaenomeles.canonical.com>

** Changed in: openstack-ansible
       Status: New => Incomplete

** Changed in: openstack-ansible
       Status: Incomplete => Confirmed

** Changed in: openstack-ansible
   Importance: Undecided => Wishlist

** Changed in: openstack-ansible
     Assignee: (unassigned) => Major Hayden (rackerhacker)

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1595669

Title:
  Separate documentation for STIGs that aren't in Ansible

Status in openstack-ansible:
  Confirmed

Bug description:
  Create separate documentation for STIGs that aren't in Ansible

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1595669/+subscriptions



From 1595669 at bugs.launchpad.net  Tue Jul  5 17:44:03 2016
From: 1595669 at bugs.launchpad.net (Jean-Philippe Evrard)
Date: Tue, 05 Jul 2016 17:44:03 -0000
Subject: [Openstack-security] [Bug 1595669] Re: Separate documentation for
 STIGs that aren't in Ansible
References: <20160623190721.1729.88002.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160705174404.30373.79170.malone@chaenomeles.canonical.com>

For context, here is the conversation about this bug in our bug triage meeting:
http://eavesdrop.openstack.org/irclogs/%23openstack-ansible/%23openstack-ansible.2016-07-05.log.html#t2016-07-05T16:45:11

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1595669

Title:
  Separate documentation for STIGs that aren't in Ansible

Status in openstack-ansible:
  Confirmed

Bug description:
  Create separate documentation for STIGs that aren't in Ansible

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1595669/+subscriptions



From swann at oopss.org  Wed Jul  6 14:49:31 2016
From: swann at oopss.org (Swann Croiset)
Date: Wed, 06 Jul 2016 14:49:31 -0000
Subject: [Openstack-security] [Bug 1552182] Re: LMA toolchain should alert
 when packages upgrade is available
References: <20160302110924.1571.6249.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160706144933.30466.19270.launchpad@chaenomeles.canonical.com>

** Changed in: lma-toolchain
    Milestone: None => 1.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/1552182

Title:
  LMA toolchain should alert when packages upgrade is available

Status in LMA Toolchain:
  Confirmed

Bug description:
  Mainly for security reason, the LMA toolchain should alert when
  packages upgrade is highly recommended.

  For example, the package nagios-plugins-basic [0] provides  the
  command: check_apt

  ====================================================
  root at node-23:~#  /usr/lib/nagios/plugins/check_apt
  APT CRITICAL: 3 packages available for upgrade (2 critical updates). |available_upgrades=3;;;0 critical_updates=2;;;0

  root at node-23:~# apt-get upgrade
  Reading package lists... Done
  Building dependency tree       
  Reading state information... Done
  Calculating upgrade... Done
  The following packages will be upgraded:
    libssl1.0.0 openssl
  The following packages will be DOWNGRADED:
    python-urllib3
  2 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
  Need to get 1,443 kB of archives.
  After this operation, 124 kB of additional disk space will be used.
  Do you want to continue? [Y/n]
  ====================================================

  [0] http://packages.ubuntu.com/trusty/nagios-plugins-basic

To manage notifications about this bug go to:
https://bugs.launchpad.net/lma-toolchain/+bug/1552182/+subscriptions



From sean_mcginnis at dell.com  Wed Jul  6 14:57:14 2016
From: sean_mcginnis at dell.com (Sean McGinnis)
Date: Wed, 06 Jul 2016 14:57:14 -0000
Subject: [Openstack-security] [Bug 1158328] Re: passwords in config files
	stored in plaintext
References: <20130321141459.14228.40307.malonedeb@soybean.canonical.com>
Message-ID: <20160706145718.23845.42168.launchpad@gac.canonical.com>

** Changed in: cinder
       Status: Confirmed => 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/1158328

Title:
  passwords in config files stored in plaintext

Status in Cinder:
  Won't Fix
Status in OpenStack Compute (nova):
  Won't Fix

Bug description:
  The credentials for database conenctions and the keystone authtoken
  are stored in plaintext within the nova.conf and apipaste config
  files.

  These values should be encrypted.  A scheme similar to /etc/shadow
  would be great.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1158328/+subscriptions



From lbragstad at gmail.com  Wed Jul  6 16:54:50 2016
From: lbragstad at gmail.com (Lance Bragstad)
Date: Wed, 06 Jul 2016 16:54:50 -0000
Subject: [Openstack-security] [Bug 1576765] Re: Potential DOS: Keystone
	Extra Fields
References: <20160429154657.5758.65558.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160706165452.18741.46129.launchpad@wampee.canonical.com>

** Changed in: keystone
       Status: New => Triaged

** Changed in: keystone
   Importance: Undecided => Medium

-- 
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):
  Triaged
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 1585147 at bugs.launchpad.net  Wed Jul  6 19:07:44 2016
From: 1585147 at bugs.launchpad.net (Dolph Mathews)
Date: Wed, 06 Jul 2016 19:07:44 -0000
Subject: [Openstack-security] [Bug 1585147] Re: If http & https proxy is
 enabled on system then openstack services wont work as expected.
References: <20160524102754.22472.66093.malonedeb@wampee.canonical.com>
Message-ID: <20160706190744.23738.74661.malone@gac.canonical.com>

The 503 is coming from an intermediary proxy (likely whatever you're
using to implement HTTPS), not keystone (keystone is not capable of
returning a 503).

** Changed in: keystone
       Status: New => Invalid

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1585147

Title:
  If http & https proxy is enabled on system then openstack services
  wont work as expected.

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  Hi,

  i am trying to setup multi node using mitaka version. if i enable Http
  and https proxy on controller node then i was not able to create any
  openstack services. steps to reproduce the error.

  1. setup a controller node

  2. edit hostname and hosts and add all ip address

      > 10.0.0.10 controller

  3. setup proxy for http and https

      > export http_proxy='http://abc.com:8080/'
      > export https_proxy='http://abc.com:8080/'
      > export no_proxy='10.0.0.0/24'

  4. export all tokens

      > export OS_TOKEN=ADMIN_TOKEN
      > export OS_URL=http://controller:35357/v3
      > export OS_IDENTITY_API_VERSION=3

  
  5. now try creating keystone services. 
    
      > openstack service create --name keystone --description "OpenStack Identity" identity

  
     OUTPUT : Service Unavailable (HTTP 503)

  even i added no proxy to exclude controller ip from proxy but apache
  server is not serving eith proxy rules.

  6. if we curl os_url : it always redirects to proxy server page.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1585147/+subscriptions



From 1419577 at bugs.launchpad.net  Thu Jul  7 12:15:10 2016
From: 1419577 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 07 Jul 2016 12:15:10 -0000
Subject: [Openstack-security] [Bug 1419577] Re: when live-migrate failed,
 lun-id couldn't be rollback in havana
References: <20150209012956.20741.53343.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160707121510.23244.20940.malone@gac.canonical.com>

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

** Changed in: nova
       Status: Confirmed => In Progress

** Changed in: nova
     Assignee: (unassigned) => Lee Yarwood (lyarwood)

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1419577

Title:
  when live-migrate failed, lun-id couldn't be rollback in havana

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Hi, guys

  When live-migrate failed with error, lun-id of connection_info column in Nova's block_deivce_mapping table couldn't be rollback.
  and failed VM can have others volume.

  my test environment is following :

  Openstack Version : Havana ( 2013.2.3)
  Compute Node OS : 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
  Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2

  test step is :

  1) create 2 Compute node (host#1 and host#2)
  2) create 1 VM on host#1 (vm01)
  3) create 1 cinder volume (vol01)
  4) attach 1 volume to vm01 (/dev/vdb)
  5) live-migrate vm01 from host#1 to host#2
  6) live-migrate success
       - please check the mapper by using multipath command in host#1 (# multipath -ll), then you can find mapper is not deleted.
         and the status of devices is "failed faulty"
       - please check the lun-id of vol01
  7) Again, live-migrate vm01 from host#2 to host#1 (vm01 was migrated to host#2 at step 4)
  8) live-migrate fail
       - please check the mapper in host#1
       - please check the lun-id of vol01, then you can find the lun hav "two" igroups
       - please check the connection_info column in Nova's block_deivce_mapping table, then you can find lun-id couldn't be rollback

  This Bug is critical security issue because the failed VM can have
  others volume.

  and every backend storage of cinder-volume can have same problem
  because this is the bug of live-migration's rollback process.

  I suggest below methods to solve issue :

  1) when live-migrate is complete, nova should delete mapper devices at origin host
  2) when live-migrate is failed, nova should rollback lun-id in connection_info column
  3) when live-migrate is failed, cinder should delete the mapping between lun and host (Netapp : igroup, EMC : storage_group ...)
  4) when volume-attach is requested , cinder volume driver of vendors should make lun-id randomly for reduce of probability of mis-mapping

  please check this bug.

  Thank you.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1419577/+subscriptions



From vgridnev at mirantis.com  Thu Jul  7 21:40:26 2016
From: vgridnev at mirantis.com (Vitaly Gridnev)
Date: Thu, 07 Jul 2016 21:40:26 -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: <20160707214028.23996.32148.launchpad@gac.canonical.com>

** Changed in: sahara
    Milestone: newton-2 => newton-3

-- 
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

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 1188189 at bugs.launchpad.net  Wed Jul 13 02:19:22 2016
From: 1188189 at bugs.launchpad.net (Armando Migliaccio)
Date: Wed, 13 Jul 2016 02:19:22 -0000
Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL'
 communication fails to check certificates (use of HTTPSConnection)
References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com>
Message-ID: <20160713021927.23805.94915.launchpad@gac.canonical.com>

** Changed in: neutron
       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/1188189

Title:
  Some server-side 'SSL' communication fails to check certificates (use
  of HTTPSConnection)

Status in Cinder:
  Invalid
Status in OpenStack Identity (keystone):
  Fix Released
Status in neutron:
  Fix Released
Status in oslo.vmware:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released
Status in python-keystoneclient:
  Fix Released
Status in OpenStack Object Storage (swift):
  Invalid

Bug description:
  Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection
  objects. In Python 2.x those do not perform CA checks so client
  connections are vulnerable to MiM attacks.

  """
  The following files use httplib.HTTPSConnection :
  keystone/middleware/s3_token.py
  keystone/middleware/ec2_token.py
  keystone/common/bufferedhttp.py
  vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py

  AFAICT HTTPSConnection does not validate server certificates and
  should be avoided. This is fixed in Python 3, however in 2.X no
  validation occurs. I suspect this is also applicable to most OpenStack
  modules that make HTTPS client calls.

  Similar problems were found in ovirt:
  https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533)

  With solutions for ovirt:
  http://gerrit.ovirt.org/#/c/7209/
  http://gerrit.ovirt.org/#/c/7249/
  """

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions



From davanum at gmail.com  Fri Jul 15 11:55:34 2016
From: davanum at gmail.com (Davanum Srinivas (DIMS))
Date: Fri, 15 Jul 2016 11:55:34 -0000
Subject: [Openstack-security] [Bug 1586079] Fix included in openstack/murano
	3.0.0.0b2
References: <20160526151540.19337.24947.malonedeb@soybean.canonical.com>
Message-ID: <20160715115534.31087.20787.malone@chaenomeles.canonical.com>

This issue was fixed in the openstack/murano 3.0.0.0b2 development
milestone.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1586079

Title:
  YaqlYamlLoader inherits from YamlLoader

Status in Murano:
  Fix Released
Status in Murano kilo series:
  Won't Fix
Status in Murano liberty series:
  Fix Released
Status in Murano mitaka series:
  Fix Released
Status in Murano newton series:
  Fix Released

Bug description:
  YaqlYamlLoader inherits from YamlLoader, meaning that it is possible
  to use extended unsafe tags in yaml files
  http://pyyaml.org/wiki/PyYAMLDocumentation#YAMLtagsandPythontypes

  Both dashboard, engine/api seem to be vulnerable.

To manage notifications about this bug go to:
https://bugs.launchpad.net/murano/+bug/1586079/+subscriptions



From davanum at gmail.com  Fri Jul 15 11:56:46 2016
From: davanum at gmail.com (Davanum Srinivas (DIMS))
Date: Fri, 15 Jul 2016 11:56:46 -0000
Subject: [Openstack-security] [Bug 1586079] Fix included in
	openstack/murano-dashboard 3.0.0.0b2
References: <20160526151540.19337.24947.malonedeb@soybean.canonical.com>
Message-ID: <20160715115646.30637.75450.malone@chaenomeles.canonical.com>

This issue was fixed in the openstack/murano-dashboard 3.0.0.0b2
development milestone.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1586079

Title:
  YaqlYamlLoader inherits from YamlLoader

Status in Murano:
  Fix Released
Status in Murano kilo series:
  Won't Fix
Status in Murano liberty series:
  Fix Released
Status in Murano mitaka series:
  Fix Released
Status in Murano newton series:
  Fix Released

Bug description:
  YaqlYamlLoader inherits from YamlLoader, meaning that it is possible
  to use extended unsafe tags in yaml files
  http://pyyaml.org/wiki/PyYAMLDocumentation#YAMLtagsandPythontypes

  Both dashboard, engine/api seem to be vulnerable.

To manage notifications about this bug go to:
https://bugs.launchpad.net/murano/+bug/1586079/+subscriptions



From gerrit2 at review.openstack.org  Mon Jul 18 14:18:15 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 18 Jul 2016 14:18:15 +0000
Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review
 request change I1dafd2e590535c29b1d91a3b9094cee1b71826f6
Message-ID: <E1bP9N9-000PAP-04@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/343654

Log:
commit 2edf8ef8f75a6fe1ea41a0a13ca9feed576027fe
Author: Dane Fichter <dane.fichter at jhuapl.edu>
Date:   Mon Jul 18 10:06:53 2016 -0400

    Add image verification spec for Ocata
    
    This change adds the previously approved spec for
    Nova support of Glance image signature verification.
    Since certificate validation functionality still needs
    to be integrated into Nova, we are re-proposing this spec
    for Ocata.
    
    SecurityImpact
    DocImpact
    
    Implements: blueprint nova-support-image-signing
    
    Change-Id: I1dafd2e590535c29b1d91a3b9094cee1b71826f6
    Previously-approved: mitaka (Ia8e7fcc21d7c15e480facbe30af88cdce2d73159)




From 1604042 at bugs.launchpad.net  Mon Jul 18 15:54:47 2016
From: 1604042 at bugs.launchpad.net (Jean-Philippe Evrard)
Date: Mon, 18 Jul 2016 15:54:47 -0000
Subject: [Openstack-security] [Bug 1604042] Re: service name should be
 chronyd not chrony in V-38620 - Synchronize system clock (enable chrony)
References: <20160718152344.16364.62999.malonedeb@soybean.canonical.com>
Message-ID: <20160718155447.8059.15746.malone@wampee.canonical.com>

Chrony service name is not part of the distribution variable.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1604042

Title:
  service name should be chronyd not chrony in V-38620 - Synchronize
  system clock (enable chrony)

Status in openstack-ansible:
  New

Bug description:
  service name should be chronyd not chrony for V-38620 (Centos 7)

  openstack/openstack-ansible-security:

  diff --git a/tasks/misc.yml b/tasks/misc.yml
  index 733aa4b..c26af06 100644
  --- a/tasks/misc.yml
  +++ b/tasks/misc.yml
  @@ -109,7 +109,7 @@

   - name: V-38620 - Synchronize system clock (enable chrony)
     service:
  -    name: chrony
  +    name: chronyd
       state: started
       enabled: yes
     when: not check_mode

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1604042/+subscriptions



From edmondsw at us.ibm.com  Mon Jul 18 19:21:21 2016
From: edmondsw at us.ibm.com (Matthew Edmonds)
Date: Mon, 18 Jul 2016 19:21:21 -0000
Subject: [Openstack-security] [Bug 1197459] Re: noVNC contains the session
 token in URL and insecurely sets the session cookie
References: <20130703161152.14968.85936.malonedeb@gac.canonical.com>
Message-ID: <20160718192121.16132.21562.malone@gac.canonical.com>

@sdague, It is a well-accepted security statement that you should never
pass secrets in query parameters. Maybe how to fix it is opinion, but
not that there is a problem here.

You don't have to have a MitM or XSS to exploit this. Query parameters
are stored in browser history, so launching a session from a shared
computer also leads to exposure. Access to a web cache also equals
exposure. Etc.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1197459

Title:
  noVNC contains the session token in URL and insecurely sets the
  session cookie

Status in OpenStack Compute (nova):
  Opinion
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  The VNC Console connection in Nova works by having the user connect to
  the API which returns a URL such as:
  https://example.com:443/?token=abc Where the token has a TTL which is
  then used to create a session from a WebSocket. However, URL's should
  not contain sensitive information such as session tokens with a TTL
  since URL's can be leaked through proxy logs or other types of attacks
  such as Cross-Site Scripting. Additionally, due to the session cookie
  being set with JavaScript it cannot securely be set to HttpOnly nor is
  it set with the Secure flag making it further susceptible to Cross-
  Site Scripting attacks or leakage through a non-SSL connection. To
  limit the exposure of the token being leaked through the URL the
  returned token from the API should be of a one-time use and only used
  as an authentication token in order to obtain a session. The session
  cookie should be set by a Web Service instead of the client in order
  to securely set the cookie with the HttpOnly flag to be set in
  addition to setting the Secure flag.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1197459/+subscriptions



From dmccowan at cisco.com  Mon Jul 18 19:44:58 2016
From: dmccowan at cisco.com (Dave McCowan)
Date: Mon, 18 Jul 2016 19:44:58 -0000
Subject: [Openstack-security] [Bug 1197459] Re: noVNC contains the session
 token in URL and insecurely sets the session cookie
References: <20130703161152.14968.85936.malonedeb@gac.canonical.com>
Message-ID: <20160718194500.22716.91468.launchpad@chaenomeles.canonical.com>

** Changed in: nova
     Assignee: Dave McCowan (dave-mccowan) => (unassigned)

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1197459

Title:
  noVNC contains the session token in URL and insecurely sets the
  session cookie

Status in OpenStack Compute (nova):
  Opinion
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  The VNC Console connection in Nova works by having the user connect to
  the API which returns a URL such as:
  https://example.com:443/?token=abc Where the token has a TTL which is
  then used to create a session from a WebSocket. However, URL's should
  not contain sensitive information such as session tokens with a TTL
  since URL's can be leaked through proxy logs or other types of attacks
  such as Cross-Site Scripting. Additionally, due to the session cookie
  being set with JavaScript it cannot securely be set to HttpOnly nor is
  it set with the Secure flag making it further susceptible to Cross-
  Site Scripting attacks or leakage through a non-SSL connection. To
  limit the exposure of the token being leaked through the URL the
  returned token from the API should be of a one-time use and only used
  as an authentication token in order to obtain a session. The session
  cookie should be set by a Web Service instead of the client in order
  to securely set the cookie with the HttpOnly flag to be set in
  addition to setting the Secure flag.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1197459/+subscriptions



From major at mhtx.net  Tue Jul 19 14:39:05 2016
From: major at mhtx.net (Major Hayden)
Date: Tue, 19 Jul 2016 14:39:05 -0000
Subject: [Openstack-security] [Bug 1604042] Re: service name should be
 chronyd not chrony in V-38620 - Synchronize system clock (enable chrony)
References: <20160718152344.16364.62999.malonedeb@soybean.canonical.com>
Message-ID: <20160719143905.5892.96521.malone@wampee.canonical.com>

I can confirm that this bug is valid:

[root at centos-osas-test openstack-ansible-security]# systemctl status chronyd
● chronyd.service - NTP client/server
   Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2016-07-19 14:37:55 UTC; 46s ago
  Process: 20363 ExecStartPost=/usr/libexec/chrony-helper update-daemon (code=exited, status=0/SUCCESS)
  Process: 20359 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 20361 (chronyd)
   CGroup: /system.slice/chronyd.service
           └─20361 /usr/sbin/chronyd

Jul 19 14:37:55 centos-osas-test systemd[1]: Starting NTP client/server...
Jul 19 14:37:55 centos-osas-test chronyd[20361]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH)
Jul 19 14:37:55 centos-osas-test chronyd[20361]: Frequency -0.748 +/- 1.430 ppm read from /var/lib/chrony/drift
Jul 19 14:37:55 centos-osas-test systemd[1]: Started NTP client/server.
Jul 19 14:38:02 centos-osas-test chronyd[20361]: Selected source 64.79.107.43
[root at centos-osas-test openstack-ansible-security]# systemctl status chronyc
● chronyc.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1604042

Title:
  service name should be chronyd not chrony in V-38620 - Synchronize
  system clock (enable chrony)

Status in openstack-ansible:
  In Progress

Bug description:
  service name should be chronyd not chrony for V-38620 (Centos 7)

  openstack/openstack-ansible-security:

  diff --git a/tasks/misc.yml b/tasks/misc.yml
  index 733aa4b..c26af06 100644
  --- a/tasks/misc.yml
  +++ b/tasks/misc.yml
  @@ -109,7 +109,7 @@

   - name: V-38620 - Synchronize system clock (enable chrony)
     service:
  -    name: chrony
  +    name: chronyd
       state: started
       enabled: yes
     when: not check_mode

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1604042/+subscriptions



From major at mhtx.net  Tue Jul 19 14:39:24 2016
From: major at mhtx.net (Major Hayden)
Date: Tue, 19 Jul 2016 14:39:24 -0000
Subject: [Openstack-security] [Bug 1604042] Re: service name should be
 chronyd not chrony in V-38620 - Synchronize system clock (enable chrony)
References: <20160718152344.16364.62999.malonedeb@soybean.canonical.com>
Message-ID: <20160719143924.4889.18184.malone@wampee.canonical.com>

Sorry, the last part of that paste should have been:

[root at centos-osas-test openstack-ansible-security]# systemctl status chrony
● chrony.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1604042

Title:
  service name should be chronyd not chrony in V-38620 - Synchronize
  system clock (enable chrony)

Status in openstack-ansible:
  In Progress

Bug description:
  service name should be chronyd not chrony for V-38620 (Centos 7)

  openstack/openstack-ansible-security:

  diff --git a/tasks/misc.yml b/tasks/misc.yml
  index 733aa4b..c26af06 100644
  --- a/tasks/misc.yml
  +++ b/tasks/misc.yml
  @@ -109,7 +109,7 @@

   - name: V-38620 - Synchronize system clock (enable chrony)
     service:
  -    name: chrony
  +    name: chronyd
       state: started
       enabled: yes
     when: not check_mode

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1604042/+subscriptions



From 1604042 at bugs.launchpad.net  Tue Jul 19 14:42:43 2016
From: 1604042 at bugs.launchpad.net (Jean-Philippe Evrard)
Date: Tue, 19 Jul 2016 14:42:43 -0000
Subject: [Openstack-security] [Bug 1604042] Re: service name should be
 chronyd not chrony in V-38620 - Synchronize system clock (enable chrony)
References: <20160718152344.16364.62999.malonedeb@soybean.canonical.com>
Message-ID: <20160719144244.4313.39062.launchpad@chaenomeles.canonical.com>

** Changed in: openstack-ansible
     Assignee: (unassigned) => Jean-Philippe Evrard (jean-philippe-evrard)

** Changed in: openstack-ansible
       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/1604042

Title:
  service name should be chronyd not chrony in V-38620 - Synchronize
  system clock (enable chrony)

Status in openstack-ansible:
  In Progress

Bug description:
  service name should be chronyd not chrony for V-38620 (Centos 7)

  openstack/openstack-ansible-security:

  diff --git a/tasks/misc.yml b/tasks/misc.yml
  index 733aa4b..c26af06 100644
  --- a/tasks/misc.yml
  +++ b/tasks/misc.yml
  @@ -109,7 +109,7 @@

   - name: V-38620 - Synchronize system clock (enable chrony)
     service:
  -    name: chrony
  +    name: chronyd
       state: started
       enabled: yes
     when: not check_mode

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1604042/+subscriptions



From 1604042 at bugs.launchpad.net  Tue Jul 19 14:43:13 2016
From: 1604042 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 19 Jul 2016 14:43:13 -0000
Subject: [Openstack-security] [Bug 1604042] Re: service name should be
 chronyd not chrony in V-38620 - Synchronize system clock (enable chrony)
References: <20160718152344.16364.62999.malonedeb@soybean.canonical.com>
Message-ID: <20160719144313.489.16157.malone@gac.canonical.com>

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

** 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/1604042

Title:
  service name should be chronyd not chrony in V-38620 - Synchronize
  system clock (enable chrony)

Status in openstack-ansible:
  In Progress

Bug description:
  service name should be chronyd not chrony for V-38620 (Centos 7)

  openstack/openstack-ansible-security:

  diff --git a/tasks/misc.yml b/tasks/misc.yml
  index 733aa4b..c26af06 100644
  --- a/tasks/misc.yml
  +++ b/tasks/misc.yml
  @@ -109,7 +109,7 @@

   - name: V-38620 - Synchronize system clock (enable chrony)
     service:
  -    name: chrony
  +    name: chronyd
       state: started
       enabled: yes
     when: not check_mode

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1604042/+subscriptions



From 1604042 at bugs.launchpad.net  Wed Jul 20 19:01:19 2016
From: 1604042 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 20 Jul 2016 19:01:19 -0000
Subject: [Openstack-security] [Bug 1604042] Re: service name should be
 chronyd not chrony in V-38620 - Synchronize system clock (enable chrony)
References: <20160718152344.16364.62999.malonedeb@soybean.canonical.com>
Message-ID: <20160720190119.532.34544.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/344278
Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=b5b92c1abe8f68124639bb241bb9e1076ac2b1a0
Submitter: Jenkins
Branch:    master

commit b5b92c1abe8f68124639bb241bb9e1076ac2b1a0
Author: Jean-Philippe Evrard <jean-philippe.evrard at rackspace.co.uk>
Date:   Tue Jul 19 15:42:49 2016 +0100

    Fix chrony daemon name for rh derivatives
    
    RH/Centos 7 uses chronyd instead of chrony as service name.
    
    Closes-Bug: 1604042
    
    Change-Id: I69fbba7ea2d7c108f51d36b9fd4ed8cf547c517b
    Signed-off-by: Jean-Philippe Evrard <jean-philippe.evrard at rackspace.co.uk>


** 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/1604042

Title:
  service name should be chronyd not chrony in V-38620 - Synchronize
  system clock (enable chrony)

Status in openstack-ansible:
  Fix Released

Bug description:
  service name should be chronyd not chrony for V-38620 (Centos 7)

  openstack/openstack-ansible-security:

  diff --git a/tasks/misc.yml b/tasks/misc.yml
  index 733aa4b..c26af06 100644
  --- a/tasks/misc.yml
  +++ b/tasks/misc.yml
  @@ -109,7 +109,7 @@

   - name: V-38620 - Synchronize system clock (enable chrony)
     service:
  -    name: chrony
  +    name: chronyd
       state: started
       enabled: yes
     when: not check_mode

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1604042/+subscriptions



From gerrit2 at review.openstack.org  Thu Jul 21 17:09:39 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 21 Jul 2016 17:09:39 +0000
Subject: [Openstack-security] [openstack/barbican-specs] SecurityImpact
 review request change I02054d80f68f38145b399909d60db80a4d91c1ba
Message-ID: <E1bQHTf-000FJh-2G@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/263972

Log:
commit 1261e068843909d957f9de4667ab3decf8ab0f3f
Author: Arun Kant <arun.kant at hpe.com>
Date:   Tue Jan 5 16:37:53 2016 -0800

    Adding spec for supporting multiple secret store backends
    
    Updated patch to clarify review comments and correct typos.
    Moving spec from mitaka to newton directory.
    Added field to capture crypto_plugin name in addition to secret store plugin
    name. This is done as both software only and pkcs11 plugin uses database
    (store_crypto) as storage backend. Difference is in crypto plugin used
    (simple crypto vs p11_crypto).
    
    APIImpact
    SecurityImpact
    
    Change-Id: I02054d80f68f38145b399909d60db80a4d91c1ba




From gerrit2 at review.openstack.org  Thu Jul 21 21:50:14 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 21 Jul 2016 21:50:14 +0000
Subject: [Openstack-security] [openstack/barbican-specs] SecurityImpact
 review request change I02054d80f68f38145b399909d60db80a4d91c1ba
Message-ID: <E1bQLrC-0005du-3g@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/263972

Log:
commit 7c1e2657977cbe27a4aca1868b99d5b577b9dbc4
Author: Arun Kant <arun.kant at hpe.com>
Date:   Tue Jan 5 16:37:53 2016 -0800

    Adding spec for supporting multiple secret store backends
    
    Updated patch to clarify review comments and correct typos.
    Moving spec from mitaka to newton directory.
    Added field to capture crypto_plugin name in addition to secret store plugin
    name. This is done as both software only and pkcs11 plugin uses database
    (store_crypto) as storage backend. Difference is in crypto plugin used
    (simple crypto vs p11_crypto).
    
    APIImpact
    SecurityImpact
    
    Change-Id: I02054d80f68f38145b399909d60db80a4d91c1ba




From 1605914 at bugs.launchpad.net  Sat Jul 23 18:22:11 2016
From: 1605914 at bugs.launchpad.net (Turbo Fredriksson)
Date: Sat, 23 Jul 2016 18:22:11 -0000
Subject: [Openstack-security] [Bug 1605914] [NEW] Hard coded security group
Message-ID: <20160723182211.8674.89923.malonedeb@soybean.canonical.com>

Public bug reported:

"trove create" also creates a security group, with hard coded values.
Some of which is not what I want/need - especially the 'allow
everything' rule!

Please allow to specify existing SG(s) (preferably plural) on either the
command line (preferably), or in the datastore/datastore_version
configuration. Or possibly in the datastore section in trove*.conf.

** Affects: trove
     Importance: Undecided
         Status: New


** Tags: configuration group security

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1605914

Title:
  Hard coded security group

Status in OpenStack DBaaS (Trove):
  New

Bug description:
  "trove create" also creates a security group, with hard coded values.
  Some of which is not what I want/need - especially the 'allow
  everything' rule!

  Please allow to specify existing SG(s) (preferably plural) on either
  the command line (preferably), or in the datastore/datastore_version
  configuration. Or possibly in the datastore section in trove*.conf.

To manage notifications about this bug go to:
https://bugs.launchpad.net/trove/+bug/1605914/+subscriptions



From 1605914 at bugs.launchpad.net  Sat Jul 23 20:17:04 2016
From: 1605914 at bugs.launchpad.net (Amrith)
Date: Sat, 23 Jul 2016 20:17:04 -0000
Subject: [Openstack-security] [Bug 1605914] Re: Hard coded security group
References: <20160723182211.8674.89923.malonedeb@soybean.canonical.com>
Message-ID: <20160723201706.413.49876.launchpad@gac.canonical.com>

** Changed in: trove
       Status: New => Confirmed

** Changed in: trove
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1605914

Title:
  Hard coded security group

Status in OpenStack DBaaS (Trove):
  Confirmed

Bug description:
  "trove create" also creates a security group, with hard coded values.
  Some of which is not what I want/need - especially the 'allow
  everything' rule!

  Please allow to specify existing SG(s) (preferably plural) on either
  the command line (preferably), or in the datastore/datastore_version
  configuration. Or possibly in the datastore section in trove*.conf.

To manage notifications about this bug go to:
https://bugs.launchpad.net/trove/+bug/1605914/+subscriptions



From doug at doughellmann.com  Thu Jul 28 18:48:42 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Thu, 28 Jul 2016 18:48:42 -0000
Subject: [Openstack-security] [Bug 1568029] Fix included in
	openstack/openstack-ansible 14.0.0.0b2
References: <20160408161908.32065.20657.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160728184842.11793.85890.malone@gac.canonical.com>

This issue was fixed in the openstack/openstack-ansible 14.0.0.0b2
development milestone.

-- 
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 doug at doughellmann.com  Thu Jul 28 18:48:47 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Thu, 28 Jul 2016 18:48:47 -0000
Subject: [Openstack-security] [Bug 1568029] Fix included in
	openstack/openstack-ansible 14.0.0.0b2
References: <20160408161908.32065.20657.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160728184847.5898.59684.malone@chaenomeles.canonical.com>

This issue was fixed in the openstack/openstack-ansible 14.0.0.0b2
development milestone.

-- 
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 doug at doughellmann.com  Thu Jul 28 18:51:00 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Thu, 28 Jul 2016 18:51:00 -0000
Subject: [Openstack-security] [Bug 1604042] Fix included in
 openstack/openstack-ansible-security 14.0.0.0b2
References: <20160718152344.16364.62999.malonedeb@soybean.canonical.com>
Message-ID: <20160728185100.11655.52948.malone@gac.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security
14.0.0.0b2 development milestone.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1604042

Title:
  service name should be chronyd not chrony in V-38620 - Synchronize
  system clock (enable chrony)

Status in openstack-ansible:
  Fix Released

Bug description:
  service name should be chronyd not chrony for V-38620 (Centos 7)

  openstack/openstack-ansible-security:

  diff --git a/tasks/misc.yml b/tasks/misc.yml
  index 733aa4b..c26af06 100644
  --- a/tasks/misc.yml
  +++ b/tasks/misc.yml
  @@ -109,7 +109,7 @@

   - name: V-38620 - Synchronize system clock (enable chrony)
     service:
  -    name: chrony
  +    name: chronyd
       state: started
       enabled: yes
     when: not check_mode

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1604042/+subscriptions



From doug at doughellmann.com  Thu Jul 28 18:51:03 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Thu, 28 Jul 2016 18:51:03 -0000
Subject: [Openstack-security] [Bug 1590916] Fix included in
 openstack/openstack-ansible-security 14.0.0.0b2
References: <20160609183045.31455.50670.malonedeb@soybean.canonical.com>
Message-ID: <20160728185103.17340.82007.malone@wampee.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security
14.0.0.0b2 development milestone.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1590916

Title:
  Running augenrules should trigger an auditd restart

Status in openstack-ansible:
  Fix Released

Bug description:
  The security role runs augenrules to create the main audit rules file
  whenever the rules template changes, but the handlers weren't set up
  to restart the audit daemon right after.  We should chain the handlers
  so that the augenrules handler will trigger a restart of auditd.

  This bug exists in master, mitaka, and liberty.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1590916/+subscriptions



From doug at doughellmann.com  Thu Jul 28 18:51:05 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Thu, 28 Jul 2016 18:51:05 -0000
Subject: [Openstack-security] [Bug 1590911] Fix included in
 openstack/openstack-ansible-security 14.0.0.0b2
References: <20160609181317.31455.73339.malonedeb@soybean.canonical.com>
Message-ID: <20160728185105.31980.15164.malone@soybean.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security
14.0.0.0b2 development milestone.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1590911

Title:
  Security role audit rules should have key fields

Status in openstack-ansible:
  Fix Released

Bug description:
  The audit rules added by the security role should have a key field
  added so that it's easier to figure out which rule caused something to
  be audited.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1590911/+subscriptions



From doug at doughellmann.com  Thu Jul 28 18:51:06 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Thu, 28 Jul 2016 18:51:06 -0000
Subject: [Openstack-security] [Bug 1590102] Fix included in
 openstack/openstack-ansible-security 14.0.0.0b2
References: <20160607181557.11891.33821.malonedeb@wampee.canonical.com>
Message-ID: <20160728185106.17305.9347.malone@wampee.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security
14.0.0.0b2 development milestone.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1590102

Title:
  "V-38579 - Bootloader configuration files must be owned by root" task
  fails when running ansible standalone in checkmode

Status in openstack-ansible:
  Fix Released

Bug description:
  When running openstack-ansible-security in standalone mode on Redhat
  7.2 the bootloaded configuration files being owned by root check
  fails.  See below for error output.

  Command run:
  ansible-playbook security.yml --check --tags cat2

  Output:
  TASK: [security | V-38579 - Bootloader configuration files must be owned by root] *** 
  fatal: [172.31.255.21] => error while evaluating conditional: grub_cfg.stat.exists
  fatal: [172.31.255.20] => error while evaluating conditional: grub_cfg.stat.exists
  fatal: [172.31.255.24] => error while evaluating conditional: grub_cfg.stat.exists
  fatal: [172.31.255.18] => error while evaluating conditional: grub_cfg.stat.exists
  fatal: [172.31.255.15] => error while evaluating conditional: grub_cfg.stat.exists
  fatal: [172.31.255.16] => error while evaluating conditional: grub_cfg.stat.exists

  FATAL: all hosts have already failed -- aborting

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1590102/+subscriptions



From doug at doughellmann.com  Thu Jul 28 18:51:08 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Thu, 28 Jul 2016 18:51:08 -0000
Subject: [Openstack-security] [Bug 1590086] Fix included in
 openstack/openstack-ansible-security 14.0.0.0b2
References: <20160607171245.24975.77161.malonedeb@gac.canonical.com>
Message-ID: <20160728185108.17305.52999.malone@wampee.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security
14.0.0.0b2 development milestone.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1590086

Title:
  check_mode not set when using tags with security role

Status in openstack-ansible:
  Fix Released

Bug description:
  If a tag is provided with the security role in check mode, the
  check_mode variable is not set. This causes any tasks that depend on
  that variable to fail.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1590086/+subscriptions



From doug at doughellmann.com  Thu Jul 28 18:51:01 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Thu, 28 Jul 2016 18:51:01 -0000
Subject: [Openstack-security] [Bug 1588544] Fix included in
 openstack/openstack-ansible-security 14.0.0.0b2
References: <20160602215527.19591.65378.malonedeb@wampee.canonical.com>
Message-ID: <20160728185101.5898.73663.malone@chaenomeles.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security
14.0.0.0b2 development milestone.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1588544

Title:
  RHEL7 Support for ansible security

Status in openstack-ansible:
  Fix Released

Bug description:
  I am attempting to take the latest openstack-ansible-security role and
  run standalone checks against RHEL 7.2 and I am finding that the often
  used method to exclude items when a --check is executed "when: not
  check_mode" fails and causes and exit.  There are some cases where I
  have been able to get round this with ignore_errors: yes however that
  is not a solution.

  
  TASK: [security | V-38637 - Contents of auditd package must be verified] ****** 
  fatal: [172.31.255.20] => error while evaluating conditional: not check_mode
  fatal: [172.31.255.21] => error while evaluating conditional: not check_mode
  fatal: [172.31.255.18] => error while evaluating conditional: not check_mode
  fatal: [172.31.255.15] => error while evaluating conditional: not check_mode
  fatal: [172.31.255.11] => error while evaluating conditional: not check_mode
  fatal: [172.31.255.12] => error while evaluating conditional: not check_mode
  fatal: [172.31.255.13] => error while evaluating conditional: not check_mode
  fatal: [172.31.255.24] => error while evaluating conditional: not check_mode
  fatal: [172.31.255.16] => error while evaluating conditional: not check_mode

  FATAL: all hosts have already failed -- aborting

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-ansible/+bug/1588544/+subscriptions



From edmondsw at us.ibm.com  Fri Jul 29 20:46:03 2016
From: edmondsw at us.ibm.com (Matthew Edmonds)
Date: Fri, 29 Jul 2016 20:46:03 -0000
Subject: [Openstack-security] [Bug 1197459] Re: noVNC contains the session
 token in URL and insecurely sets the session cookie
References: <20130703161152.14968.85936.malonedeb@gac.canonical.com>
Message-ID: <20160729204603.20475.85166.malone@wampee.canonical.com>

This is what AppScan (a dynamic security scanning product) says about
this kind of issue:

Query Parameter in SSL Request
Threat Classification: Information Leakage
Causes: Query parameters were passed over SSL, and may contain sensitive information
Security Risks: It may be possible to steal sensitive data such as credit card numbers, social security numbers etc. that are sent unencrypted
CWE: 598
X-Force: 52845

References:
Financial Privacy: The Gramm-Leach Bliley Act, https://www.ftc.gov/tips-advice/business-center/privacy-and-security/gramm-leach-bliley-act
Health Insurance Portability and Accountability Act (HIPAA), http://www.hhs.gov/hipaa/index.html
Sarbanes-Oxley Act, https://www.sec.gov/spotlight/sarbanes-oxley.htm
California SB1386, http://info.sen.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.html

Technical Description:
During the application test, it was detected that a request, which was sent over SSL, contained parameters that were transmitted in the Query part of an HTTP request.
When sending requests, the browser's history can be used to reveal the URLs, which contain the query parameter names and values.
Due to the sensitivity of encrypted requests, it is suggested to use HTTP POST (without parameters in the URL string) when possible, in order to avoid the disclosure of URLs and parameter values to others.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1197459

Title:
  noVNC contains the session token in URL and insecurely sets the
  session cookie

Status in OpenStack Compute (nova):
  Opinion
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  The VNC Console connection in Nova works by having the user connect to
  the API which returns a URL such as:
  https://example.com:443/?token=abc Where the token has a TTL which is
  then used to create a session from a WebSocket. However, URL's should
  not contain sensitive information such as session tokens with a TTL
  since URL's can be leaked through proxy logs or other types of attacks
  such as Cross-Site Scripting. Additionally, due to the session cookie
  being set with JavaScript it cannot securely be set to HttpOnly nor is
  it set with the Secure flag making it further susceptible to Cross-
  Site Scripting attacks or leakage through a non-SSL connection. To
  limit the exposure of the token being leaked through the URL the
  returned token from the API should be of a one-time use and only used
  as an authentication token in order to obtain a session. The session
  cookie should be set by a Web Service instead of the client in order
  to securely set the cookie with the HttpOnly flag to be set in
  addition to setting the Secure flag.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1197459/+subscriptions



From fungi at yuggoth.org  Sat Jul 30 00:42:22 2016
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Sat, 30 Jul 2016 00:42:22 -0000
Subject: [Openstack-security] [Bug 1197459] Re: noVNC contains the session
 token in URL and insecurely sets the session cookie
References: <20130703161152.14968.85936.malonedeb@gac.canonical.com>
Message-ID: <20160730004222.16574.12219.malone@chaenomeles.canonical.com>

I still maintain it's a security hardening opportunity. Someone would
need access to your browser history _and_ an opportunity to use it
before the token expires, so not a gaping hole but still potentially
worth fixing in a future release.

Nova devs however seem to feel this isn't worth fixing at all, hence the
"opinion" state on their bugtask. You could try submitting a fix to
Gerrit for it, but there's no guarantee it'll be met with much urgency
from them (or ever even reviewed at all).

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1197459

Title:
  noVNC contains the session token in URL and insecurely sets the
  session cookie

Status in OpenStack Compute (nova):
  Opinion
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  The VNC Console connection in Nova works by having the user connect to
  the API which returns a URL such as:
  https://example.com:443/?token=abc Where the token has a TTL which is
  then used to create a session from a WebSocket. However, URL's should
  not contain sensitive information such as session tokens with a TTL
  since URL's can be leaked through proxy logs or other types of attacks
  such as Cross-Site Scripting. Additionally, due to the session cookie
  being set with JavaScript it cannot securely be set to HttpOnly nor is
  it set with the Secure flag making it further susceptible to Cross-
  Site Scripting attacks or leakage through a non-SSL connection. To
  limit the exposure of the token being leaked through the URL the
  returned token from the API should be of a one-time use and only used
  as an authentication token in order to obtain a session. The session
  cookie should be set by a Web Service instead of the client in order
  to securely set the cookie with the HttpOnly flag to be set in
  addition to setting the Secure flag.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1197459/+subscriptions