From jesse.pretorius at gmail.com  Mon Apr  4 11:31:03 2016
From: jesse.pretorius at gmail.com (Jesse Pretorius)
Date: Mon, 04 Apr 2016 11:31:03 -0000
Subject: [Openstack-security] [Bug 1556231] Re: Rootwrap configuration has
	incorrect ownership
References: <20160311182127.26542.80930.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160404113106.32758.51324.launchpad@wampee.canonical.com>

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

Title:
  Rootwrap configuration has incorrect ownership

Status in openstack-ansible:
  Fix Released
Status in openstack-ansible kilo series:
  Fix Released
Status in openstack-ansible liberty series:
  Fix Released
Status in openstack-ansible trunk series:
  Fix Released

Bug description:
  The /etc/<openstack_service>/rootwrap.conf file and
  /etc/<openstack_service>/rootwrap.d directory and its contents created
  by the Nova, Neutron, Cinder and Ceilomer playbooks/roles are
  incorrectly owned by a user other than root.

  This is a security vulnerability inasmuch as it may allow users with
  lower privileges to modify the rootwrap configuration and escalate
  privileges.

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



From gerrit2 at review.openstack.org  Mon Apr  4 13:16:58 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 04 Apr 2016 13:16:58 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Id586b2558fd4c7ed0eda3d3555d51fcd019eb414
Message-ID: <E1an4NG-0001Sy-1n@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 0338d9c432d7ed75e9acc96ae563685f4bad25ce
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 Apr  4 13:17:05 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 04 Apr 2016 13:17:05 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I64859ad01120782fb17308aac3abb125597c3ea2
Message-ID: <E1an4NN-0001Ux-7Y@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 8a2e1b22c4f1bab6077ad8669b2454bd37f58478
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 gerrit2 at review.openstack.org  Mon Apr  4 17:10:41 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 04 Apr 2016 17:10:41 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Id586b2558fd4c7ed0eda3d3555d51fcd019eb414
Message-ID: <E1an81R-0001w6-8G@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 dc5eb8bd2b913db511fc8363dd1ea3a10c5c9f7e
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 Apr  4 17:10:49 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 04 Apr 2016 17:10:49 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I64859ad01120782fb17308aac3abb125597c3ea2
Message-ID: <E1an81Z-0001yN-U3@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 67799447eaca9d553a2e1004c3716e78f0bd6e0d
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 gerrit2 at review.openstack.org  Tue Apr  5 21:54:20 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 05 Apr 2016 21:54:20 +0000
Subject: [Openstack-security] [openstack/barbican-specs] SecurityImpact
 review request change I02054d80f68f38145b399909d60db80a4d91c1ba
Message-ID: <E1anYvU-0001pQ-RD@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 40d3a35294e1fb0ca9ac6fcebba9a1380c9b271c
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 major at mhtx.net  Fri Apr  8 16:19:08 2016
From: major at mhtx.net (Major Hayden)
Date: Fri, 08 Apr 2016 16:19:08 -0000
Subject: [Openstack-security] [Bug 1568029] [NEW] Security: Disable role
 during major version upgrades
Message-ID: <20160408161908.32065.20657.malonedeb@chaenomeles.canonical.com>

Public bug reported:

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.

** Affects: openstack-ansible
     Importance: Wishlist
         Status: New


** Tags: security

** Tags added: security

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

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

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 major at mhtx.net  Fri Apr  8 16:21:54 2016
From: major at mhtx.net (Major Hayden)
Date: Fri, 08 Apr 2016 16:21:54 -0000
Subject: [Openstack-security] [Bug 1568027] Re: Security: Add docs for
	monitoring logs/notifications
References: <20160408161603.3473.89222.malonedeb@gac.canonical.com>
Message-ID: <20160408162154.32096.95274.launchpad@chaenomeles.canonical.com>

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

Title:
  Security: Add docs for monitoring logs/notifications

Status in openstack-ansible:
  Confirmed

