From 1584187 at bugs.launchpad.net  Wed Jun  1 09:29:43 2016
From: 1584187 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 01 Jun 2016 09:29:43 -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: <20160601092944.18249.57856.malone@soybean.canonical.com>

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

commit 7b313ee1bc6c300869ce557d7ab8e3ddc17b2333
Author: Major Hayden <major at mhtx.net>
Date:   Wed May 25 11:26:56 2016 -0500

    Adding audit rule for SELinux policy modifications
    
    This patch fixes the auditd rules template so that AppArmor and SELinux
    policy modifications are logged, depending on which Linux distribution
    is in use. The security_audit_apparmor_changes variable has been renamed
    to security_audit_mac_changes to be more generic.
    
    Documentation updates and a release note are included.
    
    Closes-bug: 1584187
    
    Change-Id: I0955e2cb8a05af4afd36aaca518322a9df6d1ff7


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

Title:
  Security role should set audit rules for SELinux

Status in openstack-ansible:
  Fix Released

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 1585349 at bugs.launchpad.net  Wed Jun  1 12:44:46 2016
From: 1585349 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 01 Jun 2016 12:44:46 -0000
Subject: [Openstack-security] [Bug 1585349] Change abandoned on
 openstack-ansible-security (stable/mitaka)
References: <20160524195344.25918.65100.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160601124446.30008.96018.malone@chaenomeles.canonical.com>

Change abandoned by Major Hayden (major at mhtx.net) on branch: stable/mitaka
Review: https://review.openstack.org/323536
Reason: Most of the Ansible 2.x users will be using the master (Newton) branch of the security role anyway.

-- 
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  Wed Jun  1 12:44:51 2016
From: 1585349 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 01 Jun 2016 12:44:51 -0000
Subject: [Openstack-security] [Bug 1585349] Change abandoned on
	openstack-ansible-security (liberty)
References: <20160524195344.25918.65100.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160601124451.6070.53038.malone@wampee.canonical.com>

Change abandoned by Major Hayden (major at mhtx.net) on branch: liberty
Review: https://review.openstack.org/323537
Reason: Most of the Ansible 2.x users will be using the master (Newton) branch of the security role anyway.

-- 
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 thierry.carrez+lp at gmail.com  Wed Jun  1 15:56:35 2016
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 01 Jun 2016 15:56:35 -0000
Subject: [Openstack-security] [Bug 1516031] Fix included in openstack/glance
	13.0.0.0b1
References: <20151113142716.4469.80964.malonedeb@gac.canonical.com>
Message-ID: <20160601155635.1269.28106.malone@wampee.canonical.com>

This issue was fixed in the openstack/glance 13.0.0.0b1 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/1516031

Title:
  Use of MD5 in OpenStack Glance image signature (CVE-2015-8234)

Status in Glance:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  This have been reported by Daniel P. Berrange:
  "
  In the OpenStack Liberty release, the Glance project added support for image signature verification.

  http://specs.openstack.org/openstack/glance-specs/specs/liberty/image-
  signing-and-verification-support.html

  The verification code was added in the following git commit

  https://github.com/openstack/glance/commit/484ef1b40b738c87adb203bba6107ddb4b04ff6e

  
  Unfortunately the design of this signature verification method is flawed by design.

  The generalized approach to creating signatures of content is to apply
  a hash to the content and then encrypt it in some manner. Consider
  that the signature is defined to use hash=sha256 and cipher=rsa we can
  describe the signature computation as

  signature = rsa(sha256(content))

  In the case of verifying a disk image, the content we care about
  verifying is the complete disk image file. Unfortunately, the glance
  specification chose *not* to compute the signature against the disk
  image file. Glance already had an MD5 checksum calculated for the disk
  image file, so they instead chose to compute the signature against the
  MD5 checksum instead. ie glance is running

  signature = rsa(sha256(md5(disk-image-content)))

  This degrades the security of the system to that of the weakest hash,
  which is obviously MD5 here.

  The code where glance verifies the signature is in the
  glance/locations.py, the 'set_data' method where is does

   result = signature_utils.verify_signature(
   self.context, checksum, self.image.extra_properties)
   if result:
   LOG.info(_LI("Successfully verified signature for image %s"),
   self.image.image_id)

  The 'checksum' variable is populate by the glance_store driver, but it
  is hardcoded to always be md5 in all current glance storage backends:

   $ git grep hashlib glance_store/_drivers/ | grep checksum
   glance_store/_drivers/filesystem.py: checksum = hashlib.md5()
   glance_store/_drivers/rbd.py: checksum = hashlib.md5()
   glance_store/_drivers/s3.py: checksum = hashlib.md5()
   glance_store/_drivers/s3.py: checksum = hashlib.md5()
   glance_store/_drivers/sheepdog.py: checksum = hashlib.md5()
   glance_store/_drivers/swift/store.py: checksum =
   hashlib.md5()
   glance_store/_drivers/vmware_datastore.py: self.checksum =
   hashlib.md5()

  
  Since we will soon be shipping OpenStack Liberty release, we need to at least give a security notice to alert our customers to the fact that the signature verification is cryptographically weak/broken. IMHO, it quite likely deserves a CVE though

  NB, this is public knowledge as I first became aware of this flawed
  design in comments / discussion on a public specification proposed to
  implement the same approach in the Nova project.

  My suggested way to fix this is to simply abandon the current impl and
  re-do it such that it directly computes the signature against  the
  disk image, and does not use the existing md5 checksum in any way.

  Regards,
  Daniel
  "

  Mailing list thread for Nova impl: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079348.html
  Nova Spec: https://review.openstack.org/#/c/188874/

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



From 1583744 at bugs.launchpad.net  Wed Jun  1 16:40:52 2016
From: 1583744 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 01 Jun 2016 16:40:52 -0000
Subject: [Openstack-security] [Bug 1583744] Fix merged to
	openstack-ansible-security (master)
References: <20160519184446.8326.17404.malonedeb@soybean.canonical.com>
Message-ID: <20160601164052.692.48712.malone@wampee.canonical.com>

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

commit 32ce2246371faebf0d910f70e7ec230e5d2c1313
Author: Major Hayden <major at mhtx.net>
Date:   Thu May 19 15:06:57 2016 -0500

    Docs: Update dev notes for Cat 3 controls
    
    This patch updates the documentation for the developer notes associated
    with the Cat 3 (High) controls applied by the security role.
    
    Partial-bug: 1583744
    
    Change-Id: Ia7dad9e8d1871cfa6d0408c329d6f771704e8d96

-- 
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 1584196 at bugs.launchpad.net  Wed Jun  1 20:53:12 2016
From: 1584196 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 01 Jun 2016 20:53:12 -0000
Subject: [Openstack-security] [Bug 1584196] Re: Security role should look
	for unlabeled devices
References: <20160520195109.636.50703.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160601205312.29189.37590.malone@gac.canonical.com>

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

commit bf28fdfe90fe5a16c57f5c4c18cff9510bed2423
Author: Major Hayden <major at mhtx.net>
Date:   Wed Jun 1 13:22:12 2016 -0500

    Search for unlabeled device files
    
    The checks for V-51379 didn't apply for Ubuntu and they were
    unintentionally skipped in CentOS after the multi-distro work
    was completed.
    
    This patch adds a search for unlabeled device files on CentOS 7 systems
    and halts the playbook if an unlabeled device is found. This is a very
    rare occurrence.
    
    Documentation updates and release notes are provided.
    
    Closes-bug: 1584196
    
    Change-Id: Iba4be3bc5fa607685e3b4eeefda35f93894c7f28


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

Title:
  Security role should look for unlabeled devices

Status in openstack-ansible:
  Fix Released

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 davanum at gmail.com  Thu Jun  2 19:34:39 2016
From: davanum at gmail.com (Davanum Srinivas (DIMS))
Date: Thu, 02 Jun 2016 19:34:39 -0000
Subject: [Openstack-security] [Bug 1561796] Fix included in openstack/nova
	14.0.0.0b1
References: <20160325000544.30735.22681.malonedeb@gac.canonical.com>
Message-ID: <20160602193439.12769.16156.malone@soybean.canonical.com>

This issue was fixed in the openstack/nova 14.0.0.0b1 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/1561796

Title:
  ironic driver does not support ssl cafile

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Even though Ironic's python client supports SSL encrypted connections
  to the ironic service, and securing intra-service connections is a
  recommended practice, the nova.virt.Ironic driver currently lacks an
  option to specify a custom CA Certificate for validating the SSL
  connection to the Ironic service.

  On the other hand, other OpenStack services which Nova connects to
  (eg, Glance, Neutron...) have support for this via a service-specific
  "cafile" config option.

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



From davanum at gmail.com  Thu Jun  2 19:32:38 2016
From: davanum at gmail.com (Davanum Srinivas (DIMS))
Date: Thu, 02 Jun 2016 19:32:38 -0000
Subject: [Openstack-security] [Bug 1483132] Fix included in openstack/nova
	14.0.0.0b1
References: <20150810064713.19114.43085.malonedeb@wampee.canonical.com>
Message-ID: <20160602193238.6908.76153.malone@chaenomeles.canonical.com>

This issue was fixed in the openstack/nova 14.0.0.0b1 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/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 davanum at gmail.com  Thu Jun  2 20:10:44 2016
From: davanum at gmail.com (Davanum Srinivas (DIMS))
Date: Thu, 02 Jun 2016 20:10:44 -0000
Subject: [Openstack-security] [Bug 1579914] Fix included in
 openstack/openstack-ansible-security 13.1.2
References: <20160509205442.981.10915.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160602201045.19490.44642.malone@wampee.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security 13.1.2
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 vgridnev at mirantis.com  Fri Jun  3 09:31:40 2016
From: vgridnev at mirantis.com (Vitaly Gridnev)
Date: Fri, 03 Jun 2016 09:31:40 -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: <20160603093140.12110.29983.launchpad@soybean.canonical.com>

** No longer affects: sahara/liberty

-- 
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 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 major at mhtx.net  Fri Jun  3 16:58:17 2016
From: major at mhtx.net (Major Hayden)
Date: Fri, 03 Jun 2016 16:58:17 -0000
Subject: [Openstack-security] [Bug 1588544] Re: RHEL7 Support for ansible
	security
References: <20160602215527.19591.65378.malonedeb@wampee.canonical.com>
Message-ID: <20160603165817.16828.82154.launchpad@gac.canonical.com>

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

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

** Tags added: security

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

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 1588544 at bugs.launchpad.net  Fri Jun  3 17:27:17 2016
From: 1588544 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 03 Jun 2016 17:27:17 -0000
Subject: [Openstack-security] [Bug 1588544] Re: RHEL7 Support for ansible
	security
References: <20160602215527.19591.65378.malonedeb@wampee.canonical.com>
Message-ID: <20160603172717.6863.30004.malone@chaenomeles.canonical.com>

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

** Changed in: openstack-ansible
       Status: Confirmed => In Progress

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

Title:
  RHEL7 Support for ansible security

Status in openstack-ansible:
  In Progress

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 major at mhtx.net  Fri Jun  3 18:24:01 2016
From: major at mhtx.net (Major Hayden)
Date: Fri, 03 Jun 2016 18:24:01 -0000
Subject: [Openstack-security] [Bug 1588544] Re: RHEL7 Support for ansible
	security
References: <20160602215527.19591.65378.malonedeb@wampee.canonical.com>
Message-ID: <20160603182401.16642.718.malone@gac.canonical.com>

The functional mode should be fixed by
https://review.openstack.org/325421 in RHEL 7.

As for the check mode, that should be fixed by
https://review.openstack.org/#/c/325376/.

-- 
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:
  In Progress

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 vgridnev at mirantis.com  Fri Jun  3 18:34:14 2016
From: vgridnev at mirantis.com (Vitaly Gridnev)
Date: Fri, 03 Jun 2016 18:34:14 -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: <20160603183415.16569.76094.launchpad@gac.canonical.com>

** Changed in: sahara/mitaka
       Status: In Progress => 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:
  Won't Fix
Status in Sahara:
  In Progress
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 major at mhtx.net  Tue Jun  7 17:12:45 2016
From: major at mhtx.net (Major Hayden)
Date: Tue, 07 Jun 2016 17:12:45 -0000
Subject: [Openstack-security] [Bug 1590086] [NEW] check_mode not set when
 using tags with security role
Message-ID: <20160607171245.24975.77161.malonedeb@gac.canonical.com>

Public bug reported:

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.

** Affects: openstack-ansible
     Importance: High
     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/1590086

Title:
  check_mode not set when using tags with security role

Status in openstack-ansible:
  In Progress

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 1590086 at bugs.launchpad.net  Tue Jun  7 17:19:09 2016
From: 1590086 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 07 Jun 2016 17:19:09 -0000
Subject: [Openstack-security] [Bug 1590086] Re: check_mode not set when
 using tags with security role
References: <20160607171245.24975.77161.malonedeb@gac.canonical.com>
Message-ID: <20160607171909.2401.76810.malone@chaenomeles.canonical.com>

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

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

Title:
  check_mode not set when using tags with security role

Status in openstack-ansible:
  In Progress

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 major at mhtx.net  Tue Jun  7 18:25:59 2016
From: major at mhtx.net (Major Hayden)
Date: Tue, 07 Jun 2016 18:25:59 -0000
Subject: [Openstack-security] [Bug 1590102] Re: "V-38579 - Bootloader
 configuration files must be owned by root" task fails when running ansible
 standalone in checkmode
References: <20160607181557.11891.33821.malonedeb@wampee.canonical.com>
Message-ID: <20160607182559.24741.1744.malone@gac.canonical.com>

Thanks for tackling this one, Mark! :)

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

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

** Changed in: openstack-ansible
     Assignee: (unassigned) => Mark Hooper (hoopernet)

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

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 1590102 at bugs.launchpad.net  Tue Jun  7 19:48:19 2016
From: 1590102 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 07 Jun 2016 19:48:19 -0000
Subject: [Openstack-security] [Bug 1590102] Re: "V-38579 - Bootloader
 configuration files must be owned by root" task fails when running ansible
 standalone in checkmode
References: <20160607181557.11891.33821.malonedeb@wampee.canonical.com>
Message-ID: <20160607194821.11603.89868.launchpad@wampee.canonical.com>

** Changed in: openstack-ansible
       Status: Confirmed => In Progress

** Changed in: openstack-ansible
     Assignee: Mark Hooper (hoopernet) => 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/1590102

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

Status in openstack-ansible:
  In Progress

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 1590102 at bugs.launchpad.net  Wed Jun  8 10:05:41 2016
From: 1590102 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 08 Jun 2016 10:05:41 -0000
Subject: [Openstack-security] [Bug 1590102] Re: "V-38579 - Bootloader
 configuration files must be owned by root" task fails when running ansible
 standalone in checkmode
References: <20160607181557.11891.33821.malonedeb@wampee.canonical.com>
Message-ID: <20160608100541.31308.70473.malone@soybean.canonical.com>

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

commit 03d436f86403d5635759ed4dcfc2d36567aeca20
Author: Mark Hooper <hoopernet at gmail.com>
Date:   Tue Jun 7 14:03:04 2016 -0500

    Fix grub configuration file path in RHEL/CentOS 7
    
    CentOS and RHEL 7 both use /boot/grub2/grub.cfg, but the tasks in the
    security role expect it to be in /boot/grub/grub.cfg. This patch
    adds a variable for the grub configuration file path.
    
    Closes-bug: 1590102
    
    Change-Id: I724d6eb3b716bd9b0006d0d2e5ad201481d52e59


** 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/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  Wed Jun  8 21:19:58 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Wed, 08 Jun 2016 21:19:58 -0000
Subject: [Openstack-security] [Bug 1532317] Fix included in openstack/murano
	2015.1.1
References: <20160108202404.8643.13925.malonedeb@wampee.canonical.com>
Message-ID: <20160608211958.25149.11892.malone@gac.canonical.com>

This issue was fixed in the openstack/murano 2015.1.1 release.

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

Title:
  Only ingress rules are supported in security groups

Status in Murano:
  Fix Released
Status in Murano kilo series:
  Fix Released
Status in Murano liberty series:
  Fix Released
Status in Murano mitaka series:
  Fix Released

Bug description:
  There is no way to specify in which direction security rule should be
  applied, only ingress is supported. Also there should be an optional
  key in existing parameter specifying rule IP protocol version
  (IPv4/IPv6)


  https://github.com/openstack/murano/blob/master/meta/io.murano/Classes/system/NeutronSecurityGroupManager.yaml#L56
  https://github.com/openstack/heat/blob/stable/kilo/heat/engine/resources/openstack/neutron/security_group.py#L50

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



From doug at doughellmann.com  Wed Jun  8 21:20:32 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Wed, 08 Jun 2016 21:20:32 -0000
Subject: [Openstack-security] [Bug 1472331] Fix included in openstack/murano
	2015.1.1
References: <20150707162751.20498.27948.malonedeb@soybean.canonical.com>
Message-ID: <20160608212032.31275.21807.malone@soybean.canonical.com>

This issue was fixed in the openstack/murano 2015.1.1 release.

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

Title:
  Trust id is not hidden in logs

Status in Murano:
  Fix Released
Status in Murano kilo series:
  Fix Committed

Bug description:
  When murano creates trustes and operates with data, contains it, the
  value of trust is not hidden:

   "SystemData": {"TrustId": "d5f1261a5a4f482d9c65a01bd385255b"}},
  "token": "*** SANITIZED ***",

  Need to use *** like it's done with token

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



From vgridnev at mirantis.com  Wed Jun  8 21:45:51 2016
From: vgridnev at mirantis.com (Vitaly Gridnev)
Date: Wed, 08 Jun 2016 21:45:51 -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: <20160608214551.31647.33899.launchpad@soybean.canonical.com>

** No longer affects: sahara/mitaka

-- 
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 1590086 at bugs.launchpad.net  Thu Jun  9 03:26:05 2016
From: 1590086 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 09 Jun 2016 03:26:05 -0000
Subject: [Openstack-security] [Bug 1590086] Re: check_mode not set when
 using tags with security role
References: <20160607171245.24975.77161.malonedeb@gac.canonical.com>
Message-ID: <20160609032605.31796.10376.malone@soybean.canonical.com>

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

commit d8ae1e3b04550f271d5561430a9008dee1cf4187
Author: Major Hayden <major at mhtx.net>
Date:   Tue Jun 7 13:05:49 2016 -0500

    Set check_mode variable every time
    
    In check mode, the security role will fail when tags are used. This
    is because the check_mode variable wasn't being set when tags were
    provided. This patch ensures that the tasks that check for check mode
    and set the subsequent check_mode variable will run every time.
    
    Closes-bug: 1590086
    
    Change-Id: Ib6a29ee4c36632cd6d982ce87105f0ddec4a891d


** 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/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 1590086 at bugs.launchpad.net  Thu Jun  9 13:24:43 2016
From: 1590086 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 09 Jun 2016 13:24:43 -0000
Subject: [Openstack-security] [Bug 1590086] Fix proposed to
 openstack-ansible-security (stable/mitaka)
References: <20160607171245.24975.77161.malonedeb@gac.canonical.com>
Message-ID: <20160609132443.24741.15223.malone@gac.canonical.com>

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/327657

-- 
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 1590086 at bugs.launchpad.net  Thu Jun  9 13:24:59 2016
From: 1590086 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 09 Jun 2016 13:24:59 -0000
Subject: [Openstack-security] [Bug 1590086] Fix proposed to
	openstack-ansible-security (liberty)
References: <20160607171245.24975.77161.malonedeb@gac.canonical.com>
Message-ID: <20160609132459.31831.37019.malone@soybean.canonical.com>

Fix proposed to branch: liberty
Review: https://review.openstack.org/327658

-- 
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 major at mhtx.net  Thu Jun  9 18:30:45 2016
From: major at mhtx.net (Major Hayden)
Date: Thu, 09 Jun 2016 18:30:45 -0000
Subject: [Openstack-security] [Bug 1590916] [NEW] Running augenrules should
 trigger an auditd restart
Message-ID: <20160609183045.31455.50670.malonedeb@soybean.canonical.com>

Public bug reported:

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.

** Affects: openstack-ansible
     Importance: Medium
     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/1590916

Title:
  Running augenrules should trigger an auditd restart

Status in openstack-ansible:
  Confirmed

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 major at mhtx.net  Thu Jun  9 18:13:17 2016
From: major at mhtx.net (Major Hayden)
Date: Thu, 09 Jun 2016 18:13:17 -0000
Subject: [Openstack-security] [Bug 1590911] [NEW] Security role audit rules
	should have key fields
Message-ID: <20160609181317.31455.73339.malonedeb@soybean.canonical.com>

Public bug reported:

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.

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

Title:
  Security role audit rules should have key fields

Status in openstack-ansible:
  Confirmed

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 1590916 at bugs.launchpad.net  Thu Jun  9 19:06:14 2016
From: 1590916 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 09 Jun 2016 19:06:14 -0000
Subject: [Openstack-security] [Bug 1590916] Re: Running augenrules should
	trigger an auditd restart
References: <20160609183045.31455.50670.malonedeb@soybean.canonical.com>
Message-ID: <20160609190615.2775.54894.malone@chaenomeles.canonical.com>

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

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

Title:
  Running augenrules should trigger an auditd restart

Status in openstack-ansible:
  In Progress

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 1590911 at bugs.launchpad.net  Thu Jun  9 19:10:11 2016
From: 1590911 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 09 Jun 2016 19:10:11 -0000
Subject: [Openstack-security] [Bug 1590911] Re: Security role audit rules
	should have key fields
References: <20160609181317.31455.73339.malonedeb@soybean.canonical.com>
Message-ID: <20160609191012.2626.18130.malone@chaenomeles.canonical.com>

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

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

Title:
  Security role audit rules should have key fields

Status in openstack-ansible:
  In Progress

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 1541122 at bugs.launchpad.net  Thu Jun  9 19:12:48 2016
From: 1541122 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 09 Jun 2016 19:12:48 -0000
Subject: [Openstack-security] [Bug 1541122] Change abandoned on sahara
	(master)
References: <20160202222341.14647.37585.malonedeb@gac.canonical.com>
Message-ID: <20160609191248.25043.12986.malone@gac.canonical.com>

Change abandoned by Michael McCune (msm at redhat.com) on branch: master
Review: https://review.openstack.org/312497
Reason: abandoning this as there is a change coming from another author

-- 
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 1590086 at bugs.launchpad.net  Thu Jun  9 20:33:54 2016
From: 1590086 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 09 Jun 2016 20:33:54 -0000
Subject: [Openstack-security] [Bug 1590086] Re: check_mode not set when
 using tags with security role