Bug description:
  The openstack-ansible-security docs talk about the AIDE and Auditd
  changes, but they don't talk much about what deployers should be doing
  with those notifications.  Adding some friendly advice about how to
  handle these would be very useful.

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



From major at mhtx.net  Fri Apr  8 17:56:40 2016
From: major at mhtx.net (Major Hayden)
Date: Fri, 08 Apr 2016 17:56:40 -0000
Subject: [Openstack-security] [Bug 1568070] [NEW] Security: Identify which
	changes require a reboot
Message-ID: <20160408175640.32100.77020.malonedeb@soybean.canonical.com>

Public bug reported:

Some changes made by openstack-ansible-security require a reboot. It
would be nice to alert the deployer to those changes at the end of the
playbook run so they know if they had a change made that requires a
reboot.

** Affects: openstack-ansible
     Importance: Wishlist
         Status: New


** Tags: security

** Tags added: security

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

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

Title:
  Security: Identify which changes require a reboot

Status in openstack-ansible:
  New

Bug description:
  Some changes made by openstack-ansible-security require a reboot. It
  would be nice to alert the deployer to those changes at the end of the
  playbook run so they know if they had a change made that requires a
  reboot.

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



From major at mhtx.net  Fri Apr  8 18:04:01 2016
From: major at mhtx.net (Major Hayden)
Date: Fri, 08 Apr 2016 18:04:01 -0000
Subject: [Openstack-security] [Bug 1568075] [NEW] Security: Enable automatic
	updates as an option
Message-ID: <20160408180401.31578.77886.malonedeb@chaenomeles.canonical.com>

Public bug reported:

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.

** Affects: openstack-ansible
     Importance: Wishlist
         Status: New


** Tags: security

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

Title:
  Security: Enable automatic updates as an option

Status in openstack-ansible:
  New

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 major at mhtx.net  Fri Apr  8 18:08:25 2016
From: major at mhtx.net (Major Hayden)
Date: Fri, 08 Apr 2016 18:08:25 -0000
Subject: [Openstack-security] [Bug 1568027] Re: Security: Add docs for
	monitoring logs/notifications
References: <20160408161603.3473.89222.malonedeb@gac.canonical.com>
Message-ID: <20160408180826.31510.56214.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/1568027

Title:
  Security: Add docs for monitoring logs/notifications

Status in openstack-ansible:
  Confirmed

Bug description:
  The openstack-ansible-security docs talk about the AIDE and Auditd
  changes, but they don't talk much about what deployers should be doing
  with those notifications.  Adding some friendly advice about how to
  handle these would be very useful.

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



From 1568075 at bugs.launchpad.net  Mon Apr 11 09:45:00 2016
From: 1568075 at bugs.launchpad.net (Matt Thompson)
Date: Mon, 11 Apr 2016 09:45:00 -0000
Subject: [Openstack-security] [Bug 1568075] Re: Security: Enable automatic
	updates as an option
References: <20160408180401.31578.77886.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160411094501.32475.10995.launchpad@soybean.canonical.com>

** Changed in: openstack-ansible
     Assignee: (unassigned) => Matt Thompson (mattt416)

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

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 matt at mattfischer.com  Mon Apr 11 14:19:50 2016
From: matt at mattfischer.com (Matt Fischer)
Date: Mon, 11 Apr 2016 08:19:50 -0600
Subject: [Openstack-security] abandoned OSSNs?
Message-ID: <CAHr1CO9Q6HQ47TYVxkkgsoQTbmwdQ7=+qfMGC2A7XMD3_tmPkg@mail.gmail.com>

Some folks from our security team here asked me to ensure them that our
services were patched for all the OSSNs that are listed here:
https://wiki.openstack.org/wiki/Security_Notes

Most of these are straight-forward, but there are some OSSNs that have been
allocated an ID but then abandoned. There is no detailed wiki page and my
best google efforts lead me to a possible IRC mention and maybe an
abandoned review. The two specifically are OSSN-50/51.

So what am I to do with an "abandoned" OSSN? Has it been decided that there
is no issue anymore? These are pretty old if I look at the dates framing
the other OSSNs (49/52), so I assume they aren't urgent. Can we ignore
these? They sound somewhat scary, for example, "keystonemiddleware can
allow access after token revocation" but I have no means to say whether it
affects us or how we can mitigate without more info.

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20160411/e93b674a/attachment.html>

From 1568075 at bugs.launchpad.net  Mon Apr 11 16:01:19 2016
From: 1568075 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 11 Apr 2016 16:01:19 -0000
Subject: [Openstack-security] [Bug 1568075] Re: Security: Enable automatic
	updates as an option
References: <20160408180401.31578.77886.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160411160120.31710.44960.launchpad@chaenomeles.canonical.com>

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

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

Title:
  Security: Enable automatic updates as an option

Status in openstack-ansible:
  In Progress

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 jesse.pretorius at gmail.com  Tue Apr 12 16:08:09 2016
From: jesse.pretorius at gmail.com (Jesse Pretorius)
Date: Tue, 12 Apr 2016 16:08:09 -0000
Subject: [Openstack-security] [Bug 1568070] Re: Security: Identify which
	changes require a reboot
References: <20160408175640.32100.77020.malonedeb@soybean.canonical.com>
Message-ID: <20160412160810.3973.2937.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/1568070

Title:
  Security: Identify which changes require a reboot

Status in openstack-ansible:
  Confirmed

Bug description:
  Some changes made by openstack-ansible-security require a reboot. It
  would be nice to alert the deployer to those changes at the end of the
  playbook run so they know if they had a change made that requires a
  reboot.

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



From 1445295 at bugs.launchpad.net  Wed Apr 13 01:34:03 2016
From: 1445295 at bugs.launchpad.net (Amrith)
Date: Wed, 13 Apr 2016 01:34:03 -0000
Subject: [Openstack-security] [Bug 1445295] Re: Guestagent config leaks
	rabbit password
References: <20150417022721.14148.34459.malonedeb@wampee.canonical.com>
Message-ID: <20160413013403.1479.43914.malone@wampee.canonical.com>

flwang asked questions about this on IRC today. I'll update the bug with
the known avoidance and explanations on how to securely deploy trove.

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

Title:
  Guestagent config leaks rabbit password

Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack DBaaS (Trove):
  New

Bug description:
  A running guest vm has the guestagent service running.  Included in
  this is the trave-guestagent.conf file. This contains (at least) the
  rabbit password.

  It is pretty easy to extract this as an unprivileged user - given that the guest image is publicly available, it can be downloaded, 
  and (if needed) converted to raw and mounted. From this either:

  - config can be immediately read if guestagent is pre-installed (or)
  - rsync command and ip + location of config files can be gleaned from 
  the init script

  In the second case it is then pretty easy to boot a vm on the 
  appropriate network and rsync the config files using the above gleaned 
  command(s) as required (e.g add keys to the previously downloaded trove 
  guest image, upload it to glance then run it directly from nova and ssh 
  in...).

  I'm thinking that we need to setup the guestagent so it does *not*
  need to know this level of detail about the inner workings of
  Openstack.

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



From jesse.pretorius at gmail.com  Fri Apr 15 11:04:02 2016
From: jesse.pretorius at gmail.com (Jesse Pretorius)
Date: Fri, 15 Apr 2016 11:04:02 -0000
Subject: [Openstack-security] [Bug 1568075] Re: Security: Enable automatic
	updates as an option
References: <20160408180401.31578.77886.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160415110403.5256.79638.launchpad@chaenomeles.canonical.com>

** Changed in: openstack-ansible
    Milestone: None => newton-1

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

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 morgan.fainberg at gmail.com  Mon Apr 18 17:35:29 2016
From: morgan.fainberg at gmail.com (Morgan Fainberg)
Date: Mon, 18 Apr 2016 17:35:29 -0000
Subject: [Openstack-security] [Bug 1567694] Re: nova's neutron client
	auth_uri uses admin