References: <20160607171245.24975.77161.malonedeb@gac.canonical.com>
Message-ID: <20160609203354.12169.94734.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/327657
Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=f0848de629f9e9e595749ceef727ef53693f624d
Submitter: Jenkins
Branch:    stable/mitaka

commit f0848de629f9e9e595749ceef727ef53693f624d
Author: Major Hayden <major at mhtx.net>
Date:   Thu Jun 9 08:19:27 2016 -0500

    Set check_mode variable every time
    
    In check mode, the security role will fail when tags are used. This
    is because the check_mode variable wasn't being set when tags were
    provided. This patch ensures that the tasks that check for check mode
    and set the subsequent check_mode variable will run every time.
    
    This is a manual backport of Ib6a29ee4c36632cd6d982ce87105f0ddec4a891d
    since the master/Newton branch includes some new things for systemd that
    doesn't make sense in Mitaka/Liberty.
    
    Closes-bug: 1590086
    
    Change-Id: Ib6a29ee4c36632cd6d982ce87105f0ddec4a891d


** Tags added: in-stable-mitaka

** 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/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 1590086 at bugs.launchpad.net  Thu Jun  9 20:34:01 2016
From: 1590086 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 09 Jun 2016 20:34:01 -0000
Subject: [Openstack-security] [Bug 1590086] Fix merged to
	openstack-ansible-security (liberty)
References: <20160607171245.24975.77161.malonedeb@gac.canonical.com>
Message-ID: <20160609203401.25149.51355.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/327658
Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=6213c87d51d00416475e1e97c13686e726c8f288
Submitter: Jenkins
Branch:    liberty

commit 6213c87d51d00416475e1e97c13686e726c8f288
Author: Major Hayden <major at mhtx.net>
Date:   Thu Jun 9 08:19:27 2016 -0500

    Set check_mode variable every time
    
    In check mode, the security role will fail when tags are used. This
    is because the check_mode variable wasn't being set when tags were
    provided. This patch ensures that the tasks that check for check mode
    and set the subsequent check_mode variable will run every time.
    
    This is a manual backport of Ib6a29ee4c36632cd6d982ce87105f0ddec4a891d
    since the master/Newton branch includes some new things for systemd that
    doesn't make sense in Mitaka/Liberty.
    
    Closes-bug: 1590086
    
    Change-Id: Ib6a29ee4c36632cd6d982ce87105f0ddec4a891d

-- 
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 1590916 at bugs.launchpad.net  Fri Jun 10 05:03:39 2016
From: 1590916 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 10 Jun 2016 05:03:39 -0000
Subject: [Openstack-security] [Bug 1590916] Re: Running augenrules should
	trigger an auditd restart
References: <20160609183045.31455.50670.malonedeb@soybean.canonical.com>
Message-ID: <20160610050339.12134.94483.malone@wampee.canonical.com>

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

commit 809b6cb52db069fc2cfc4e22f11fef417a893195
Author: Major Hayden <major at mhtx.net>
Date:   Thu Jun 9 15:14:42 2016 -0500

    Restart auditd after running augenrules
    
    The augenrules command joins together all of the audit rules from
    rules.d and it is run any time the audit rules template changes. However,
    the augenrules handler didn't actually restart auditd to apply the
    changes to the system.
    
    This patch fires off the auditd restart handler anytime the augenrules
    handler is notified.
    
    Closes-bug: 1590916
    
    Change-Id: Ice83fe17ebb0e9edff9da897e435ae96c1778580


** 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/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 1588544 at bugs.launchpad.net  Fri Jun 10 07:43:03 2016
From: 1588544 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 10 Jun 2016 07:43:03 -0000
Subject: [Openstack-security] [Bug 1588544] Fix merged to
	openstack-ansible-security (master)
References: <20160602215527.19591.65378.malonedeb@wampee.canonical.com>
Message-ID: <20160610074304.11671.88054.malone@wampee.canonical.com>

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

commit ef69ba2fadfd9c484a5b009b79c0d27ee282613d
Author: Major Hayden <major at mhtx.net>
Date:   Thu Jun 9 09:02:50 2016 -0500

    Add initial support for Red Hat Enterprise Linux 7
    
    This patch adds initial support for Red Hat Enterprise Linux 7. Although
    it has been tested on release 7.2, it's not possible to test Red Hat
    Enterprise Linux in the OpenStack CI gate jobs.
    
    Release notes are included.
    
    Change-Id: I62e06b9b105bc901eab6a019a378b29691862658
    Partial-bug: 1588544

-- 
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:
  In Progress

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 1590911 at bugs.launchpad.net  Fri Jun 10 07:46:04 2016
From: 1590911 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 10 Jun 2016 07:46:04 -0000
Subject: [Openstack-security] [Bug 1590911] Re: Security role audit rules
	should have key fields
References: <20160609181317.31455.73339.malonedeb@soybean.canonical.com>
Message-ID: <20160610074604.24623.96882.malone@gac.canonical.com>

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

commit 44e6056a933a53456711b6e8b3f2dae906830f8e
Author: Major Hayden <major at mhtx.net>
Date:   Thu Jun 9 13:42:18 2016 -0500

    Add key fields to audit rules
    
    This patch adjusts the key fields in the audit rules that are added
    by the security rule to make it easier to link a log entry with the
    audit rules that caused it. Deployers with overflowing logs should
    be able to narrow down the rule much more easily.
    
    Closes-Bug: 1590911
    
    Change-Id: I39c673d515467f685004463e914a0a1aaec3c153


** 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/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 1590916 at bugs.launchpad.net  Fri Jun 10 12:54:58 2016
From: 1590916 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 10 Jun 2016 12:54:58 -0000
Subject: [Openstack-security] [Bug 1590916] Fix proposed to
 openstack-ansible-security (stable/mitaka)
References: <20160609183045.31455.50670.malonedeb@soybean.canonical.com>
Message-ID: <20160610125458.31112.32146.malone@soybean.canonical.com>

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/328278

-- 
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 1590916 at bugs.launchpad.net  Fri Jun 10 12:55:12 2016
From: 1590916 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 10 Jun 2016 12:55:12 -0000
Subject: [Openstack-security] [Bug 1590916] Fix proposed to
	openstack-ansible-security (liberty)
References: <20160609183045.31455.50670.malonedeb@soybean.canonical.com>
Message-ID: <20160610125512.2181.86759.malone@chaenomeles.canonical.com>

Fix proposed to branch: liberty
Review: https://review.openstack.org/328279

-- 
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 1590911 at bugs.launchpad.net  Fri Jun 10 12:59:18 2016
From: 1590911 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 10 Jun 2016 12:59:18 -0000
Subject: [Openstack-security] [Bug 1590911] Fix proposed to
 openstack-ansible-security (stable/mitaka)
References: <20160609181317.31455.73339.malonedeb@soybean.canonical.com>
Message-ID: <20160610125918.25079.72450.malone@gac.canonical.com>

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/328285

-- 
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 1590911 at bugs.launchpad.net  Fri Jun 10 13:00:44 2016
From: 1590911 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 10 Jun 2016 13:00:44 -0000
Subject: [Openstack-security] [Bug 1590911] Fix proposed to
	openstack-ansible-security (liberty)
References: <20160609181317.31455.73339.malonedeb@soybean.canonical.com>
Message-ID: <20160610130044.24506.10436.malone@gac.canonical.com>

Fix proposed to branch: liberty
Review: https://review.openstack.org/328288

-- 
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 gerrit2 at review.openstack.org  Mon Jun 13 13:02:04 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 13 Jun 2016 13:02:04 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Id586b2558fd4c7ed0eda3d3555d51fcd019eb414
Message-ID: <E1bCRVE-000F7K-0K@review.openstack.org>


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

Log:
commit ba67bb033db995798124a534404c04224fb37a9a
Author: Solly Ross <sross at redhat.com>
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  Mon Jun 13 13:02:10 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 13 Jun 2016 13:02:10 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I64859ad01120782fb17308aac3abb125597c3ea2
Message-ID: <E1bCRVK-000F8t-70@review.openstack.org>


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

Log:
commit e84d58523d0f38ba803adb272b67c13a66c5684a
Author: Solly Ross <sross at redhat.com>
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 1588544 at bugs.launchpad.net  Mon Jun 13 15:57:34 2016
From: 1588544 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 13 Jun 2016 15:57:34 -0000
Subject: [Openstack-security] [Bug 1588544] Fix proposed to
	openstack-ansible-security (master)
References: <20160602215527.19591.65378.malonedeb@wampee.canonical.com>
Message-ID: <20160613155734.2112.98091.malone@chaenomeles.canonical.com>

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

-- 
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:
  In Progress

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 gerrit2 at review.openstack.org  Mon Jun 13 16:35:36 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 13 Jun 2016 16:35:36 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Id586b2558fd4c7ed0eda3d3555d51fcd019eb414
Message-ID: <E1bCUps-000WkX-S6@review.openstack.org>


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

Log:
commit a30f02e39e8e5b2ee9ab053f7771078f6ce3985f
Author: Solly Ross <sross at redhat.com>
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  Mon Jun 13 16:35:45 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 13 Jun 2016 16:35:45 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I64859ad01120782fb17308aac3abb125597c3ea2
Message-ID: <E1bCUq1-000Wnw-Ui@review.openstack.org>


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

Log:
commit 6cc5aa085f79871586098a6566b098a75c0eada3
Author: Solly Ross <sross at redhat.com>
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 1588544 at bugs.launchpad.net  Mon Jun 13 19:30:19 2016
From: 1588544 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 13 Jun 2016 19:30:19 -0000
Subject: [Openstack-security] [Bug 1588544] Re: RHEL7 Support for ansible
	security
References: <20160602215527.19591.65378.malonedeb@wampee.canonical.com>
Message-ID: <20160613193021.12204.33919.launchpad@wampee.canonical.com>

** Changed in: openstack-ansible
     Assignee: Major Hayden (rackerhacker) => Amy Marrich (amy-marrich)

-- 
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:
  In Progress

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 1590911 at bugs.launchpad.net  Tue Jun 14 10:31:00 2016
From: 1590911 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 14 Jun 2016 10:31:00 -0000
Subject: [Openstack-security] [Bug 1590911] Re: Security role audit rules
	should have key fields
References: <20160609181317.31455.73339.malonedeb@soybean.canonical.com>
Message-ID: <20160614103100.25043.23752.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/328288
Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=fd51d68c4df13b1d8e35b35c38ce8e2c0860a1fb
Submitter: Jenkins
Branch:    liberty

commit fd51d68c4df13b1d8e35b35c38ce8e2c0860a1fb
Author: Major Hayden <major at mhtx.net>
Date:   Thu Jun 9 13:42:18 2016 -0500

    Add key fields to audit rules
    
    This patch adjusts the key fields in the audit rules that are added
    by the security rule to make it easier to link a log entry with the
    audit rules that caused it. Deployers with overflowing logs should
    be able to narrow down the rule much more easily.
    
    A manual cherry-pick of I39c673d515467f685004463e914a0a1aaec3c153 is
    required since the master branch has some additions for SELinux that
    don't make sense in Mitaka or Liberty.
    
    Closes-Bug: 1590911
    
    Change-Id: I5c8757333eb22f35a120d78c8772f53c1c0bb9ca


** Tags added: in-liberty

** 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/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 1590911 at bugs.launchpad.net  Tue Jun 14 10:33:14 2016
From: 1590911 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 14 Jun 2016 10:33:14 -0000
Subject: [Openstack-security] [Bug 1590911] Fix merged to
	openstack-ansible-security (stable/mitaka)
References: <20160609181317.31455.73339.malonedeb@soybean.canonical.com>
Message-ID: <20160614103314.31610.57403.malone@soybean.canonical.com>

Reviewed:  https://review.openstack.org/328285
Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=cc45bade6a63472a704deb2093c845f5541d895b
Submitter: Jenkins
Branch:    stable/mitaka

commit cc45bade6a63472a704deb2093c845f5541d895b
Author: Major Hayden <major at mhtx.net>
Date:   Thu Jun 9 13:42:18 2016 -0500

    Add key fields to audit rules
    
    This patch adjusts the key fields in the audit rules that are added
    by the security rule to make it easier to link a log entry with the
    audit rules that caused it. Deployers with overflowing logs should
    be able to narrow down the rule much more easily.
    
    A manual cherry-pick of I39c673d515467f685004463e914a0a1aaec3c153 is
    required since the master branch has some additions for SELinux that
    don't make sense in Mitaka or Liberty.
    
    Closes-Bug: 1590911
    
    Change-Id: I5c8757333eb22f35a120d78c8772f53c1c0bb9ca

-- 
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 major at mhtx.net  Tue Jun 14 12:51:46 2016
From: major at mhtx.net (Major Hayden)
Date: Tue, 14 Jun 2016 12:51:46 -0000
Subject: [Openstack-security] [Bug 1588544] Re: RHEL7 Support for ansible
	security
References: <20160602215527.19591.65378.malonedeb@wampee.canonical.com>
Message-ID: <20160614125147.2181.77043.launchpad@chaenomeles.canonical.com>

** Changed in: openstack-ansible
     Assignee: Amy Marrich (amy-marrich) => 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/1588544

Title:
  RHEL7 Support for ansible security

Status in openstack-ansible:
  In Progress

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 1590916 at bugs.launchpad.net  Tue Jun 14 14:12:36 2016
From: 1590916 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 14 Jun 2016 14:12:36 -0000
Subject: [Openstack-security] [Bug 1590916] Re: Running augenrules should
	trigger an auditd restart
References: <20160609183045.31455.50670.malonedeb@soybean.canonical.com>
Message-ID: <20160614141236.12134.78409.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/328279
Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=e26c9112f95b2b3503dd8650bb9f49c11940d5a6
Submitter: Jenkins
Branch:    liberty

commit e26c9112f95b2b3503dd8650bb9f49c11940d5a6
Author: Major Hayden <major at mhtx.net>
Date:   Thu Jun 9 15:14:42 2016 -0500

    Restart auditd after running augenrules
    
    The augenrules command joins together all of the audit rules from
    rules.d and it is run any time the audit rules template changes. However,
    the augenrules handler didn't actually restart auditd to apply the
    changes to the system.
    
    This patch fires off the auditd restart handler anytime the augenrules
    handler is notified.
    
    Closes-bug: 1590916
    
    Change-Id: Ice83fe17ebb0e9edff9da897e435ae96c1778580
    (cherry picked from commit 809b6cb52db069fc2cfc4e22f11fef417a893195)


** Tags added: in-liberty

** 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/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 1590916 at bugs.launchpad.net  Tue Jun 14 14:13:02 2016
From: 1590916 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 14 Jun 2016 14:13:02 -0000
Subject: [Openstack-security] [Bug 1590916] Fix merged to
	openstack-ansible-security (stable/mitaka)
References: <20160609183045.31455.50670.malonedeb@soybean.canonical.com>
Message-ID: <20160614141302.24975.41548.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/328278
Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=bf195e2ec7c85b4e521385092f2d30adae05205e
Submitter: Jenkins
Branch:    stable/mitaka

commit bf195e2ec7c85b4e521385092f2d30adae05205e
Author: Major Hayden <major at mhtx.net>
Date:   Thu Jun 9 15:14:42 2016 -0500

    Restart auditd after running augenrules
    
    The augenrules command joins together all of the audit rules from
    rules.d and it is run any time the audit rules template changes. However,
    the augenrules handler didn't actually restart auditd to apply the
    changes to the system.
    
    This patch fires off the auditd restart handler anytime the augenrules
    handler is notified.
    
    Closes-bug: 1590916
    
    Change-Id: Ice83fe17ebb0e9edff9da897e435ae96c1778580
    (cherry picked from commit 809b6cb52db069fc2cfc4e22f11fef417a893195)

-- 
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 1590185 at bugs.launchpad.net  Tue Jun 14 16:08:00 2016
From: 1590185 at bugs.launchpad.net (Jean-Philippe Evrard)
Date: Tue, 14 Jun 2016 16:08:00 -0000
Subject: [Openstack-security] [Bug 1590185] Re: "V-38496 - Gather
 problematic system accounts" check fails on RHEL 7
References: <20160607232139.12031.65314.malonedeb@wampee.canonical.com>
Message-ID: <20160614160801.12385.81164.launchpad@wampee.canonical.com>

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

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

Title:
  "V-38496 - Gather problematic system accounts" check fails on RHEL 7

Status in openstack-ansible:
  Confirmed

Bug description:
  The check "V-38496 - Gather problematic system accounts" fails
  gloriously due to RHEL 7 not using jinja2.8 by default.  The specific
  issue is due to Jinja being 2.7 and not 2.8.

  If see the following error then you need to run "pip install Jinja2
  --upgrade":

  TASK: [openstack-ansible-security | V-38496 - Gather problematic system accounts] *** 
  fatal: [172.31.255.20] => Traceback (most recent call last):
    File "/usr/lib/python2.7/site-packages/ansible/runner/__init__.py", line 586, in _executor
      exec_rc = self._executor_internal(host, new_stdin)
    File "/usr/lib/python2.7/site-packages/ansible/runner/__init__.py", line 789, in _executor_internal
      return self._executor_internal_inner(host, self.module_name, self.module_args, inject, port, complex_args=complex_args)
    File "/usr/lib/python2.7/site-packages/ansible/runner/__init__.py", line 1013, in _executor_internal_inner
      complex_args = template.template(self.basedir, complex_args, inject, fail_on_undefined=self.error_on_undefined_vars)
    File "/usr/lib/python2.7/site-packages/ansible/utils/template.py", line 140, in template
      d[k] = template(basedir, v, templatevars, lookup_fatal, depth, expand_lists, convert_bare, fail_on_undefined, filter_fatal)
    File "/usr/lib/python2.7/site-packages/ansible/utils/template.py", line 124, in template
      varname = template_from_string(basedir, varname, templatevars, fail_on_undefined)
    File "/usr/lib/python2.7/site-packages/ansible/utils/template.py", line 382, in template_from_string
      res = jinja2.utils.concat(rf)
    File "<template>", line 11, in root
    File "/usr/lib/python2.7/site-packages/jinja2/filters.py", line 318, in do_join
      return text_type(d).join(imap(text_type, value))
    File "/usr/lib/python2.7/site-packages/jinja2/filters.py", line 931, in _select_or_reject
      if modfunc(func(transfunc(item))):
    File "/usr/lib/python2.7/site-packages/jinja2/filters.py", line 925, in <lambda>
      name, item, args, kwargs)
    File "/usr/lib/python2.7/site-packages/jinja2/environment.py", line 438, in call_test
      raise TemplateRuntimeError('no test named %r' % name)
  TemplateRuntimeError: no test named 'equalto'

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



From major at mhtx.net  Tue Jun 14 16:07:29 2016
From: major at mhtx.net (Major Hayden)
Date: Tue, 14 Jun 2016 16:07:29 -0000
Subject: [Openstack-security] [Bug 1590185] Re: "V-38496 - Gather
 problematic system accounts" check fails on RHEL 7
References: <20160607232139.12031.65314.malonedeb@wampee.canonical.com>
Message-ID: <20160614160730.2401.43999.launchpad@chaenomeles.canonical.com>

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

Title:
  "V-38496 - Gather problematic system accounts" check fails on RHEL 7

Status in openstack-ansible:
  Confirmed

Bug description:
  The check "V-38496 - Gather problematic system accounts" fails
  gloriously due to RHEL 7 not using jinja2.8 by default.  The specific
  issue is due to Jinja being 2.7 and not 2.8.

  If see the following error then you need to run "pip install Jinja2
  --upgrade":

  TASK: [openstack-ansible-security | V-38496 - Gather problematic system accounts] *** 
  fatal: [172.31.255.20] => Traceback (most recent call last):
    File "/usr/lib/python2.7/site-packages/ansible/runner/__init__.py", line 586, in _executor
      exec_rc = self._executor_internal(host, new_stdin)
    File "/usr/lib/python2.7/site-packages/ansible/runner/__init__.py", line 789, in _executor_internal
      return self._executor_internal_inner(host, self.module_name, self.module_args, inject, port, complex_args=complex_args)
    File "/usr/lib/python2.7/site-packages/ansible/runner/__init__.py", line 1013, in _executor_internal_inner
      complex_args = template.template(self.basedir, complex_args, inject, fail_on_undefined=self.error_on_undefined_vars)
    File "/usr/lib/python2.7/site-packages/ansible/utils/template.py", line 140, in template
      d[k] = template(basedir, v, templatevars, lookup_fatal, depth, expand_lists, convert_bare, fail_on_undefined, filter_fatal)
    File "/usr/lib/python2.7/site-packages/ansible/utils/template.py", line 124, in template
      varname = template_from_string(basedir, varname, templatevars, fail_on_undefined)
    File "/usr/lib/python2.7/site-packages/ansible/utils/template.py", line 382, in template_from_string
      res = jinja2.utils.concat(rf)
    File "<template>", line 11, in root
    File "/usr/lib/python2.7/site-packages/jinja2/filters.py", line 318, in do_join
      return text_type(d).join(imap(text_type, value))
    File "/usr/lib/python2.7/site-packages/jinja2/filters.py", line 931, in _select_or_reject
      if modfunc(func(transfunc(item))):
    File "/usr/lib/python2.7/site-packages/jinja2/filters.py", line 925, in <lambda>
      name, item, args, kwargs)
    File "/usr/lib/python2.7/site-packages/jinja2/environment.py", line 438, in call_test
      raise TemplateRuntimeError('no test named %r' % name)
  TemplateRuntimeError: no test named 'equalto'

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



From major at mhtx.net  Tue Jun 14 16:12:26 2016
From: major at mhtx.net (Major Hayden)
Date: Tue, 14 Jun 2016 16:12:26 -0000
Subject: [Openstack-security] [Bug 1590185] Re: "V-38496 - Gather
 problematic system accounts" check fails on RHEL 7
References: <20160607232139.12031.65314.malonedeb@wampee.canonical.com>
Message-ID: <20160614161226.11603.74589.malone@wampee.canonical.com>

I'd recommend against using the built-in Ansible and Jinja2 packages
provided by Red Hat because they're a little outdated with some of the
new features that the role uses.

You have a two options:

1. Use the 'run_tests.sh' script from the repository

This will build out a small virtual environment with the right versions
of Ansible and Jinja2

2. Build your own virtual environment

This is fairly easy and I can share some tips.

The Ansible version requirements should be more clearly stated in the
documentation and these two options should be presented, too.  I'll make
a patch for that in the docs.

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