References: <20160407230323.3601.19297.malonedeb@gac.canonical.com>
Message-ID: <20160418173529.25286.6360.malone@wampee.canonical.com>

In keystone V3 (please keep sticking with v3!) the routes are the same
between admin and public (the distinction was a v2-specific construct in
keystone). It should be 100% safe to use either endpoint under v3.

For v2, I am unsure if this is working with something specific in the
eksytone crud API vs strictly auth.

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

Title:
  nova's neutron client auth_uri uses admin

Status in OpenStack Compute (nova):
  New

Bug description:
  looking at default config from various projects, including nova's own
  CI

  /etc/nova/nova.conf:
  [neutron]
  auth_url = http://localhost/35357/v3

  however when compared to other projects, they use the non-admin
  keystone port (5000) and the auth version(v3) for auth.

  It is confusing if this is necessary because the client needs access
  to the keystone admin api's or if we are simply just holding over some
  old config lore.

  Can we document what the actual requirement for this url is?
  is is only for auth?
  does it really need the keystone admin port?

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



From sean at dague.net  Mon Apr 18 18:01:31 2016
From: sean at dague.net (Sean Dague)
Date: Mon, 18 Apr 2016 18:01:31 -0000
Subject: [Openstack-security] [Bug 1567694] Re: nova's neutron client
	auth_uri uses admin
References: <20160407230323.3601.19297.malonedeb@gac.canonical.com>
Message-ID: <20160418180131.24867.94283.malone@wampee.canonical.com>

Closed because in v3 these are the same, as Morgan stated

** Changed in: nova
       Status: New => Won't Fix

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

Title:
  nova's neutron client auth_uri uses admin

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

Bug description:
  looking at default config from various projects, including nova's own
  CI

  /etc/nova/nova.conf:
  [neutron]
  auth_url = http://localhost/35357/v3

  however when compared to other projects, they use the non-admin
  keystone port (5000) and the auth version(v3) for auth.

  It is confusing if this is necessary because the client needs access
  to the keystone admin api's or if we are simply just holding over some
  old config lore.

  Can we document what the actual requirement for this url is?
  is is only for auth?
  does it really need the keystone admin port?

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



From 1568075 at bugs.launchpad.net  Mon Apr 18 19:18:12 2016
From: 1568075 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 18 Apr 2016 19:18:12 -0000
Subject: [Openstack-security] [Bug 1568075] Re: Security: Enable automatic
	updates as an option
References: <20160408180401.31578.77886.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160418191812.24196.41959.malone@gac.canonical.com>

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

commit d1ca8dbaa752703eee2c68e33aade87223602415
Author: Matt Thompson <mattt at defunct.ca>
Date:   Mon Apr 11 13:22:08 2016 +0100

    Add ability to enable unattended upgrades
    
    This commit adds the ability to enable automatic package upgrades via
    openstack-ansible-security.  To enable, add the following variable to
    your /etc/openstack_deploy/user_variables.yml file:
    
    unattended_upgrades_enabled: true
    
    To have the unattended upgrades system send e-mail notifications
    when packages need updating or errors are encountered, add the
    following to user_variables.yml:
    
    unattended_upgrades_notifications: true
    
    As many organisations do not subscribe to auto updates, this
    functionality will remain disabled by default.
    
    Note that the first iteration of this change does not allow deep
    customisation of unatteded-upgrades.  This means that as it stands
    only trusty-security (or $distro-security) updates will be applied.
    
    Closes-Bug: #1568075
    
    Change-Id: I22ba1a02acfbe2befb601af6a4099d53d988d856


** 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/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 1568070 at bugs.launchpad.net  Tue Apr 19 14:56:38 2016
From: 1568070 at bugs.launchpad.net (Matt Thompson)
Date: Tue, 19 Apr 2016 14:56:38 -0000
Subject: [Openstack-security] [Bug 1568070] Re: Security: Identify which
	changes require a reboot