Title:
  "V-38496 - Gather problematic system accounts" check fails on RHEL 7

Status in openstack-ansible:
  Confirmed

Bug description:
  The check "V-38496 - Gather problematic system accounts" fails
  gloriously due to RHEL 7 not using jinja2.8 by default.  The specific
  issue is due to Jinja being 2.7 and not 2.8.

  If see the following error then you need to run "pip install Jinja2
  --upgrade":

  TASK: [openstack-ansible-security | V-38496 - Gather problematic system accounts] *** 
  fatal: [172.31.255.20] => Traceback (most recent call last):
    File "/usr/lib/python2.7/site-packages/ansible/runner/__init__.py", line 586, in _executor
      exec_rc = self._executor_internal(host, new_stdin)
    File "/usr/lib/python2.7/site-packages/ansible/runner/__init__.py", line 789, in _executor_internal
      return self._executor_internal_inner(host, self.module_name, self.module_args, inject, port, complex_args=complex_args)
    File "/usr/lib/python2.7/site-packages/ansible/runner/__init__.py", line 1013, in _executor_internal_inner
      complex_args = template.template(self.basedir, complex_args, inject, fail_on_undefined=self.error_on_undefined_vars)
    File "/usr/lib/python2.7/site-packages/ansible/utils/template.py", line 140, in template
      d[k] = template(basedir, v, templatevars, lookup_fatal, depth, expand_lists, convert_bare, fail_on_undefined, filter_fatal)
    File "/usr/lib/python2.7/site-packages/ansible/utils/template.py", line 124, in template
      varname = template_from_string(basedir, varname, templatevars, fail_on_undefined)
    File "/usr/lib/python2.7/site-packages/ansible/utils/template.py", line 382, in template_from_string
      res = jinja2.utils.concat(rf)
    File "<template>", line 11, in root
    File "/usr/lib/python2.7/site-packages/jinja2/filters.py", line 318, in do_join
      return text_type(d).join(imap(text_type, value))
    File "/usr/lib/python2.7/site-packages/jinja2/filters.py", line 931, in _select_or_reject
      if modfunc(func(transfunc(item))):
    File "/usr/lib/python2.7/site-packages/jinja2/filters.py", line 925, in <lambda>
      name, item, args, kwargs)
    File "/usr/lib/python2.7/site-packages/jinja2/environment.py", line 438, in call_test
      raise TemplateRuntimeError('no test named %r' % name)
  TemplateRuntimeError: no test named 'equalto'

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



From 1588544 at bugs.launchpad.net  Tue Jun 14 23:19:28 2016
From: 1588544 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 14 Jun 2016 23:19:28 -0000
Subject: [Openstack-security] [Bug 1588544] Re: RHEL7 Support for ansible
	security
References: <20160602215527.19591.65378.malonedeb@wampee.canonical.com>
Message-ID: <20160614231928.15314.68522.malone@wampee.canonical.com>

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

commit b937e5b6bdac71b51824de6ccf1f16fa6da15d02
Author: Major Hayden <major at mhtx.net>
Date:   Mon Jun 13 14:25:02 2016 -0500

    Docs: Specify supported distributions
    
    This patch updates the list of supported Linux distributions since
    RHEL 7 support was added in I62e06b9b105bc901eab6a019a378b29691862658.
    
    Closes-bug: 1588544
    
    Change-Id: Ibaef4d65bbe418d553511f6496189c03205222d8


** 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/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 thierry.carrez+lp at gmail.com  Wed Jun 15 12:23:43 2016
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 15 Jun 2016 12:23:43 -0000
Subject: [Openstack-security] [Bug 1585349] Fix included in
 openstack/openstack-ansible-security 14.0.0.0b1
References: <20160524195344.25918.65100.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160615122343.11856.2840.malone@wampee.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security
14.0.0.0b1 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/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 thierry.carrez+lp at gmail.com  Wed Jun 15 12:23:46 2016
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 15 Jun 2016 12:23:46 -0000
Subject: [Openstack-security] [Bug 1584942] Fix included in
 openstack/openstack-ansible-security 14.0.0.0b1
References: <20160523201522.476.31063.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160615122346.11737.52932.malone@wampee.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security
14.0.0.0b1 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/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 thierry.carrez+lp at gmail.com  Wed Jun 15 12:23:42 2016
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 15 Jun 2016 12:23:42 -0000
Subject: [Openstack-security] [Bug 1584196] Fix included in
 openstack/openstack-ansible-security 14.0.0.0b1
References: <20160520195109.636.50703.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160615122342.24261.47807.malone@gac.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security
14.0.0.0b1 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/1584196

Title:
  Security role should look for unlabeled devices

Status in openstack-ansible:
  Fix Released

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 thierry.carrez+lp at gmail.com  Wed Jun 15 12:23:50 2016
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 15 Jun 2016 12:23:50 -0000
Subject: [Openstack-security] [Bug 1584194] Fix included in
 openstack/openstack-ansible-security 14.0.0.0b1
References: <20160520194448.10380.52421.malonedeb@gac.canonical.com>
Message-ID: <20160615122350.2522.88673.malone@chaenomeles.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security
14.0.0.0b1 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/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 thierry.carrez+lp at gmail.com  Wed Jun 15 12:23:48 2016
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 15 Jun 2016 12:23:48 -0000
Subject: [Openstack-security] [Bug 1584191] Fix included in
 openstack/openstack-ansible-security 14.0.0.0b1
References: <20160520193841.9222.38896.malonedeb@gac.canonical.com>
Message-ID: <20160615122349.15480.57207.malone@wampee.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security
14.0.0.0b1 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/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 thierry.carrez+lp at gmail.com  Wed Jun 15 12:23:44 2016
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 15 Jun 2016 12:23:44 -0000
Subject: [Openstack-security] [Bug 1584187] Fix included in
 openstack/openstack-ansible-security 14.0.0.0b1
References: <20160520192300.511.16353.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160615122344.25114.4220.malone@gac.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security
14.0.0.0b1 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/1584187

Title:
  Security role should set audit rules for SELinux

Status in openstack-ansible:
  Fix Released

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 thierry.carrez+lp at gmail.com  Wed Jun 15 12:23:45 2016
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 15 Jun 2016 12:23:45 -0000
Subject: [Openstack-security] [Bug 1583752] Fix included in
 openstack/openstack-ansible-security 14.0.0.0b1
References: <20160519190918.21523.53336.malonedeb@wampee.canonical.com>
Message-ID: <20160615122345.31308.52689.malone@soybean.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security
14.0.0.0b1 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/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 thierry.carrez+lp at gmail.com  Wed Jun 15 12:23:53 2016
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 15 Jun 2016 12:23:53 -0000
Subject: [Openstack-security] [Bug 1579914] Fix included in
 openstack/openstack-ansible-security 14.0.0.0b1
References: <20160509205442.981.10915.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160615122353.2592.71135.malone@chaenomeles.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security
14.0.0.0b1 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/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 thierry.carrez+lp at gmail.com  Wed Jun 15 12:23:58 2016
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 15 Jun 2016 12:23:58 -0000
Subject: [Openstack-security] [Bug 1568075] Fix included in
 openstack/openstack-ansible-security 14.0.0.0b1
References: <20160408180401.31578.77886.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160615122359.2740.76666.malone@chaenomeles.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security
14.0.0.0b1 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/1568075

Title:
  Security: Enable automatic updates as an option

Status in openstack-ansible:
  Fix Released

Bug description:
  Automatic updates are not included in openstack-ansible-security. This
  could potentially cause issues in some environments, but some
  deployers may want to enable automatic updates.

  We should add the Ansible tasks to get this done, but make it
  optional.

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



From thierry.carrez+lp at gmail.com  Wed Jun 15 12:18:48 2016
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 15 Jun 2016 12:18:48 -0000
Subject: [Openstack-security] [Bug 1568029] Fix included in
	openstack/openstack-ansible 14.0.0.0b1
References: <20160408161908.32065.20657.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160615121848.24391.51105.malone@gac.canonical.com>

This issue was fixed in the openstack/openstack-ansible 14.0.0.0b1
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 thierry.carrez+lp at gmail.com  Wed Jun 15 12:18:51 2016
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 15 Jun 2016 12:18:51 -0000
Subject: [Openstack-security] [Bug 1568029] Fix included in
	openstack/openstack-ansible 14.0.0.0b1
References: <20160408161908.32065.20657.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160615121851.24261.69072.malone@gac.canonical.com>

This issue was fixed in the openstack/openstack-ansible 14.0.0.0b1
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 davanum at gmail.com  Fri Jun 17 11:52:19 2016
From: davanum at gmail.com (Davanum Srinivas (DIMS))
Date: Fri, 17 Jun 2016 11:52:19 -0000
Subject: [Openstack-security] [Bug 1584942] Fix included in
 openstack/openstack-ansible-security 13.1.3
References: <20160523201522.476.31063.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160617115219.2915.67266.malone@chaenomeles.canonical.com>

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

-- 
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 davanum at gmail.com  Fri Jun 17 12:13:07 2016
From: davanum at gmail.com (Davanum Srinivas (DIMS))
Date: Fri, 17 Jun 2016 12:13:07 -0000
Subject: [Openstack-security] [Bug 1584942] Fix included in
 openstack/openstack-ansible-security 12.0.15
References: <20160523201522.476.31063.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160617121307.11603.17619.malone@wampee.canonical.com>

This issue was fixed in the openstack/openstack-ansible-security 12.0.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/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 1583804 at bugs.launchpad.net  Tue Jun 21 17:00:06 2016
From: 1583804 at bugs.launchpad.net (Jean-Philippe Evrard)
Date: Tue, 21 Jun 2016 17:00:06 -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: <20160621170007.24835.20544.launchpad@gac.canonical.com>

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

Title:
  Security role should require an email to receive root's mail

Status in openstack-ansible:
  Confirmed

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 major at mhtx.net  Wed Jun 22 04:06:53 2016
From: major at mhtx.net (Major Hayden)
Date: Wed, 22 Jun 2016 04:06:53 -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: <20160622040654.21817.46070.launchpad@soybean.canonical.com>

** Changed in: openstack-ansible
       Status: In Progress => Fix Committed

** Changed in: openstack-ansible
       Status: Fix Committed => 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/1583744

Title:
  Security role docs need updates for Xenial/CentOS

Status in openstack-ansible:
  Fix Released

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 832507 at bugs.launchpad.net  Wed Jun 22 17:04:09 2016
From: 832507 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 22 Jun 2016 17:04:09 -0000
Subject: [Openstack-security] [Bug 832507] Re: console.log grows indefinitely
References: <20110824042742.10840.74572.malonedeb@wampee.canonical.com>
Message-ID: <20160622170411.23744.6277.launchpad@chaenomeles.canonical.com>

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

** Changed in: nova
     Assignee: (unassigned) => Markus Zoeller (markus_z) (mzoeller)

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

Title:
  console.log grows indefinitely

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix
Status in libvirt package in Ubuntu:
  Fix Released
Status in nova package in Ubuntu:
  Fix Released
Status in qemu-kvm package in Ubuntu:
  Triaged

Bug description:
  KVM takes everything from stdout and prints it to console.log. This
  does not appear to have a size limit, so if a user (mistakenly or
  otherwise) sends a lot of data to stdout, the console.log file can
  fill the entire disk of the compute node quite quickly.

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