References: <20160408175640.32100.77020.malonedeb@soybean.canonical.com>
Message-ID: <20160419145640.5722.14342.launchpad@chaenomeles.canonical.com>

** Changed in: openstack-ansible
     Assignee: (unassigned) => Matt Thompson (mattt416)

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

Title:
  Security: Identify which changes require a reboot

Status in openstack-ansible:
  Confirmed

Bug description:
  Some changes made by openstack-ansible-security require a reboot. It
  would be nice to alert the deployer to those changes at the end of the
  playbook run so they know if they had a change made that requires a
  reboot.

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



From 1568070 at bugs.launchpad.net  Tue Apr 19 15:38:20 2016
From: 1568070 at bugs.launchpad.net (Matt Thompson)
Date: Tue, 19 Apr 2016 15:38:20 -0000
Subject: [Openstack-security] [Bug 1568070] Re: Security: Identify which
	changes require a reboot
References: <20160408175640.32100.77020.malonedeb@soybean.canonical.com>
Message-ID: <20160419153822.17621.48285.launchpad@soybean.canonical.com>

** Changed in: openstack-ansible
     Assignee: Matt Thompson (mattt416) => Ian Cordasco (icordasc)

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

Title:
  Security: Identify which changes require a reboot

Status in openstack-ansible:
  Confirmed

Bug description:
  Some changes made by openstack-ansible-security require a reboot. It
  would be nice to alert the deployer to those changes at the end of the
  playbook run so they know if they had a change made that requires a
  reboot.

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



From gerrit2 at review.openstack.org  Tue Apr 19 21:20:06 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 19 Apr 2016 21:20:06 +0000
Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review
 request change If447521fdd54a5e999a36524b0adb01dd46496fa
Message-ID: <E1asd42-00079v-JB@review.openstack.org>


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

Log:
commit 5fc9fad96d15bba8e58ee5ed951e6828691312f9
Author: Dane Fichter <dane.fichter at jhuapl.edu>
Date:   Mon Apr 18 16:45:33 2016 -0400

    Stop encrypted disk on instance suspend/power off
    
    Disconnecting dm-crypt device from an encrypted LVM volume while the
    instance is suspended or powered off will secure user data from
    unauthorized access. This will extend data at-rest protection provided
    by the LVM ephemeral storage encryption feature.
    
    Implements: blueprint stop-dmcrypt-on-suspend
    SecurityImpact
    
    Previously-approved: mitaka (I32cace0fb5f5ccf12638de4abd527aad5a6ec4ac)
    
    Change-Id: If447521fdd54a5e999a36524b0adb01dd46496fa




From gerrit2 at review.openstack.org  Wed Apr 20 01:27:47 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 20 Apr 2016 01:27:47 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I3835d7364cc3c96c38c917fc0fb1674a11447954
Message-ID: <E1asgvj-0001bv-9Z@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 b8569a3ad9b19a5c9591f14ca1db9fadd653c555
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  Thu Apr 21 01:22:44 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 21 Apr 2016 01:22:44 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I3835d7364cc3c96c38c917fc0fb1674a11447954
Message-ID: <E1at3KO-0003uV-72@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 5149b2e590c1bc1489b7fc9346849368abb7f3fd
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  Thu Apr 21 07:22:44 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 21 Apr 2016 07:22:44 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I3835d7364cc3c96c38c917fc0fb1674a11447954
Message-ID: <E1at8wm-000Ez7-3V@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 0d0d7c975eb603130bbfa8b99806dfd86a52be9d
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 nik.komawar at gmail.com  Thu Apr 21 20:16:45 2016
From: nik.komawar at gmail.com (nikhil komawar)
Date: Thu, 21 Apr 2016 20:16:45 -0000
Subject: [Openstack-security] [Bug 1516031] Re: Use of MD5 in OpenStack
 Glance image signature (CVE-2015-8234)
References: <20151113142716.4469.80964.malonedeb@gac.canonical.com>
Message-ID: <20160421201647.23935.19758.launchpad@gac.canonical.com>

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

** Changed in: glance
       Status: Triaged => In Progress

** Changed in: glance
     Assignee: (unassigned) => Dane Fichter (dane-fichter)

** Changed in: glance
    Milestone: None => newton-1

-- 
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:
  In Progress
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 1516031 at bugs.launchpad.net  Thu Apr 21 21:33:31 2016
From: 1516031 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 21 Apr 2016 21:33:31 -0000
Subject: [Openstack-security] [Bug 1516031] Re: Use of MD5 in OpenStack
 Glance image signature (CVE-2015-8234)
References: <20151113142716.4469.80964.malonedeb@gac.canonical.com>
Message-ID: <20160421213331.24997.82132.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/308466
Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=5ab63107b69e381f04bfa4aa9143e229ac2a9857
Submitter: Jenkins
Branch:    master

commit 5ab63107b69e381f04bfa4aa9143e229ac2a9857
Author: Dane Fichter <dane.fichter at jhuapl.edu>
Date:   Tue Apr 19 01:27:02 2016 -0400

    Remove deprecated "sign-the-hash" approach
    
    This change removes the "sign-the-hash" signature
    verification code in the signature_utils module and
    the ImageProxy class. This code was deprecated in
    Mitaka and scheduled for removal in Newton.
    
    Change-Id: I8862f6c94538dd818c7360ba287e14c1264ff20f
    Closes-Bug: #1516031


** Changed in: glance
       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/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 gerrit2 at review.openstack.org  Fri Apr 22 09:02:36 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 22 Apr 2016 09:02:36 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I3835d7364cc3c96c38c917fc0fb1674a11447954
Message-ID: <E1atWyy-000LDV-6J@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 4664549c6de6fd1cc4955db0a35fe81d2dee9cbc
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 1568070 at bugs.launchpad.net  Mon Apr 25 22:02:11 2016
From: 1568070 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 25 Apr 2016 22:02:11 -0000
Subject: [Openstack-security] [Bug 1568070] Re: Security: Identify which
	changes require a reboot
References: <20160408175640.32100.77020.malonedeb@soybean.canonical.com>
Message-ID: <20160425220211.16897.70132.malone@soybean.canonical.com>

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

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

Title:
  Security: Identify which changes require a reboot

Status in openstack-ansible:
  In Progress

Bug description:
  Some changes made by openstack-ansible-security require a reboot. It
  would be nice to alert the deployer to those changes at the end of the
  playbook run so they know if they had a change made that requires a
  reboot.

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



From 832507 at bugs.launchpad.net  Tue Apr 26 00:36:55 2016
From: 832507 at bugs.launchpad.net (Seth Arnold)
Date: Tue, 26 Apr 2016 00:36:55 -0000
Subject: [Openstack-security] [Bug 832507] Re: console.log grows indefinitely
References: <20110824042742.10840.74572.malonedeb@wampee.canonical.com>
Message-ID: <20160426003656.17358.25826.launchpad@soybean.canonical.com>

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

Title:
  console.log grows indefinitely

Status in OpenStack Compute (nova):
  Confirmed
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 gerrit2 at review.openstack.org  Tue Apr 26 10:37:06 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 26 Apr 2016 10:37:06 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Id586b2558fd4c7ed0eda3d3555d51fcd019eb414
Message-ID: <E1av0Mc-000X2N-Rj@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 a557bd3c3c2de7d97f967fe480b9fbcc7e5346f5
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  Tue Apr 26 10:37:13 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 26 Apr 2016 10:37:13 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I64859ad01120782fb17308aac3abb125597c3ea2
Message-ID: <E1av0Mj-000X4S-Ox@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 63f7516fcb5173f0c8576d5f207f7621f2a1c81c
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 gerrit2 at review.openstack.org  Tue Apr 26 18:38:01 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 26 Apr 2016 18:38:01 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I64859ad01120782fb17308aac3abb125597c3ea2
Message-ID: <E1av7s1-000HtX-9Y@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 ac3ce83b7c6866e72f760f3537dfb8c3d967e882
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 sean_mcginnis at dell.com  Thu Apr 28 20:26:51 2016
From: sean_mcginnis at dell.com (Sean McGinnis)
Date: Thu, 28 Apr 2016 20:26:51 -0000
Subject: [Openstack-security] [Bug 1192971] Re: Command execution cases need
	to be strengthened