From 1586079 at bugs.launchpad.net  Thu Jun 23 16:50:24 2016
From: 1586079 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 23 Jun 2016 16:50:24 -0000
Subject: [Openstack-security] [Bug 1586079] Re: YaqlYamlLoader inherits from
	YamlLoader
References: <20160526151540.19337.24947.malonedeb@soybean.canonical.com>
Message-ID: <20160623165024.1542.14169.malone@chaenomeles.canonical.com>

Reviewed:  https://review.openstack.org/333428
Committed: https://git.openstack.org/cgit/openstack/murano-dashboard/commit/?id=66ef3d71941c4bd672d1e8e37d8f7b199acd5462
Submitter: Jenkins
Branch:    master

commit 66ef3d71941c4bd672d1e8e37d8f7b199acd5462
Author: Kirill Zaitsev <kzaitsev at mirantis.com>
Date:   Fri May 27 00:11:28 2016 +0300

    Inherit custom yaml Loader from yaml.SafeLoader
    
    Before this patch yaql-enabled yaml Loader was inherited from yaml.Loader, that
    potentially allows creating arbitrary python objects from specifically
    formatted yaml tags. This could have happened whenever UI definitions of
    the package were processed.
    With this change yaql yaml-Loader no longer allows creating custom python objects.
    
    Change-Id: I4fe38aa7e0fc567211ab872c7e1f8e81dbc3e765
    Closes-Bug: #1586079


** Changed in: murano
       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/1586079

Title:
  YaqlYamlLoader inherits from YamlLoader

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

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

  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 1586079 at bugs.launchpad.net  Thu Jun 23 17:20:04 2016
From: 1586079 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 23 Jun 2016 17:20:04 -0000
Subject: [Openstack-security] [Bug 1586079] Fix merged to murano (master)
References: <20160526151540.19337.24947.malonedeb@soybean.canonical.com>
Message-ID: <20160623172004.1803.23548.malone@chaenomeles.canonical.com>

Reviewed:  https://review.openstack.org/333423
Committed: https://git.openstack.org/cgit/openstack/murano/commit/?id=28de8c36c9dbe4aaf4d062e6fb6099afd437f49b
Submitter: Jenkins
Branch:    master

commit 28de8c36c9dbe4aaf4d062e6fb6099afd437f49b
Author: Kirill Zaitsev <k.zaitsev at me.com>
Date:   Fri May 27 00:42:38 2016 +0300

    Use SafeLoader to load yaml files
    
    Before this patch yaml.Loader was used by the engine to create custom
    yaql-enabled yaml loader. It is unsafe do to so, because yaml.Loader is
    capable of creating custom python objects from specifically constructed
    yaml files.
    After this patch all yaml load operations are performed with safe
    loaders instead.
    Also uses SafeConstructor instead of Constructor.
    
    Change-Id: I61a3c42d73608b5d013285f015a45f4774d264e3
    Closes-Bug: #1586079

-- 
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 Committed
Status in Murano mitaka series:
  Fix Committed
Status in Murano newton series:
  Fix Released

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

  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 1586079 at bugs.launchpad.net  Thu Jun 23 17:25:12 2016
From: 1586079 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 23 Jun 2016 17:25:12 -0000
Subject: [Openstack-security] [Bug 1586079] Re: YaqlYamlLoader inherits from
	YamlLoader
References: <20160526151540.19337.24947.malonedeb@soybean.canonical.com>
Message-ID: <20160623172512.2119.39364.malone@chaenomeles.canonical.com>

Reviewed:  https://review.openstack.org/333424
Committed: https://git.openstack.org/cgit/openstack/murano/commit/?id=b03c4759aa40d66bd4fcf62c96e352c117bdf4b9
Submitter: Jenkins
Branch:    stable/mitaka

commit b03c4759aa40d66bd4fcf62c96e352c117bdf4b9
Author: Kirill Zaitsev <k.zaitsev at me.com>
Date:   Fri May 27 00:42:38 2016 +0300

    Use SafeLoader to load yaml files
    
    Before this patch yaml.Loader was used by the engine to create custom
    yaql-enabled yaml loader. It is unsafe do to so, because yaml.Loader is
    capable of creating custom python objects from specifically constructed
    yaml files.
    After this patch all yaml load operations are performed with safe
    loaders instead.
    Also use SafeConstructor instead of Constructor.
    
    Change-Id: I61a3c42d73608b5d013285f015a45f4774d264e3
    Closes-Bug: #1586079


** Changed in: murano/mitaka
       Status: In Progress => Fix Committed

** Changed in: murano/liberty
       Status: In Progress => Fix Committed

-- 
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 Committed
Status in Murano mitaka series:
  Fix Committed
Status in Murano newton series:
  Fix Released

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

  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 1586079 at bugs.launchpad.net  Thu Jun 23 17:25:18 2016
From: 1586079 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 23 Jun 2016 17:25:18 -0000
Subject: [Openstack-security] [Bug 1586079] Fix merged to murano
	(stable/liberty)
References: <20160526151540.19337.24947.malonedeb@soybean.canonical.com>
Message-ID: <20160623172518.1878.5177.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/333425
Committed: https://git.openstack.org/cgit/openstack/murano/commit/?id=355513fe2e8c929f783de1109bee76c340cedced
Submitter: Jenkins
Branch:    stable/liberty

commit 355513fe2e8c929f783de1109bee76c340cedced
Author: Kirill Zaitsev <k.zaitsev at me.com>
Date:   Fri May 27 00:42:38 2016 +0300

    Use SafeLoader to load yaml files
    
    Before this patch yaml.Loader was used by the engine to create custom
    yaql-enabled yaml loader. It is unsafe do to so, because yaml.Loader is
    capable of creating custom python objects from specifically constructed
    yaml files.
    After this patch all yaml load operations are performed with safe
    loaders instead.
    Also use SafeConstructor instead of Constructor.
    
    Change-Id: I61a3c42d73608b5d013285f015a45f4774d264e3
    Closes-Bug: #1586079

-- 
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 Committed
Status in Murano mitaka series:
  Fix Committed
Status in Murano newton series:
  Fix Released

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

  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 1586079 at bugs.launchpad.net  Thu Jun 23 17:25:25 2016
From: 1586079 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 23 Jun 2016 17:25:25 -0000
Subject: [Openstack-security] [Bug 1586079] Fix merged to murano-dashboard
	(stable/mitaka)
References: <20160526151540.19337.24947.malonedeb@soybean.canonical.com>
Message-ID: <20160623172525.9285.26207.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/333439
Committed: https://git.openstack.org/cgit/openstack/murano-dashboard/commit/?id=338989020cfd2f4b16a71f7da9a788d668502c9e
Submitter: Jenkins
Branch:    stable/mitaka

commit 338989020cfd2f4b16a71f7da9a788d668502c9e
Author: Kirill Zaitsev <kzaitsev at mirantis.com>
Date:   Fri May 27 00:11:28 2016 +0300

    Inherit custom yaml Loader from yaml.SafeLoader
    
    Before this patch yaql-enabled yaml Loader was inherited from yaml.Loader, that
    potentially allows creating arbitrary python objects from specifically
    formatted yaml tags. This could have happened whenever UI definitions of
    the package were processed.
    With this change yaql yaml-Loader no longer allows creating custom python objects.
    
    Change-Id: I4fe38aa7e0fc567211ab872c7e1f8e81dbc3e765
    Closes-Bug: #1586079

-- 
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 Committed
Status in Murano mitaka series:
  Fix Committed
Status in Murano newton series:
  Fix Released

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

  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 1586078 at bugs.launchpad.net  Thu Jun 23 17:28:53 2016
From: 1586078 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 23 Jun 2016 17:28:53 -0000
Subject: [Openstack-security] [Bug 1586078] Re: YaqlYamlLoader inherits from
	YamlLoader
References: <20160526151327.17490.6569.malonedeb@soybean.canonical.com>
Message-ID: <20160623172853.8872.93541.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/333440
Committed: https://git.openstack.org/cgit/openstack/python-muranoclient/commit/?id=cd182ba363a11078ae7a0595f54751c1ebddd2e0
Submitter: Jenkins
Branch:    master

commit cd182ba363a11078ae7a0595f54751c1ebddd2e0
Author: Kirill Zaitsev <kzaitsev at mirantis.com>
Date:   Fri May 27 01:04:31 2016 +0300

    Use yaml.SafeLoader instead of yaml.Loader
    
    Before this patch yaml.Loader was used by the client to create custom
    yaql-enabled yaml loader. It is unsfae do to so, because yaml.Loader is
    capable of creating custom python objects from specifically constructed
    yaml files.
    UI parsing functions also fell back to yaml.Loader if
    the custom loader was not supplied.
    After this patch all yaml load operations are performed with safe
    loaders instead.
    
    Change-Id: Id9bb6eabda35522271ec394f8758a974878cbb4b
    Closes-Bug: #1586078


** Changed in: python-muranoclient
       Status: In Progress => Fix Released

** Changed in: python-muranoclient/mitaka
       Status: In Progress => Fix Committed

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

Title:
  YaqlYamlLoader inherits from YamlLoader

Status in python-muranoclient:
  Fix Released
Status in python-muranoclient kilo series:
  Won't Fix
Status in python-muranoclient liberty series:
  In Progress
Status in python-muranoclient mitaka series:
  Fix Committed
Status in python-muranoclient newton series:
  Fix Released

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

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/python-muranoclient/+bug/1586078/+subscriptions



From 1586078 at bugs.launchpad.net  Thu Jun 23 17:29:07 2016
From: 1586078 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 23 Jun 2016 17:29:07 -0000
Subject: [Openstack-security] [Bug 1586078] Fix merged to
	python-muranoclient (stable/mitaka)
References: <20160526151327.17490.6569.malonedeb@soybean.canonical.com>
Message-ID: <20160623172907.2279.8408.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/333443
Committed: https://git.openstack.org/cgit/openstack/python-muranoclient/commit/?id=e470430814ceddadea66d2e4bb3a9b10b55869e6
Submitter: Jenkins
Branch:    stable/mitaka

commit e470430814ceddadea66d2e4bb3a9b10b55869e6
Author: Kirill Zaitsev <kzaitsev at mirantis.com>
Date:   Fri May 27 01:04:31 2016 +0300

    Use yaml.SafeLoader instead of yaml.Loader
    
    Before this patch yaml.Loader was used by the client to create custom
    yaql-enabled yaml loader. It is unsfae do to so, because yaml.Loader is
    capable of creating custom python objects from specifically constructed
    yaml files.
    UI parsing functions also fell back to yaml.Loader if
    the custom loader was not supplied.
    After this patch all yaml load operations are performed with safe
    loaders instead.
    
    Change-Id: Id9bb6eabda35522271ec394f8758a974878cbb4b
    Closes-Bug: #1586078

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

Title:
  YaqlYamlLoader inherits from YamlLoader

Status in python-muranoclient:
  Fix Released
Status in python-muranoclient kilo series:
  Won't Fix
Status in python-muranoclient liberty series:
  In Progress
Status in python-muranoclient mitaka series:
  Fix Committed
Status in python-muranoclient newton series:
  Fix Released

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

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/python-muranoclient/+bug/1586078/+subscriptions



From 1586078 at bugs.launchpad.net  Thu Jun 23 17:45:51 2016
From: 1586078 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 23 Jun 2016 17:45:51 -0000
Subject: [Openstack-security] [Bug 1586078] Re: YaqlYamlLoader inherits from
	YamlLoader