References: <20130620133506.19620.30523.malonedeb@gac.canonical.com>
Message-ID: <20160428202654.16928.19322.launchpad@soybean.canonical.com>

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

Title:
  Command execution cases need to be strengthened

Status in Cinder:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Grant Murphy from Red Hat Product Security Team reports the following
  potential vulnerability:

  For the most part OpenStack seems to do command execution safely using
  subprocess.Popen. There are two instances where things become a little
  dubious. The first is when shell=True is used with subprocess. This
  doesn't prevent arguments being supplied that allow for multiple
  commands to be executed. e.g. '; cat /etc/passwd'. The second case is
  where commands are made to an external ssh host.

  See attached file for a lit of potential injections: we should double-
  check them (even if I expect most of them to turn false positive)

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



From 1568029 at bugs.launchpad.net  Fri Apr 29 16:21:53 2016
From: 1568029 at bugs.launchpad.net (Jean-Philippe Evrard)
Date: Fri, 29 Apr 2016 16:21:53 -0000
Subject: [Openstack-security] [Bug 1568029] Re: Security: Disable role
	during major version upgrades
References: <20160408161908.32065.20657.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160429162153.5831.95244.malone@chaenomeles.canonical.com>

I'll start with a doc change.

If this requires more work, feel free to add another commit to it.

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

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

Bug description:
  Upgrading between major versions of OpenStack services, such as Kilo
  to Liberty, or Liberty to Mitaka, can be challenging. We should advise
  deployers to consider disabling the openstack-ansible-security role
  during an upgrade to reduce the domain of things to troubleshoot
  during an upgrade.

  This should be in the docs, the upgrade scripts, or both.

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



From 1568029 at bugs.launchpad.net  Fri Apr 29 17:20:22 2016
From: 1568029 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 29 Apr 2016 17:20:22 -0000
Subject: [Openstack-security] [Bug 1568029] Re: Security: Disable role
	during major version upgrades
References: <20160408161908.32065.20657.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160429172022.25623.25220.malone@wampee.canonical.com>

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

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

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

Title:
  Security: Disable role during major version upgrades

Status in openstack-ansible:
  In Progress

Bug description:
  Upgrading between major versions of OpenStack services, such as Kilo
  to Liberty, or Liberty to Mitaka, can be challenging. We should advise
  deployers to consider disabling the openstack-ansible-security role
  during an upgrade to reduce the domain of things to troubleshoot
  during an upgrade.

  This should be in the docs, the upgrade scripts, or both.

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



From 1568029 at bugs.launchpad.net  Fri Apr 29 17:45:26 2016
From: 1568029 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 29 Apr 2016 17:45:26 -0000
Subject: [Openstack-security] [Bug 1568029] Fix proposed to
	openstack-ansible (liberty)
References: <20160408161908.32065.20657.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160429174526.17572.21020.malone@soybean.canonical.com>

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

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

Bug description:
  Upgrading between major versions of OpenStack services, such as Kilo
  to Liberty, or Liberty to Mitaka, can be challenging. We should advise
  deployers to consider disabling the openstack-ansible-security role
  during an upgrade to reduce the domain of things to troubleshoot
  during an upgrade.

  This should be in the docs, the upgrade scripts, or both.

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



From 1568029 at bugs.launchpad.net  Fri Apr 29 17:59:45 2016
From: 1568029 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 29 Apr 2016 17:59:45 -0000
Subject: [Openstack-security] [Bug 1568029] Fix proposed to
	openstack-ansible (master)
References: <20160408161908.32065.20657.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160429175945.5658.45894.malone@chaenomeles.canonical.com>

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

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

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