References: <20160526151327.17490.6569.malonedeb@soybean.canonical.com>
Message-ID: <20160623174551.1729.22419.malone@chaenomeles.canonical.com>

Reviewed:  https://review.openstack.org/333444
Committed: https://git.openstack.org/cgit/openstack/python-muranoclient/commit/?id=b1e8a1753ccc3faf06840f675403645311ac9d79
Submitter: Jenkins
Branch:    stable/liberty

commit b1e8a1753ccc3faf06840f675403645311ac9d79
Author: Kirill Zaitsev <kzaitsev at mirantis.com>
Date:   Fri May 27 01:04:31 2016 +0300

    Use yaml.SafeLoader instead of yaml.Loader
    
    Before this patch yaml.Loader was used by the client to create custom
    yaql-enabled yaml loader. It is unsfae do to so, because yaml.Loader is
    capable of creating custom python objects from specifically constructed
    yaml files.
    UI parsing functions also fell back to yaml.Loader if
    the custom loader was not supplied.
    After this patch all yaml load operations are performed with safe
    loaders instead.
    
    Change-Id: Id9bb6eabda35522271ec394f8758a974878cbb4b
    Closes-Bug: #1586078


** Changed in: python-muranoclient/liberty
       Status: In Progress => Fix Committed

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

Title:
  YaqlYamlLoader inherits from YamlLoader

Status in python-muranoclient:
  Fix Released
Status in python-muranoclient kilo series:
  Won't Fix
Status in python-muranoclient liberty series:
  Fix Committed
Status in python-muranoclient mitaka series:
  Fix Committed
Status in python-muranoclient newton series:
  Fix Released

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

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/python-muranoclient/+bug/1586078/+subscriptions



From 1586079 at bugs.launchpad.net  Thu Jun 23 17:52:54 2016
From: 1586079 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 23 Jun 2016 17:52:54 -0000
Subject: [Openstack-security] [Bug 1586079] Fix merged to murano-dashboard
	(stable/liberty)
References: <20160526151540.19337.24947.malonedeb@soybean.canonical.com>
Message-ID: <20160623175254.1691.41503.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/333432
Committed: https://git.openstack.org/cgit/openstack/murano-dashboard/commit/?id=0f3745415ab4f083cbf069a9cb574168e499a386
Submitter: Jenkins
Branch:    stable/liberty

commit 0f3745415ab4f083cbf069a9cb574168e499a386
Author: Kirill Zaitsev <kzaitsev at mirantis.com>
Date:   Fri May 27 00:11:28 2016 +0300

    Inherit custom yaml Loader from yaml.SafeLoader
    
    Before this patch yaql-enabled yaml Loader was inherited from yaml.Loader, that
    potentially allows creating arbitrary python objects from specifically
    formatted yaml tags. This could have happened whenever UI definitions of
    the package were processed.
    With this change yaql yaml-Loader no longer allows creating custom python objects.
    
    Change-Id: I4fe38aa7e0fc567211ab872c7e1f8e81dbc3e765
    Closes-Bug: #1586079

-- 
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 Committed
Status in Murano mitaka series:
  Fix Committed
Status in Murano newton series:
  Fix Released

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

  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 ian.cordasco at rackspace.com  Thu Jun 23 20:50:12 2016
From: ian.cordasco at rackspace.com (Ian Cordasco)
Date: Thu, 23 Jun 2016 20:50:12 -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: <20160623205012.2163.37973.malone@soybean.canonical.com>

Yasmine, why is this a private security vulnerability? Those are only
for vulnerabilities.

** Information type changed from Private Security to Public

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

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 gerrit2 at review.openstack.org  Thu Jun 23 22:55:35 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 23 Jun 2016 22:55:35 +0000
Subject: [Openstack-security] [openstack/barbican-specs] SecurityImpact
 review request change I02054d80f68f38145b399909d60db80a4d91c1ba
Message-ID: <E1bGDX5-0002o9-80@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 427c7d6b68cd265195d6651e67495ae908edde64
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.
    
    APIImpact
    SecurityImpact
    
    Change-Id: I02054d80f68f38145b399909d60db80a4d91c1ba




From doug at doughellmann.com  Mon Jun 27 12:15:32 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Mon, 27 Jun 2016 12:15:32 -0000
Subject: [Openstack-security] [Bug 1586078] Fix included in
	openstack/python-muranoclient 0.9.0
References: <20160526151327.17490.6569.malonedeb@soybean.canonical.com>
Message-ID: <20160627121532.14051.77137.malone@soybean.canonical.com>

This issue was fixed in the openstack/python-muranoclient 0.9.0 release.

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

Title:
  YaqlYamlLoader inherits from YamlLoader

Status in python-muranoclient:
  Fix Released
Status in python-muranoclient kilo series:
  Won't Fix
Status in python-muranoclient liberty series:
  Fix Committed
Status in python-muranoclient mitaka series:
  Fix Committed
Status in python-muranoclient 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

To manage notifications about this bug go to:
https://bugs.launchpad.net/python-muranoclient/+bug/1586078/+subscriptions



From doug at doughellmann.com  Mon Jun 27 12:22:23 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Mon, 27 Jun 2016 12:22:23 -0000
Subject: [Openstack-security] [Bug 1586079] Fix included in
	openstack/murano-dashboard 2.0.1
References: <20160526151540.19337.24947.malonedeb@soybean.canonical.com>
Message-ID: <20160627122223.15150.28711.malone@soybean.canonical.com>

This issue was fixed in the openstack/murano-dashboard 2.0.1 release.

-- 
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 Committed
Status in Murano mitaka series:
  Fix Committed
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 doug at doughellmann.com  Mon Jun 27 12:22:44 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Mon, 27 Jun 2016 12:22:44 -0000
Subject: [Openstack-security] [Bug 1586079] Fix included in openstack/murano
	2.0.1
References: <20160526151540.19337.24947.malonedeb@soybean.canonical.com>
Message-ID: <20160627122244.30934.58992.malone@chaenomeles.canonical.com>

This issue was fixed in the openstack/murano 2.0.1 release.

-- 
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 Committed
Status in Murano mitaka series:
  Fix Committed
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 doug at doughellmann.com  Mon Jun 27 12:25:15 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Mon, 27 Jun 2016 12:25:15 -0000
Subject: [Openstack-security] [Bug 1586079] Fix included in
	openstack/murano-dashboard 1.0.3
References: <20160526151540.19337.24947.malonedeb@soybean.canonical.com>
Message-ID: <20160627122515.17886.12806.malone@wampee.canonical.com>

This issue was fixed in the openstack/murano-dashboard 1.0.3 release.

-- 
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 Committed
Status in Murano mitaka series:
  Fix Committed
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 doug at doughellmann.com  Mon Jun 27 12:25:34 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Mon, 27 Jun 2016 12:25:34 -0000
Subject: [Openstack-security] [Bug 1586079] Fix included in openstack/murano
	1.0.3
References: <20160526151540.19337.24947.malonedeb@soybean.canonical.com>
Message-ID: <20160627122534.23279.91057.malone@gac.canonical.com>

This issue was fixed in the openstack/murano 1.0.3 release.

-- 
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 Committed
Status in Murano mitaka series:
  Fix Committed
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 doug at doughellmann.com  Mon Jun 27 12:23:50 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Mon, 27 Jun 2016 12:23:50 -0000
Subject: [Openstack-security] [Bug 1586078] Fix included in
	openstack/python-muranoclient 0.8.5
References: <20160526151327.17490.6569.malonedeb@soybean.canonical.com>
Message-ID: <20160627122350.30538.48109.malone@chaenomeles.canonical.com>

This issue was fixed in the openstack/python-muranoclient 0.8.5 release.

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

Title:
  YaqlYamlLoader inherits from YamlLoader

Status in python-muranoclient:
  Fix Released
Status in python-muranoclient kilo series:
  Won't Fix
Status in python-muranoclient liberty series:
  Fix Committed
Status in python-muranoclient mitaka series:
  Fix Committed
Status in python-muranoclient 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

To manage notifications about this bug go to:
https://bugs.launchpad.net/python-muranoclient/+bug/1586078/+subscriptions



From doug at doughellmann.com  Mon Jun 27 12:26:17 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Mon, 27 Jun 2016 12:26:17 -0000
Subject: [Openstack-security] [Bug 1586078] Fix included in
	openstack/python-muranoclient 0.7.3
References: <20160526151327.17490.6569.malonedeb@soybean.canonical.com>
Message-ID: <20160627122617.23445.3638.malone@gac.canonical.com>

This issue was fixed in the openstack/python-muranoclient 0.7.3 release.

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

Title:
  YaqlYamlLoader inherits from YamlLoader

Status in python-muranoclient:
  Fix Released
Status in python-muranoclient kilo series:
  Won't Fix
Status in python-muranoclient liberty series:
  Fix Committed
Status in python-muranoclient mitaka series:
  Fix Committed
Status in python-muranoclient 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

To manage notifications about this bug go to:
https://bugs.launchpad.net/python-muranoclient/+bug/1586078/+subscriptions



From doug at doughellmann.com  Mon Jun 27 12:25:48 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Mon, 27 Jun 2016 12:25:48 -0000
Subject: [Openstack-security] [Bug 1552291] Fix included in openstack/murano
	1.0.3
References: <20160302155143.1515.80235.malonedeb@soybean.canonical.com>
Message-ID: <20160627122548.14082.61739.malone@soybean.canonical.com>

This issue was fixed in the openstack/murano 1.0.3 release.

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

Title:
  User with permissions can not set 'unshared' Murano package to
  'shared'

Status in Murano:
  Fix Released
Status in Murano liberty series:
  Fix Committed
Status in Murano mitaka series:
  Fix Released

Bug description:
  Hello,
  Please take a look at the issue below.
  Globally the problem is that user with permissions can't update Murano package.
  My env is: MOS 8.0 with ISO:589 (HA with vlan, murano, cinder and disabled SSL: 2x controllers; 3x compute,cinder)

  Actions performed from controller:

  1) OK - Perform actions as admin user:
  # . openrc

  2) OK - Create new role:
  # openstack role create 'can_publicize_packages'
      +-------+----------------------------------+
      | Field | Value |
      +-------+----------------------------------+
      | id | cdb2bf1c7cba4c188792481e9bfdf449 |
      | name | can_publicize_packages |
      +-------+----------------------------------+

  3) OK - List roles:
  # openstack role list
      +----------------------------------+------------------------+
      | ID | Name |
      +----------------------------------+------------------------+
       . . . .
      | cdb2bf1c7cba4c188792481e9bfdf449 | can_publicize_packages |
      +----------------------------------+------------------------+

  4) OK - Create new user inside 'services' project:
  # openstack user create '_test_user' --password 'password' --project 'services'
      +------------+----------------------------------+
      | Field | Value |
      +------------+----------------------------------+
      | email | None |
      | enabled | True |
      | id | e9783de276d64c0189df2c5a5ff79a63 |
      | name | _test_user |
      | project_id | fa38dcb711a24e979f1cd88486a9965e |
      | username | _test_user |
      +------------+----------------------------------+

  5) OK - Assign new role to the new user:
  # openstack role add 'can_publicize_packages' --user '_test_user' --project 'services'
      +-------+----------------------------------+
      | Field | Value |
      +-------+----------------------------------+
      | id | cdb2bf1c7cba4c188792481e9bfdf449 |
      | name | can_publicize_packages |
      +-------+----------------------------------+

  6) NOK - Check new role for :
  # openstack user role list '_test_user'
      {empty output}

    \\ I suppose it is expected to have some output here.

  7) OK - Try to assign again the same role to the same user:
  # openstack role add 'can_publicize_packages' --user '_test_user' --project 'services'
      Conflict occurred attempting to store role grant -
      User e9783de276d64c0189df2c5a5ff79a63 already has role
      cdb2bf1c7cba4c188792481e9bfdf449
      in tenant fa38dcb711a24e979f1cd88486a9965e
    (HTTP 409) (Request-ID: req-90460dca-6001-4c1d-90de-212aec294942)

   \\ So, seems, that role was actually assigned to the user.

  5) OK - On all two controllers add new role to /etc/murano/policy.json:
  # cp /etc/murano/policy.json /etc/murano/policy.json_orig
  # vim /etc/murano/policy.json
      from:
    "publicize_package": "rule:admin_api",
      to:
      "publicize_package": "rule:admin_api or role:can_publicize_packages",
      ### The same with:
      "publicize_package": ["rule:admin_api", "role:can_publicize_packages"],

  6) OK - On all two controllers restart some Murano services:
  # service murano-api restart ; service murano-engine restart
      murano-api stop/waiting
      murano-api start/running, process 5597
      murano-engine stop/waiting
      murano-engine start/running, process 5627

  6) OK - Change env to '_test_user' and 'services' project:
  # export OS_TENANT_NAME='services' ; export OS_PROJECT_NAME='services' ; export OS_USERNAME='_test_user' ; export OS_PASSWORD='password'

  7) OK - As a '_test_user' import Murano pkg:
  # murano --murano-repo-url=http://storage.apps.openstack.org package-import 'io.murano.apps.docker.Interfaces'
      Package file 'io.murano.apps.docker.Interfaces' does not exist, attempting to download
      Importing package io.murano.apps.docker.Interfaces
      +----------------------------------+--------------------------+----------------------------------+---------------+-----------+
      | ID | Name | FQN | Author | Is Public |
      +----------------------------------+--------------------------+----------------------------------+---------------+-----------+
      | 90fee6d0e41b441f9e8c4b29d89497aa | Core library | io.murano | murano.io | True |
      | 6c36dc3f149744ca8b18c5e1527b74ef | Docker Interface Library | io.murano.apps.docker.Interfaces | Mirantis, Inc | |
   +----------------------------------+--------------------------+----------------------------------+---------------+-----------+

  8) NOK - As a '_test_user' update imported pkg with Public=TRUE:
  # murano package-update '6c36dc3f149744ca8b18c5e1527b74ef' --is-public true
      403 Forbidden: Access was denied to this resource. (HTTP 403)

   \\ After step (5) it is expected for a new user to have ability to
  update imported packages.

  Please find logs for the last step (8) attached.
  Thanks.

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



From doug at doughellmann.com  Mon Jun 27 12:25:55 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Mon, 27 Jun 2016 12:25:55 -0000
Subject: [Openstack-security] [Bug 1532317] Fix included in openstack/murano
	1.0.3
References: <20160108202404.8643.13925.malonedeb@wampee.canonical.com>
Message-ID: <20160627122556.30809.95162.malone@chaenomeles.canonical.com>

This issue was fixed in the openstack/murano 1.0.3 release.

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

Title:
  Only ingress rules are supported in security groups

Status in Murano:
  Fix Released
Status in Murano kilo series:
  Fix Released
Status in Murano liberty series:
  Fix Released
Status in Murano mitaka series:
  Fix Released

Bug description:
  There is no way to specify in which direction security rule should be
  applied, only ingress is supported. Also there should be an optional
  key in existing parameter specifying rule IP protocol version
  (IPv4/IPv6)


  https://github.com/openstack/murano/blob/master/meta/io.murano/Classes/system/NeutronSecurityGroupManager.yaml#L56
  https://github.com/openstack/heat/blob/stable/kilo/heat/engine/resources/openstack/neutron/security_group.py#L50

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



From tdecacqu at redhat.com  Mon Jun 27 15:59:16 2016
From: tdecacqu at redhat.com (Tristan Cacqueray)
Date: Mon, 27 Jun 2016 15:59:16 -0000
Subject: [Openstack-security] [Bug 1572719] Re: Client may hold socket open
	after ChunkWriteTimeout
References: <20160420203849.17438.29709.malonedeb@soybean.canonical.com>
Message-ID: <20160627155916.30466.10823.malone@chaenomeles.canonical.com>

Opening this bug based on above comments

** 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.
- 
  You can reproduce this by issuing a GET request for a few hundred MB
  file and never consuming the response, but keep the client socket open.
  Swift will log a 499 but the socket does not always close.
  
  ChunkWriteTimeout is meant to protect the proxy from a slow reading client:
    https://github.com/openstack/swift/blob/master/swift/proxy/controllers/base.py#L889-L905
  
  Sometimes when this exception is thrown there is still data in the process socket buffer, so when eventlet tries to close the socket it first flushes it:
    https://github.com/eventlet/eventlet/blob/master/eventlet/wsgi.py#L631
    https://hg.python.org/cpython/file/v2.7.11/Lib/SocketServer.py#l711
  
  The problem is that if the client is not consuming the socket buffer
  then that flush will wait forever; it's trying to write on a socket that
  just threw a timeout trying to write! The flush write is not protected
  by any timeout.
  
  As far as I can tell, this WRITE_TIMEOUT does nothing:
    https://github.com/openstack/swift/blob/master/swift/common/wsgi.py#L407
  
  wsgi.server() takes a socket_timeout that might be what we're after?
    https://github.com/openstack/swift/blob/master/swift/common/wsgi.py#L437-L440
  
  Even with socket_timeout, eventlet needs to be patched. This should be in a finally block:
    https://github.com/eventlet/eventlet/blob/master/eventlet/wsgi.py#L636-L637
  
  All of this is probably mitigated by most operators setting an idle
  timeout in their load balancers, but I wanted to report it. Going
  directly to a proxy I was able to hold sockets open for long periods of
  time.
  
  I did the initial research on version 2.2.2 but I was able to reproduce
  on 2.7.0. I'm trying to translate links to master branch on github. I
  apologize in advance if it's not quite right.

** Tags added: security

** Information type changed from Private Security to Public

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

Title:
  Client may hold socket open after ChunkWriteTimeout

Status in OpenStack Security Advisory:
  Incomplete
Status in OpenStack Object Storage (swift):
  New

Bug description:
  You can reproduce this by issuing a GET request for a few hundred MB
  file and never consuming the response, but keep the client socket
  open. Swift will log a 499 but the socket does not always close.

  ChunkWriteTimeout is meant to protect the proxy from a slow reading client:
    https://github.com/openstack/swift/blob/master/swift/proxy/controllers/base.py#L889-L905

  Sometimes when this exception is thrown there is still data in the process socket buffer, so when eventlet tries to close the socket it first flushes it:
    https://github.com/eventlet/eventlet/blob/master/eventlet/wsgi.py#L631
    https://hg.python.org/cpython/file/v2.7.11/Lib/SocketServer.py#l711

  The problem is that if the client is not consuming the socket buffer
  then that flush will wait forever; it's trying to write on a socket
  that just threw a timeout trying to write! The flush write is not
  protected by any timeout.

  As far as I can tell, this WRITE_TIMEOUT does nothing:
    https://github.com/openstack/swift/blob/master/swift/common/wsgi.py#L407

  wsgi.server() takes a socket_timeout that might be what we're after?
    https://github.com/openstack/swift/blob/master/swift/common/wsgi.py#L437-L440

  Even with socket_timeout, eventlet needs to be patched. This should be in a finally block:
    https://github.com/eventlet/eventlet/blob/master/eventlet/wsgi.py#L636-L637

  All of this is probably mitigated by most operators setting an idle
  timeout in their load balancers, but I wanted to report it. Going
  directly to a proxy I was able to hold sockets open for long periods
  of time.

  I did the initial research on version 2.2.2 but I was able to
  reproduce on 2.7.0. I'm trying to translate links to master branch on
  github. I apologize in advance if it's not quite right.

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



From 1583788 at bugs.launchpad.net  Tue Jun 28 16:06:24 2016
From: 1583788 at bugs.launchpad.net (Jean-Philippe Evrard)
Date: Tue, 28 Jun 2016 16:06:24 -0000
Subject: [Openstack-security] [Bug 1583788] Re: Security role should use
 pam_faillock for V-38501 on CentOS
References: <20160519204832.823.4874.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160628160627.15150.94001.launchpad@soybean.canonical.com>

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

Title:
  Security role should use pam_faillock for V-38501 on CentOS

Status in openstack-ansible:
  Confirmed

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 1595669 at bugs.launchpad.net  Tue Jun 28 17:11:39 2016
From: 1595669 at bugs.launchpad.net (Jean-Philippe Evrard)
Date: Tue, 28 Jun 2016 17:11:39 -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: <20160628171139.18342.61267.malone@wampee.canonical.com>

Hello,

We'll need more details on the bug for proper triaging, is that a
whishlist, what's the real bug behind it? Could you help us understand,
please?

Thank you in advance.

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

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 gerrit2 at review.openstack.org  Tue Jun 28 20:25:49 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 28 Jun 2016 20:25:49 +0000
Subject: [Openstack-security] [openstack/barbican-specs] SecurityImpact
 review request change I02054d80f68f38145b399909d60db80a4d91c1ba
Message-ID: <E1bHzZt-000AbZ-1F@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 b7faadf59995fcae7981f8a32e0bfac9c2d6b3e8
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  Wed Jun 29 06:41:08 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 29 Jun 2016 06:41:08 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I3835d7364cc3c96c38c917fc0fb1674a11447954
Message-ID: <E1bI9BM-000PBs-Ly@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 e2a51ee7b92fae3b75597fa0963a0b12f73a344c
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 gerrit2 at review.openstack.org  Wed Jun 29 15:50:13 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 29 Jun 2016 15:50:13 +0000
Subject: [Openstack-security] [openstack/barbican-specs] SecurityImpact
 review request change I02054d80f68f38145b399909d60db80a4d91c1ba
Message-ID: <E1bIHkj-000BQ2-VA@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 186eb4502fd9991d87a379f8338e43bdb16ac1e7
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  Wed Jun 29 17:15:38 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 29 Jun 2016 17:15:38 +0000
Subject: [Openstack-security] [openstack/barbican-specs] SecurityImpact
 review request change I02054d80f68f38145b399909d60db80a4d91c1ba
Message-ID: <E1bIJ5O-000Uox-Fd@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 1b493e274c3258a36ea31ae66c35749479230ebd
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 Jun 30 14:00:34 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 30 Jun 2016 14:00:34 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Id586b2558fd4c7ed0eda3d3555d51fcd019eb414
Message-ID: <E1bIcWA-0001zH-Ak@review.openstack.org>


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

Log:
commit 913dcd77505e5c0fa039334db57c6d5cfe17c463
Author: Solly Ross <sross at redhat.com>
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 Jun 30 14:00:44 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 30 Jun 2016 14:00:44 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I64859ad01120782fb17308aac3abb125597c3ea2
Message-ID: <E1bIcWK-00020X-5i@review.openstack.org>


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

Log:
commit 6ead7e17049f667f2af2225a5a00ddf69651775e
Author: Solly Ross <sross at redhat.com>
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