From gerrit2 at review.openstack.org  Wed Oct  1 01:29:54 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 01 Oct 2014 01:29:54 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I28fdd5268b26b21469889d098f06a82fe188ad1a
Message-ID: <E1XZ8jq-0005UZ-DU@review.openstack.org>


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

Log:
commit cc5943577ad3cbd164e3525847399d705229f833
Author: melanie witt <melwitt at yahoo-inc.com>
Date:   Wed Oct 1 00:42:52 2014 +0000

    use safe SSL connection in xenserver glance plugin
    
    httplib.HTTPSConnection is known to not verify SSL certificates
    in Python 2.x. This change replaces use of httplib.HTTPSConnection
    with the requests module. It uses the existing nova config setting
    "glance.api_insecure" to decide whether or not to verify certs.
    
    SecurityImpact
    DocImpact
    Closes-Bug: #1374001
    
    Change-Id: I28fdd5268b26b21469889d098f06a82fe188ad1a




From thierry.carrez+lp at gmail.com  Wed Oct  1 07:29:53 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 01 Oct 2014 07:29:53 -0000
Subject: [Openstack-security] [Bug 1367238] Re: IBM NAS cinder driver sets
 'rw' permissions to all during volume create operation,
 which is security issue
References: <20140909112305.32185.63569.malonedeb@gac.canonical.com>
Message-ID: <20141001072955.32158.57386.launchpad@gac.canonical.com>

** Changed in: cinder
       Status: Fix Committed => Fix Released

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

Title:
  IBM NAS cinder driver sets 'rw' permissions to all during volume
  create operation, which is security issue

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

Bug description:
  IBM NAS cinder driver sets 'rw' permissions to all during volume create operation from a volume snapshot or from an existing volume (volume clone operation).
  This is not required as 'rw' permissions to the user only should be sufficient.
  This also helps resolve the security issue setting 'rw' permissions to all.

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



From thierry.carrez+lp at gmail.com  Wed Oct  1 07:28:41 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 01 Oct 2014 07:28:41 -0000
Subject: [Openstack-security] [Bug 1321906] Re: [EDP] Swift credentials
	passed in plain text
References: <20140521195819.29499.71748.malonedeb@wampee.canonical.com>
Message-ID: <20141001072844.17942.94654.launchpad@chaenomeles.canonical.com>

** Changed in: sahara
       Status: Fix Committed => Fix Released

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

Title:
  [EDP] Swift credentials passed in plain text

Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Data Processing (Sahara, ex. Savanna):
  Fix Released

Bug description:
  For Sahara, we support job binaries and data sources in Swift.  Job
  binaries are accessed from the Sahara process, and data sources are
  accessed from Hadoop at job execution time.  Username/password
  credentials are required for swift access.  These credentials might
  be/are compromised in the following ways:

  1) For both job binaries and data sources, objects are created and
  stored in the Sahara database that contain the path and the associated
  credentials in plain text.  Anyone gaining access to the database can
  therefore read the username/password credentials stored there with the
  swift path.

  2) For data sources, the credentials are passed as part of the Hadoop
  job configuration.  Currently all Hadoop jobs are run as Oozie
  workflows.  The swift username and password values are set in the
  workflow.xml file, and are visible to anyone that can access the Oozie
  UI console, use the Oozie command line to retrieve the workflow.xml,
  or even use hadoop fs to look at the files uploaded for the job (which
  include the workflow.xml)

  We need a way for Sahara and Hadoop to access swift objects securely,
  without exposing swift credentials in workflow.xml or storing them in
  the database in plain text.  In the future we will support mechanisms
  other than Oozie so this is not just an Oozie issue per se.

  For further background, here is the Hadoop patch that allows Hadoop to
  access swift paths.  It uses a service suffix in the netlocation
  portion of the URL to match the URL against credential values in the
  job configuration.  Any solution to this issue will require a new
  patch to Hadoop itself, as well as changes to the Sahara code base.

  https://issues.apache.org/jira/browse/HADOOP-8545

  It's been suggested within the Sahara team that we can potentially
  accomplish this with trusts.

  Note, this vulnerability isn't really a secret to anyone observant who
  is familiar with Sahara EDP, but it is probably better not to trumpet
  it too loudly.

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



From thierry.carrez+lp at gmail.com  Wed Oct  1 07:35:31 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 01 Oct 2014 07:35:31 -0000
Subject: [Openstack-security] [Bug 1369627] Re: libvirt disk.config will
 have issues when booting two with different config drive values
References: <20140915153310.17745.11485.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141001073535.17709.72829.launchpad@chaenomeles.canonical.com>

** Changed in: nova
       Status: Fix Committed => Fix Released

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

Title:
  libvirt disk.config will have issues when booting two with different
  config drive values

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Currently, in the image creating code for Juno we have

          if configdrive.required_by(instance):
              LOG.info(_LI('Using config drive'), instance=instance)

              image_type = self._get_configdrive_image_type()
              backend = image('disk.config', image_type)
              backend.cache(fetch_func=self._create_configdrive,
                            filename='disk.config' + suffix,
                            instance=instance,
                            admin_pass=admin_pass,
                            files=files,
                            network_info=network_info)

  The important thing to notice here is that we have
  "filename='disk.confg' + suffix".  This means that the filename for
  the config drive in the cache directory will be simply 'disk.config'
  followed by any potential suffix (e.g. '.rescue').  This name is not
  unique to the instance whose config drive we are creating.  Therefore,
  when we go to boot another instance with a different config drive, the
  cache function will detect the old config drive, and decide it doesn't
  need to create the new config drive with the appropriate config for
  the new instance.

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



From thierry.carrez+lp at gmail.com  Wed Oct  1 07:44:35 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 01 Oct 2014 07:44:35 -0000
Subject: [Openstack-security] [Bug 1369487] Re: NIST: increase RSA key
	length to 2048 bit
References: <20140915100120.18130.90286.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141001074438.32158.13219.launchpad@gac.canonical.com>

** Changed in: nova
       Status: Fix Committed => Fix Released

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

Title:
  NIST: increase RSA key length to 2048 bit

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  According to NIST 800-131A, RSA key lenght for digital signature must
  >= 2048 bit.

  In crypto.py, we use 1024 bit as the default key length to generate
  cert file, and does not specify any larger number to override the
  default value when utilizing it.

  def generate_x509_cert(user_id, project_id, bits=1024):

  Need to increase the default key length to 2048 bit.

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



From thierry.carrez+lp at gmail.com  Wed Oct  1 07:43:17 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 01 Oct 2014 07:43:17 -0000
Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache
 poisoning by local attacker
References: <20140715043528.2209.47100.malonedeb@gac.canonical.com>
Message-ID: <20141001074321.479.1425.launchpad@gac.canonical.com>

** Changed in: nova
       Status: Fix Committed => Fix Released

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

Title:
  suds client subject to cache poisoning by local attacker

Status in Cinder:
  Fix Released
Status in Cinder havana series:
  Fix Released
Status in Cinder icehouse series:
  Fix Committed
Status in Gantt:
  New
Status in OpenStack Compute (Nova):
  Fix Released
Status in Oslo VMware library for OpenStack projects:
  Fix Released
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  New

Bug description:
  
  The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. 

  cinder/requirements.txt:suds>=0.4
  gantt/requirements.txt:suds>=0.4
  nova/requirements.txt:suds>=0.4
  oslo.vmware/requirements.txt:suds>=0.4

  
  The details are available here - 
  https://bugzilla.redhat.com/show_bug.cgi?id=978696
  (CVE-2013-2217)

  Although this is an unlikely attack vector steps should be taken to
  prevent this behaviour. Potential ways to fix this are by explicitly
  setting the cache location to a directory created via
  tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or
  using a custom cache implementation that doesn't load / store pickled
  objects from an insecure location.

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



From thierry.carrez+lp at gmail.com  Wed Oct  1 13:54:08 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 01 Oct 2014 13:54:08 -0000
Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent
 does not recreate flows after ovsdb-server restarts
References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com>
Message-ID: <20141001135412.4829.39815.launchpad@wampee.canonical.com>

** Changed in: neutron
       Status: Fix Committed => Fix Released

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

Title:
  neutron-openvswitch-agent does not recreate flows after ovsdb-server
  restarts

Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in neutron icehouse series:
  Fix Released
Status in tripleo - openstack on openstack:
  Fix Released

Bug description:
  The DHCP requests were not being responded to after they were seen on
  the undercloud network interface.  The neutron services were restarted
  in an attempt to ensure they had the newest configuration and knew
  they were supposed to respond to the requests.

  Rather than using the heat stack create (called in
  devtest_overcloud.sh) to test, it was simple to use the following to
  directly boot a baremetal node.

      nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \
            --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \
            bm-test1

  Whilst the baremetal node was attempting to pxe boot a restart of the
  neutron services was performed.  This allowed the baremetal node to
  boot.

  It has been observed that a neutron restart was needed for each
  subsequent reboot of the baremetal nodes to succeed.

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



From 1315556 at bugs.launchpad.net  Wed Oct  1 14:43:14 2014
From: 1315556 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 01 Oct 2014 14:43:14 -0000
Subject: [Openstack-security] [Bug 1315556] Fix proposed to keystone
	(stable/icehouse)
References: <20140502222034.18381.89762.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141001144314.18348.43418.malone@chaenomeles.canonical.com>

Fix proposed to branch: stable/icehouse
Review: https://review.openstack.org/125364

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

Title:
  Disabling a domain does not disable the projects in that domain

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone icehouse series:
  In Progress

Bug description:
  User from an enabled domain can still get a token scoped to a project
  in a disabled domain.

  Steps to reproduce.

  1. create domains "domainA" and "domainB"
  2. create user "userA" and project "projectA" in "domainA"
  3. create user "userB" and project "projectB" in "domainB"
  4. assign "userA" some role for "projectB"
  5. disable "domainB"
  6. authenticate to get a  token for "userA" scoped to "projectB". This should fail as "projectB"'s domain ("domainB") is disabled.

  Looks like the fix would be the check for the project domain to make
  sure it is also enabled. See

  https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py#L112

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



From 1315556 at bugs.launchpad.net  Wed Oct  1 14:44:02 2014
From: 1315556 at bugs.launchpad.net (Dolph Mathews)
Date: Wed, 01 Oct 2014 14:44:02 -0000
Subject: [Openstack-security] [Bug 1315556] Re: Disabling a domain does not
 disable the projects in that domain
References: <20140502222034.18381.89762.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141001144403.25076.39559.launchpad@soybean.canonical.com>

** Also affects: keystone/icehouse
   Importance: Undecided
       Status: New

** Tags removed: havana-backport-potential icehouse-backport-potential
security

** Changed in: keystone/icehouse
       Status: New => In Progress

** Changed in: keystone/icehouse
   Importance: Undecided => High

** Changed in: keystone/icehouse
     Assignee: (unassigned) => Dolph Mathews (dolph)

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

Title:
  Disabling a domain does not disable the projects in that domain

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone icehouse series:
  In Progress

Bug description:
  User from an enabled domain can still get a token scoped to a project
  in a disabled domain.

  Steps to reproduce.

  1. create domains "domainA" and "domainB"
  2. create user "userA" and project "projectA" in "domainA"
  3. create user "userB" and project "projectB" in "domainB"
  4. assign "userA" some role for "projectB"
  5. disable "domainB"
  6. authenticate to get a  token for "userA" scoped to "projectB". This should fail as "projectB"'s domain ("domainB") is disabled.

  Looks like the fix would be the check for the project domain to make
  sure it is also enabled. See

  https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py#L112

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



From gerrit2 at review.openstack.org  Thu Oct  2 01:01:17 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 02 Oct 2014 01:01:17 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I241ca72329f1ec9df778498b346d7b29c224d528
Message-ID: <E1XZUlh-0002jL-HH@review.openstack.org>


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

Log:
commit 55503ecab21d2365c3b0b6c59421cbd79c35cbaf
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Aug 27 17:06:44 2014 -0500

    pki/ssl_setup configurable digest
    
    The digest to use for pki_setup couldn't be configured. The value was
    `default`, which means that the digest was sha1. Some security
    standards require the digest to be stronger (SHA2), so making the
    digest configurable will allow deployments to be compliant.
    
    SecurityImpact
    
    DocImpact
    
    New `message_digest_algorithm` configuration options are added to the
    [signing] and [ssl] sections which default to `default`.
    
    Change-Id: I241ca72329f1ec9df778498b346d7b29c224d528
    Closes-Bug: #1362343




From gerrit2 at review.openstack.org  Thu Oct  2 01:01:23 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 02 Oct 2014 01:01:23 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I9e42c9bafc307ba1334fa641bab76f251722044d
Message-ID: <E1XZUln-0002jq-Ea@review.openstack.org>


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

Log:
commit 9ec6bd51f16823cec3fcf74e9cb2f7739af04701
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Aug 27 17:11:06 2014 -0500

    Change the default digest for pki/ssl_setup to sha256
    
    The default digest was `default`, which meant that the digest was the
    openssl default of sha1. The default setting should be a SHA2
    algorithm since this meets current security standards.
    
    This is for security hardening.
    
    SecurityImpact
    
    DocImpact
    
    The `default_message_digest` configuration options now default to
    `sha256` instead of `default`.
    
    Change-Id: I9e42c9bafc307ba1334fa641bab76f251722044d
    Related-Bug: #1362343




From gerrit2 at review.openstack.org  Thu Oct  2 21:23:13 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 02 Oct 2014 21:23:13 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I241ca72329f1ec9df778498b346d7b29c224d528
Message-ID: <E1XZnqD-00072f-Oi@review.openstack.org>


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

Log:
commit 090bedbb55862944c8298ee366821349969a6df9
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Aug 27 17:06:44 2014 -0500

    pki/ssl_setup configurable digest
    
    The digest to use for pki_setup couldn't be configured. The value was
    `default`, which means that the digest was sha1. Some security
    standards require the digest to be stronger (SHA2), so making the
    digest configurable will allow deployments to be compliant.
    
    SecurityImpact
    
    DocImpact
    
    New `message_digest_algorithm` configuration options are added to the
    [signing] and [ssl] sections which default to `default`.
    
    Change-Id: I241ca72329f1ec9df778498b346d7b29c224d528
    Closes-Bug: #1362343




From gerrit2 at review.openstack.org  Thu Oct  2 21:23:19 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 02 Oct 2014 21:23:19 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I9e42c9bafc307ba1334fa641bab76f251722044d
Message-ID: <E1XZnqJ-00073C-4V@review.openstack.org>


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

Log:
commit 58483551fcf360da11f595b9c7b39ff2d1d27896
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Aug 27 17:11:06 2014 -0500

    Change the default digest for pki/ssl_setup to sha256
    
    The default digest was `default`, which meant that the digest was the
    openssl default of sha1. The default setting should be a SHA2
    algorithm since this meets current security standards.
    
    This is for security hardening.
    
    SecurityImpact
    
    DocImpact
    
    The `default_message_digest` configuration options now default to
    `sha256` instead of `default`.
    
    Change-Id: I9e42c9bafc307ba1334fa641bab76f251722044d
    Related-Bug: #1362343




From bknudson at us.ibm.com  Thu Oct  2 22:14:59 2014
From: bknudson at us.ibm.com (Brant Knudson)
Date: Thu, 02 Oct 2014 22:14:59 -0000
Subject: [Openstack-security] [Bug 1329301] Re: Update how tokens are
	redacted
References: <20140612121824.4650.65306.malonedeb@wampee.canonical.com>
Message-ID: <20141002221500.24875.20573.launchpad@soybean.canonical.com>

** Also affects: python-keystoneclient
   Importance: Undecided
       Status: New

** Changed in: python-keystoneclient
     Assignee: (unassigned) => Brant Knudson (blk-u)

** Changed in: python-keystoneclient
       Status: New => In Progress

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

Title:
  Update how tokens are redacted

Status in Python client library for Glance:
  Fix Released
Status in Python client library for Keystone:
  In Progress

Bug description:
  We should move from this approach:

  https://review.openstack.org/#/c/83350/

  to whatever cross-project approach is agreed upon:

  See this thread:

  http://lists.openstack.org/pipermail/openstack-
  dev/2014-June/037345.html

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



From 1329301 at bugs.launchpad.net  Thu Oct  2 22:56:32 2014
From: 1329301 at bugs.launchpad.net (Dolph Mathews)
Date: Thu, 02 Oct 2014 22:56:32 -0000
Subject: [Openstack-security] [Bug 1329301] Re: Update how tokens are
 redacted from plaintext exposure
References: <20140612121824.4650.65306.malonedeb@wampee.canonical.com>
Message-ID: <20141002225632.17842.42353.launchpad@chaenomeles.canonical.com>

** Summary changed:

- Update how tokens are redacted
+ Update how tokens are redacted from plaintext exposure

** Changed in: python-keystoneclient
   Importance: Undecided => Low

** Changed in: python-glanceclient
   Importance: Undecided => Low

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

Title:
  Update how tokens are redacted from plaintext exposure

Status in Python client library for Glance:
  Fix Released
Status in Python client library for Keystone:
  In Progress

Bug description:
  We should move from this approach:

  https://review.openstack.org/#/c/83350/

  to whatever cross-project approach is agreed upon:

  See this thread:

  http://lists.openstack.org/pipermail/openstack-
  dev/2014-June/037345.html

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



From 1341954 at bugs.launchpad.net  Thu Oct  2 23:42:40 2014
From: 1341954 at bugs.launchpad.net (Adam Gandelman)
Date: Thu, 02 Oct 2014 23:42:40 -0000
Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache
 poisoning by local attacker
References: <20140715043528.2209.47100.malonedeb@gac.canonical.com>
Message-ID: <20141002234244.32158.88522.launchpad@gac.canonical.com>

** Changed in: cinder/icehouse
       Status: Fix Committed => Fix Released

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

Title:
  suds client subject to cache poisoning by local attacker

Status in Cinder:
  Fix Released
Status in Cinder havana series:
  Fix Released
Status in Cinder icehouse series:
  Fix Released
Status in Gantt:
  New
Status in OpenStack Compute (Nova):
  Fix Released
Status in Oslo VMware library for OpenStack projects:
  Fix Released
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  New

Bug description:
  
  The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. 

  cinder/requirements.txt:suds>=0.4
  gantt/requirements.txt:suds>=0.4
  nova/requirements.txt:suds>=0.4
  oslo.vmware/requirements.txt:suds>=0.4

  
  The details are available here - 
  https://bugzilla.redhat.com/show_bug.cgi?id=978696
  (CVE-2013-2217)

  Although this is an unlikely attack vector steps should be taken to
  prevent this behaviour. Potential ways to fix this are by explicitly
  setting the cache location to a directory created via
  tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or
  using a custom cache implementation that doesn't load / store pickled
  objects from an insecure location.

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



From 1334926 at bugs.launchpad.net  Thu Oct  2 23:47:44 2014
From: 1334926 at bugs.launchpad.net (Adam Gandelman)
Date: Thu, 02 Oct 2014 23:47:44 -0000
Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working
 once connected even after it is disociated
References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com>
Message-ID: <20141002234748.5401.82442.launchpad@wampee.canonical.com>

** Changed in: neutron/icehouse
       Status: Fix Committed => Fix Released

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

Title:
  floatingip still working once connected even after it is disociated

Status in OpenStack Neutron (virtual network service):
  Fix Committed
Status in neutron icehouse series:
  Fix Released
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  After we create an SSH connection to a VM via its floating ip, even
  though we have removed the floating ip association, we can still
  access the VM via that connection. Namely, SSH is not disconnected
  when the floating ip is not valid

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



From thierry.carrez+lp at gmail.com  Fri Oct  3 06:53:03 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Fri, 03 Oct 2014 06:53:03 -0000
Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working
 once connected even after it is disociated
References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com>
Message-ID: <20141003065307.341.49530.launchpad@gac.canonical.com>

** Changed in: neutron
       Status: Fix Committed => Fix Released

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

Title:
  floatingip still working once connected even after it is disociated

Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in neutron icehouse series:
  Fix Released
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  After we create an SSH connection to a VM via its floating ip, even
  though we have removed the floating ip association, we can still
  access the VM via that connection. Namely, SSH is not disconnected
  when the floating ip is not valid

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



From nkinder at redhat.com  Fri Oct  3 20:29:43 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Fri, 03 Oct 2014 20:29:43 -0000
Subject: [Openstack-security] [Bug 1337349] Re: Nova qemu hypervisor host
 smbios serial number is leaked to guest
References: <20140703142824.27562.82896.malonedeb@gac.canonical.com>
Message-ID: <20141003202944.5494.1355.malone@wampee.canonical.com>

This issue has been published as OSSN-0028:

  https://wiki.openstack.org/wiki/OSSN/OSSN-0028

** Changed in: ossn
       Status: In Progress => Fix Released

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

Title:
  Nova qemu hypervisor host smbios serial number is leaked to guest

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  Erwan Velu from eNovance reported a vulnerability in OpenStack Nova.

  The hypervisor is passing host system uuid (-smbios version) to guests, and this happen to be a critical info leak.
  The defect have been pinpointed to:
   https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3054

  From a simple virtual machine, this may allow numerous info leak like:
      Allow compute hardware enumeration from guests
      Deduce service tag and get all hardware configuration
      Ability to know if two instances are on the same compute

  Dell hardware is particulary impacted as :
      - the uuid encodes the service tag
      - the service tag can be used on support site to determine:
      - detailled hardware configuration
      - date & country where the hw was shipped
      - date & type of support contract
      - amount of servers bought during this shipment

  If there is no use case for this, we should scrambled that piece of
  information.

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



From gerrit2 at review.openstack.org  Sat Oct  4 10:32:52 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Sat, 04 Oct 2014 10:32:52 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I0b8e6319a4cc39876b1e396ef705f0fc5def1e44
Message-ID: <E1XaMdw-0004ab-VF@review.openstack.org>


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

Log:
commit cc88417637e4967860619e8d7e43f5d28957fcda
Author: Sylvain Bauza <sbauza at redhat.com>
Date:   Mon Sep 29 13:33:50 2014 +0200

    Fix unsafe SSL connection on TrustedFilter
    
    TrustedFilter was using httplib which doesn't check for CAs.
    Here the change is using Requests and verifies local CAs by default (or another
    one if provided)
    This effort is related to CVE 2013-2255.
    
    SecurityImpact
    
    Closes-Bug: #1373993
    
    Change-Id: I0b8e6319a4cc39876b1e396ef705f0fc5def1e44
    (cherry picked from commit 30871e8702737edbbfbcbbb5f21858873b37685c)




From robert.clark at hp.com  Sat Oct  4 11:48:52 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Sat, 4 Oct 2014 11:48:52 +0000
Subject: [Openstack-security] Elections for OSSG lead
Message-ID: <A0C170085C37664D93EE1604364858A112472CD8@G4W3300.americas.hpqcorp.net>

Hi All,

 

It gives me great pleasure to open the election process for OSSG leadership. 

 

This is the second time the OSSG has had the opportunity to elect leadership since the OSSG began nearly three years ago.  The term
for this position will begin at the Kilo Summit in Paris (November 2014) and end at the 'L' Summit in Vancouver (May 2015). The
elected leader will be responsible for holding a new election to fill the OSSG Lead position for the following term. There are no
term limits (an individual may be re-elected as many times as the community chooses).

 

Any member of the election electorate (see wiki for details) can propose his/her candidacy for the same election. No nomination is
required. They do so by sending an email to the openstack-security at lists.openstack.org mailing-list, using the subject: "OSSG Lead
Candidacy". The email may include a description of the candidate platform. The candidacy is then confirmed by one of the election
officials, after verification of the electorate status of the candidate.

 

Please read more at the wiki entry here: http://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Fall_2014 

 

Thank you all for being a part of the community and good luck to all the candidates!

 

-Rob

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141004/ce7f52b5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6187 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141004/ce7f52b5/attachment.bin>

From 1174499 at bugs.launchpad.net  Sat Oct  4 22:50:00 2014
From: 1174499 at bugs.launchpad.net (Akihiro Motoki)
Date: Sat, 04 Oct 2014 22:50:00 -0000
Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20141004225000.18243.83493.malone@chaenomeles.canonical.com>

The required fix in Horizon side is just an update of the example settings file and the documentation of the new parameter.
Thus I think it is a good candidate for Juno-RC2 (we already plan RC2 for translation import).

** Tags added: juno-rc-potential

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

Title:
  Keystone token hashing is MD5

Status in Django OpenStack Auth:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  Fix Released

Bug description:
  https://github.com/openstack/python-
  keystoneclient/blob/master/keystoneclient/common/cms.py

  def cms_hash_token(token_id):
      """
  return: for ans1_token, returns the hash of the passed in token
  otherwise, returns what it was passed in.
  """
      if token_id is None:
          return None
      if is_ans1_token(token_id):
          hasher = hashlib.md5()
          hasher.update(token_id)
          return hasher.hexdigest()
      else:
          return token_id

  
  MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256.
  Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use.

To manage notifications about this bug go to:
https://bugs.launchpad.net/django-openstack-auth/+bug/1174499/+subscriptions



From fungi at yuggoth.org  Mon Oct  6 14:42:22 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 06 Oct 2014 14:42:22 -0000
Subject: [Openstack-security] [Bug 1375599] Re: Cinder should not publish
 sensitive data such as user token in notifications.
References: <20140930070610.4767.44598.malonedeb@wampee.canonical.com>
Message-ID: <20141006144224.18243.42414.launchpad@chaenomeles.canonical.com>

** Tags added: security

** Changed in: ossa
       Status: Incomplete => Won't Fix

** Information type changed from Public Security to Public

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

Title:
  Cinder should not publish sensitive data such as user token in
  notifications.

Status in Cinder:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Here is a message captured in rabbitmq:

  ctxt: {u'domain': None, u'project_name': u'admin', u'user_id': u'f6fafd3282a841849a01beeb80fd3161', u'roles': [u'heat_stack_owner', u'_member_', u'admin'], u'user_identity': u'f6fafd3282a841849a01beeb80fd3161 d6acdbfa2bba426c912f214c665e78d9 - - -', u'project_domain': None, u'timestamp': u'2014-09-25T07:01:02.936829', u'auth_token': u'bac7c01f4eb1412b841ab819ceddc5ad', u'remote_address': u'19.0.0.99', u'quota_class': None, u'project_id': u'd6acdbfa2bba426c912f214c665e78d9', u'is_admin': True, u'user': u'f6fafd3282a841849a01beeb80fd3161', u'service_catalog': [{u'endpoints': [{u'adminURL': u'http://19.0.0.99:8774/v2/d6acdbfa2bba426c912f214c665e78d9', u'region': u'RegionOne', u'internalURL': u'http://19.0.0.99:8774/v2/d6acdbfa2bba426c912f214c665e78d9', u'publicURL': u'http://19.0.0.99:8774/v2/d6acdbfa2bba426c912f214c665e78d9'}], u'type': u'compute', u'name': u'nova'}], u'request_id': u'req-623ecb62-0660-4264-b0d3-04eb13f54914', u'user_domain': None, u'read_deleted': u'no', u'tenant': u'd6acdbfa2bba426c912f214c665e78d9'}
  publisher_id: volume.aj-celiometer at lvmdriver-1
  event_type: volume.delete.end
  payload: {u'status': u'deleting', u'instance_uuid': None, u'user_id': u'f6fafd3282a841849a01beeb80fd3161', u'availability_zone': u'nova', u'tenant_id': u'd6acdbfa2bba426c912f214c665e78d9', u'created_at': u'2014-09-24 14:11:42', u'snapshot_id': None, u'volume_type': u'0bc2a44a-fd19-4448-8399-1538fc8724e5', u'host': u'aj-celiometer at lvmdriver-1#lvmdriver-1', u'replication_status': u'disabled', u'volume_id': u'25102eee-9e82-4ba8-8f8c-17bc52c6519f', u'replication_extended_status': None, u'replication_driver_data': None, u'size': 1, u'launched_at': u'2014-09-24 14:11:42', u'display_name': None}
  metadata: {'timestamp': u'2014-09-25 07:01:19.271715', 'message_id': u'9c77a382-05c2-4014-a1a9-cbc41b2d2eb7'}

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



From fungi at yuggoth.org  Mon Oct  6 14:52:39 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 06 Oct 2014 14:52:39 -0000
Subject: [Openstack-security] [Bug 1372643] Re: MITM vulnerability with XIV
	driver
References: <20140922204545.32411.9337.malonedeb@gac.canonical.com>
Message-ID: <20141006145239.25513.51490.malone@soybean.canonical.com>

This looks like another in the vein of bug 1188189 which we've so far
considered a security hardening opportunity, no advisory warranted.

** Information type changed from Private Security to Public

** Tags added: security

** Changed in: ossa
       Status: Incomplete => Won't Fix

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

Title:
  MITM vulnerability with XIV driver

Status in Cinder:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The XIV driver in Juno appears to blindly trust whatever certificate
  it gets back from the device without any validation. This would leave
  it open to a MITM attack.

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



From fungi at yuggoth.org  Mon Oct  6 15:51:53 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 06 Oct 2014 15:51:53 -0000
Subject: [Openstack-security] [Bug 1372643] Re: MITM vulnerability with XIV
	driver
References: <20140922204545.32411.9337.malonedeb@gac.canonical.com>
Message-ID: <20141006155153.25282.39843.malone@soybean.canonical.com>

Granted the position is worth revisiting. Are we to the point where
we're ready as a project to declare victory on bug 1188189 now and
consider anything else which doesn't encrypt internal communications or
fails to validate server certificates (for SSL sockets, SSH, et cetera)
a surprise to the community and worth individual security advisories and
mandatory stable backports going forward?

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

Title:
  MITM vulnerability with XIV driver

Status in Cinder:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The XIV driver in Juno appears to blindly trust whatever certificate
  it gets back from the device without any validation. This would leave
  it open to a MITM attack.

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



From 1163569 at bugs.launchpad.net  Mon Oct  6 16:39:51 2014
From: 1163569 at bugs.launchpad.net (Doug Chivers)
Date: Mon, 06 Oct 2014 16:39:51 -0000
Subject: [Openstack-security] [Bug 1163569] Re: security groups don't work
	with vip and ovs plugin
References: <20130402204346.20639.18981.malonedeb@wampee.canonical.com>
Message-ID: <20141006163954.32158.55127.launchpad@gac.canonical.com>

** Changed in: ossn
     Assignee: (unassigned) => Doug Chivers (doug-chivers)

** Changed in: ossn
   Importance: Undecided => High

** Changed in: ossn
       Status: New => In Progress

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

Title:
  security groups don't work with vip and ovs plugin

Status in OpenStack Neutron (virtual network service):
  In Progress
Status in OpenStack Security Notes:
  In Progress

Bug description:
  http://codepad.org/xU8G4s00

  I pinged nachi and he suggested to try using:

  interface_driver = quantum.agent.linux.interface.BridgeInterfaceDriver

  But after setting this it seems like the vip does not work at all.

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



From 1174499 at bugs.launchpad.net  Mon Oct  6 16:48:18 2014
From: 1174499 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 06 Oct 2014 16:48:18 -0000
Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20141006164818.32642.76511.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/116510
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=372d033d89c0f5d305959a6ad5fd3e1159cc91ed
Submitter: Jenkins
Branch:    master

commit 372d033d89c0f5d305959a6ad5fd3e1159cc91ed
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Sun Aug 24 10:04:10 2014 -0500

    Document token hash algorithm option
    
    With https://review.openstack.org/#/c/116509/ ,
    django-openstack-auth will support a new option for the token hash
    algorithm. This adds the documentation to Horizon's local settings
    example file.
    
    This is for security hardening. The token hash algorithm defaults
    to MD5, which is considered too weak due to the potential for hash
    collisions. Some security standards require a SHA2 hash algorithm to
    be used.
    
    DocImpact
    SecurityImpact
    
    Change-Id: I6774b9b7215d191259586e4721e357487bb777cd
    Closes-Bug: #1174499


** Changed in: horizon
       Status: In Progress => Fix Committed

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

Title:
  Keystone token hashing is MD5

Status in Django OpenStack Auth:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Committed
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  Fix Released

Bug description:
  https://github.com/openstack/python-
  keystoneclient/blob/master/keystoneclient/common/cms.py

  def cms_hash_token(token_id):
      """
  return: for ans1_token, returns the hash of the passed in token
  otherwise, returns what it was passed in.
  """
      if token_id is None:
          return None
      if is_ans1_token(token_id):
          hasher = hashlib.md5()
          hasher.update(token_id)
          return hasher.hexdigest()
      else:
          return token_id

  
  MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256.
  Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use.

To manage notifications about this bug go to:
https://bugs.launchpad.net/django-openstack-auth/+bug/1174499/+subscriptions



From fungi at yuggoth.org  Mon Oct  6 19:33:19 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 06 Oct 2014 19:33:19 -0000
Subject: [Openstack-security] [Bug 1372643] Re: MITM vulnerability with XIV
	driver
References: <20140922204545.32411.9337.malonedeb@gac.canonical.com>
Message-ID: <20141006193321.479.12331.launchpad@gac.canonical.com>

** Changed in: cinder
     Assignee: (unassigned) => Alon Marx (alonma)

** Changed in: ossa
     Assignee: Alon Marx (alonma) => (unassigned)

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

Title:
  MITM vulnerability with XIV driver

Status in Cinder:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The XIV driver in Juno appears to blindly trust whatever certificate
  it gets back from the device without any validation. This would leave
  it open to a MITM attack.

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



From gerrit2 at review.openstack.org  Mon Oct  6 22:31:27 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 06 Oct 2014 22:31:27 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I8e46d41164e9478b820cad569ba82f25de244620
Message-ID: <E1XbGoR-0007B0-79@review.openstack.org>


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

Log:
commit 789ad9cba93bc264ee0e89db5be40b26dece9872
Author: melanie witt <melwitt at yahoo-inc.com>
Date:   Fri Sep 26 05:15:16 2014 +0000

    replace httplib.HTTPSConnection in EC2KeystoneAuth
    
    httplib.HTTPSConnection is known to not verify SSL certificates
    in Python 2.x. This change replaces use of httplib.HTTPSConnection
    with the requests module. It imports config settings related to SSL
    verification: ssl.key_file, ssl.cert_file, and ssl.ca_file. It also
    adds one config setting: keystone_ec2_insecure. By default, SSL
    verification is on, but can be disabled by setting:
    
    keystone_ec2_insecure=true
    
    This patch is based on the keystone middleware ec2 token patch:
    
    https://review.openstack.org/#/c/76476
    
    SecurityImpact
    DocImpact
    Closes-Bug: #1373992
    
    Change-Id: I8e46d41164e9478b820cad569ba82f25de244620




From sam at code-smash.net  Wed Oct  1 11:55:29 2014
From: sam at code-smash.net (Sam Betts)
Date: Wed, 01 Oct 2014 11:55:29 -0000
Subject: [Openstack-security] [Bug 1369876] Re: Missing HttpOnly Attribute
	in Session Cookie
References: <20140916064453.32545.92390.malonedeb@gac.canonical.com>
Message-ID: <20141001115529.25484.1253.malone@soybean.canonical.com>

As far as I can tell in master right now SESSION_COOKIE_HTTPONLY = True
which should add httponly to all session cookies.

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

Title:
  Missing HttpOnly Attribute in Session Cookie

Status in OpenStack Dashboard (Horizon):
  Confirmed

Bug description:
  Affected URL: https://Ip_address/admin/
  Entity: csrftoken (Cookie)
  Risk: It is possible to steal or manipulate customer session and cookies, which might be used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user.
  Causes: The web application sets session cookies without the HttpOnly attribute
  Recommend Fix: Add the 'HttpOnly' attribute to all session cookies.

  The Test Requests and Responses:
  GET /admin/ HTTP/1.1
  Host: 9.5.29.52
  User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
  Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
  Accept-Language: en-US,en;q=0.5
  Referer: https://9.5.29.52/
  Cookie: csrftoken=JPjBiDp6Ex6YDw3sgfZPCTPUwWKZdZTm; sessionid=oad3bpy15qm8ntml9wx604yr79cc6zpb
  Connection: keep-alive
  HTTP/1.1 200 OK
  Date: Fri, 12 Sep 2014 07:52:50 GMT
  Server: Apache
  Vary: Accept-Language,Cookie,Accept-Encoding
  X-Frame-Options: SAMEORIGIN
  Content-Language: en
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive
  2014/9/12 504
  Transfer-Encoding: chunked
  Content-Type: text/html
  Set-Cookie: csrftoken=silTP6ARbLvXohF6YYFLlWHce0KZkjPy; expires=Fri, 11-Sep-2015 07:52:52 GMT; Max-Age=31449600; Path=/; secure
  Set-Cookie: sessionid=ygq094phgr6og471j6n0asq7x6q37j6n; httponly; Path=/; secure
  <!DOCTYPE html>
  <html>
  <head>
  <meta content='text/html; charset=utf-8' http-equiv='Content-Type' />
  <title>Usage Overview - Cloud Management Dashboard</title>
  <!--
  Copyright 2014 *** Corp.
  -->
  <link rel="stylesheet" href="/static/dashboard/css/5730bed76fd3.css" type="text/css" media="screen" />
  <link rel="shortcut icon" href="/static/dashboard/img/favicon.png"/>
  <!--
  Fix header padding issue in IE < 10
  -->
  <!--[if lt IE 10 ]>
  <style>
  .topbar {
  padding-bottom: 0px;
  }
  </style>
  <![endif]-->
  <script type="text/javascript" src="/static/dashboard/js/841198948869.js"></script>
  <script type="text/javascript" charset="utf-8">
  /*
  Added so that we can append Horizon scoped JS events to
  the DOM load events without running in to the "horizon"
  name-space not currently being defined since we load the
  scripts at the bottom of the page.
  */
  var addHorizonLoadEvent = function(func) {
  var old_onload = window.onload;
  if (typeof window.onload != 'function') {
  window.onload = func;
  } else {
  window.onload = function() {
  old_onload();
  func();
  }
  }
  }
  </script>
  </head>
  <body id="" ng-app='hz'>
  <div id="container">
  <div class='topbar'>
  <!--
  Copyright 2014 ***Corp.
  -->
  <h1 class="brand"><a href="/home/">Cloud Management Dashboard</a></h1>
  <div id="user_info" class="pull-right">
  <div id="tenant_switcher" class="dropdown switcher_bar hide_image " tabindex="1">
  <div>admin</div>
  </div>
  <div id="profile_editor_switcher" class="dropdown switcher_bar" tabindex='1'>
  <a class="dropdown-toggle" data-toggle="dropdown" href="#profile_editor_switcher">
  <div>admin</div>
  </a>
  <ul id="editor_list" class="dropdown-menu">
  <li class='divider'></li>
  <li><a href="/settings/">Settings</a></li>
  2014/9/12 505
  TOC
  <li><a href="http://docs.openstack.org" target="_new">Help</a></li>
  <li><a href="/auth/logout/">Sign Out</a></li>
  </ul>
  </div>
  <img class="brand_icon" src="/static/dashboard/img/logo.png" alt=""/>
  </div>
  </div>
  <div id='main_content'>
  <div class="messages">
  </div>
  <div class='sidebar'>
  <div>
  <dl class="nav_accordion">
  <dt >
  <div>Project</div>
  </dt>
  <dd style="display:none;">
  <div><h4><div>Compute</div></h4>
  <ul>
  <li><a href="/project/" tabindex="1" >Overview</a></li>
  <li><a href="/project/instances/" tabindex="2" >Instances</a></li>
  <li><a href="/project/volumes/" tabindex="3" >Volumes</a></li>
  <li><a href="/project/images/" tabindex="4" >Images</a></li>
  <li><a href="/project/access_and_security/" tabindex="5" >Access &amp; Security</a></li>
  </ul>
  </div>
  <div><h4><div>Network</div></h4>
  <ul>
  <li><a href="/project/network_topology/" tabindex="1" >Network Topology</a></li>
  <li><a href="/project/networks/" tabindex="2" >Networks</a></li>
  <li><a href="/project/routers/" tabindex="3" >Routers</a></li>
  </ul>
  </div>
  <div><h4><div>Orchestration</div></h4>
  <ul>
  <li><a href="/project/stacks/" tabindex="1" >Stacks</a></li>
  </ul>
  </div>
  ...
  ...
  ...

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



From 1375857 at bugs.launchpad.net  Fri Oct  3 13:19:13 2014
From: 1375857 at bugs.launchpad.net (Dolph Mathews)
Date: Fri, 03 Oct 2014 13:19:13 -0000
Subject: [Openstack-security] [Bug 1375857] Re: It's not possibile to pass
 the cacert to the swift store
References: <20140930152151.17678.6371.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141003131914.32257.75075.launchpad@gac.canonical.com>

** Tags removed: swift

** Tags added: security swift

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

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

Title:
  It's not possibile to pass the cacert to the swift store

Status in OpenStack Image Registry and Delivery Service (Glance):
  In Progress

Bug description:
  The swift store device defined in the glance store doesn't allow to pass the ca cert file. When the driver creates a connection via the swift client it is not possible to pass that value. 
  That means that if we have swift running on TLS in some cases we have to set the insecure option equals to True as the client can't correctly complete the handshake as it fails on the verification of the cert.

  The fix I'd like to propose is to add a new parameter to define the ca
  cert file and pass this value when we create the connection via the
  swift client.

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



From 1372375 at bugs.launchpad.net  Sat Oct  4 14:36:13 2014
From: 1372375 at bugs.launchpad.net (John Griffith)
Date: Sat, 04 Oct 2014 14:36:13 -0000
Subject: [Openstack-security] [Bug 1372375] Re: Attaching LVM encrypted
 volumes (with LUKS) could cause data loss if LUKS headers get corrupted
References: <20140922095132.18315.85937.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141004143613.25207.10206.malone@soybean.canonical.com>

Adding a flag seems reasonable, I'm actually undecided however if that
should be a new key in the DB or perhaps just some admin-meta.  My
preference here would be admin-meta and I believe that would work here.

I'm also not sure how the implementation would end up looking, first
glance it seems like it would be fairly clean to add the check

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

Title:
  Attaching LVM encrypted volumes (with LUKS) could cause data loss if
  LUKS headers get corrupted

Status in Cinder:
  New
Status in OpenStack Compute (Nova):
  Incomplete
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  I have doubts about the flow of the volume attaching operation, as
  defined in /usr/lib/python2.6/site-
  packages/nova/volume/encryptors/luks.py.

  If the device is not recognized to be a valid luks device, the script is luks formatting it! So if for some reason the luks header get corrupted, it erases the whole data.
  To manage corrupted headers there are the 

      cryptsetup luksHeaderBackup

  and

      cryptsetup luksHeaderRestore

  commands that respectively do the backup and the restore of the
  headers.

  I think that the process has to be reviewed, and the luksFormat
  operation has to be performed during the volume creation.

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



From drfish at us.ibm.com  Mon Oct  6 13:28:03 2014
From: drfish at us.ibm.com (Doug Fish)
Date: Mon, 06 Oct 2014 13:28:03 -0000
Subject: [Openstack-security] [Bug 1369876] Re: Missing HttpOnly Attribute
	in Session Cookie
References: <20140916064453.32545.92390.malonedeb@gac.canonical.com>
Message-ID: <20141006132803.32745.39706.malone@gac.canonical.com>

Django 1.6 introduces a new setting to make the crsf cookie (which is separate from the session cookie) httpreadonly.
https://docs.djangoproject.com/en/1.6/ref/settings/#csrf-cookie-httponly

Our docs say to use it
https://github.com/openstack/horizon/blob/a0f7235278cfe187b2ff31bfb787548735111c8b/doc/source/topics/deployment.rst#secure-site-recommendations
so I assume it has been tested and works (offhand, I wasn't sure if our javascript was ever used to extract and send that value in a form), on the other hand our documentation suggests this has been available since 1.4, which is wrong.  So that's not exactly confidence inspiring.

@Zhang Yun, can you verify that setting
CSRF_COOKIE_HTTPONLY = True in you local_settings file addresses your concern?

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

Title:
  Missing HttpOnly Attribute in Session Cookie

Status in OpenStack Dashboard (Horizon):
  Confirmed

Bug description:
  Affected URL: https://Ip_address/admin/
  Entity: csrftoken (Cookie)
  Risk: It is possible to steal or manipulate customer session and cookies, which might be used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user.
  Causes: The web application sets session cookies without the HttpOnly attribute
  Recommend Fix: Add the 'HttpOnly' attribute to all session cookies.

  The Test Requests and Responses:
  GET /admin/ HTTP/1.1
  Host: 9.5.29.52
  User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
  Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
  Accept-Language: en-US,en;q=0.5
  Referer: https://9.5.29.52/
  Cookie: csrftoken=JPjBiDp6Ex6YDw3sgfZPCTPUwWKZdZTm; sessionid=oad3bpy15qm8ntml9wx604yr79cc6zpb
  Connection: keep-alive
  HTTP/1.1 200 OK
  Date: Fri, 12 Sep 2014 07:52:50 GMT
  Server: Apache
  Vary: Accept-Language,Cookie,Accept-Encoding
  X-Frame-Options: SAMEORIGIN
  Content-Language: en
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive
  2014/9/12 504
  Transfer-Encoding: chunked
  Content-Type: text/html
  Set-Cookie: csrftoken=silTP6ARbLvXohF6YYFLlWHce0KZkjPy; expires=Fri, 11-Sep-2015 07:52:52 GMT; Max-Age=31449600; Path=/; secure
  Set-Cookie: sessionid=ygq094phgr6og471j6n0asq7x6q37j6n; httponly; Path=/; secure
  <!DOCTYPE html>
  <html>
  <head>
  <meta content='text/html; charset=utf-8' http-equiv='Content-Type' />
  <title>Usage Overview - Cloud Management Dashboard</title>
  <!--
  Copyright 2014 *** Corp.
  -->
  <link rel="stylesheet" href="/static/dashboard/css/5730bed76fd3.css" type="text/css" media="screen" />
  <link rel="shortcut icon" href="/static/dashboard/img/favicon.png"/>
  <!--
  Fix header padding issue in IE < 10
  -->
  <!--[if lt IE 10 ]>
  <style>
  .topbar {
  padding-bottom: 0px;
  }
  </style>
  <![endif]-->
  <script type="text/javascript" src="/static/dashboard/js/841198948869.js"></script>
  <script type="text/javascript" charset="utf-8">
  /*
  Added so that we can append Horizon scoped JS events to
  the DOM load events without running in to the "horizon"
  name-space not currently being defined since we load the
  scripts at the bottom of the page.
  */
  var addHorizonLoadEvent = function(func) {
  var old_onload = window.onload;
  if (typeof window.onload != 'function') {
  window.onload = func;
  } else {
  window.onload = function() {
  old_onload();
  func();
  }
  }
  }
  </script>
  </head>
  <body id="" ng-app='hz'>
  <div id="container">
  <div class='topbar'>
  <!--
  Copyright 2014 ***Corp.
  -->
  <h1 class="brand"><a href="/home/">Cloud Management Dashboard</a></h1>
  <div id="user_info" class="pull-right">
  <div id="tenant_switcher" class="dropdown switcher_bar hide_image " tabindex="1">
  <div>admin</div>
  </div>
  <div id="profile_editor_switcher" class="dropdown switcher_bar" tabindex='1'>
  <a class="dropdown-toggle" data-toggle="dropdown" href="#profile_editor_switcher">
  <div>admin</div>
  </a>
  <ul id="editor_list" class="dropdown-menu">
  <li class='divider'></li>
  <li><a href="/settings/">Settings</a></li>
  2014/9/12 505
  TOC
  <li><a href="http://docs.openstack.org" target="_new">Help</a></li>
  <li><a href="/auth/logout/">Sign Out</a></li>
  </ul>
  </div>
  <img class="brand_icon" src="/static/dashboard/img/logo.png" alt=""/>
  </div>
  </div>
  <div id='main_content'>
  <div class="messages">
  </div>
  <div class='sidebar'>
  <div>
  <dl class="nav_accordion">
  <dt >
  <div>Project</div>
  </dt>
  <dd style="display:none;">
  <div><h4><div>Compute</div></h4>
  <ul>
  <li><a href="/project/" tabindex="1" >Overview</a></li>
  <li><a href="/project/instances/" tabindex="2" >Instances</a></li>
  <li><a href="/project/volumes/" tabindex="3" >Volumes</a></li>
  <li><a href="/project/images/" tabindex="4" >Images</a></li>
  <li><a href="/project/access_and_security/" tabindex="5" >Access &amp; Security</a></li>
  </ul>
  </div>
  <div><h4><div>Network</div></h4>
  <ul>
  <li><a href="/project/network_topology/" tabindex="1" >Network Topology</a></li>
  <li><a href="/project/networks/" tabindex="2" >Networks</a></li>
  <li><a href="/project/routers/" tabindex="3" >Routers</a></li>
  </ul>
  </div>
  <div><h4><div>Orchestration</div></h4>
  <ul>
  <li><a href="/project/stacks/" tabindex="1" >Stacks</a></li>
  </ul>
  </div>
  ...
  ...
  ...

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



From drfish at us.ibm.com  Mon Oct  6 13:35:42 2014
From: drfish at us.ibm.com (Doug Fish)
Date: Mon, 06 Oct 2014 13:35:42 -0000
Subject: [Openstack-security] [Bug 1369876] Re: Missing HttpOnly Attribute
	in Session Cookie
References: <20140916064453.32545.92390.malonedeb@gac.canonical.com>
Message-ID: <20141006133542.17942.38898.malone@chaenomeles.canonical.com>

reading more carefully, I see our docs don't mention
CSRF_COOKIE_HTTPONLY so they aren't wrong.  (They reference
CSRF_COOKIE_SECURE) But also this suggests that no investigation has
been done on potential side-effects.

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

Title:
  Missing HttpOnly Attribute in Session Cookie

Status in OpenStack Dashboard (Horizon):
  Confirmed

Bug description:
  Affected URL: https://Ip_address/admin/
  Entity: csrftoken (Cookie)
  Risk: It is possible to steal or manipulate customer session and cookies, which might be used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user.
  Causes: The web application sets session cookies without the HttpOnly attribute
  Recommend Fix: Add the 'HttpOnly' attribute to all session cookies.

  The Test Requests and Responses:
  GET /admin/ HTTP/1.1
  Host: 9.5.29.52
  User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
  Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
  Accept-Language: en-US,en;q=0.5
  Referer: https://9.5.29.52/
  Cookie: csrftoken=JPjBiDp6Ex6YDw3sgfZPCTPUwWKZdZTm; sessionid=oad3bpy15qm8ntml9wx604yr79cc6zpb
  Connection: keep-alive
  HTTP/1.1 200 OK
  Date: Fri, 12 Sep 2014 07:52:50 GMT
  Server: Apache
  Vary: Accept-Language,Cookie,Accept-Encoding
  X-Frame-Options: SAMEORIGIN
  Content-Language: en
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive
  2014/9/12 504
  Transfer-Encoding: chunked
  Content-Type: text/html
  Set-Cookie: csrftoken=silTP6ARbLvXohF6YYFLlWHce0KZkjPy; expires=Fri, 11-Sep-2015 07:52:52 GMT; Max-Age=31449600; Path=/; secure
  Set-Cookie: sessionid=ygq094phgr6og471j6n0asq7x6q37j6n; httponly; Path=/; secure
  <!DOCTYPE html>
  <html>
  <head>
  <meta content='text/html; charset=utf-8' http-equiv='Content-Type' />
  <title>Usage Overview - Cloud Management Dashboard</title>
  <!--
  Copyright 2014 *** Corp.
  -->
  <link rel="stylesheet" href="/static/dashboard/css/5730bed76fd3.css" type="text/css" media="screen" />
  <link rel="shortcut icon" href="/static/dashboard/img/favicon.png"/>
  <!--
  Fix header padding issue in IE < 10
  -->
  <!--[if lt IE 10 ]>
  <style>
  .topbar {
  padding-bottom: 0px;
  }
  </style>
  <![endif]-->
  <script type="text/javascript" src="/static/dashboard/js/841198948869.js"></script>
  <script type="text/javascript" charset="utf-8">
  /*
  Added so that we can append Horizon scoped JS events to
  the DOM load events without running in to the "horizon"
  name-space not currently being defined since we load the
  scripts at the bottom of the page.
  */
  var addHorizonLoadEvent = function(func) {
  var old_onload = window.onload;
  if (typeof window.onload != 'function') {
  window.onload = func;
  } else {
  window.onload = function() {
  old_onload();
  func();
  }
  }
  }
  </script>
  </head>
  <body id="" ng-app='hz'>
  <div id="container">
  <div class='topbar'>
  <!--
  Copyright 2014 ***Corp.
  -->
  <h1 class="brand"><a href="/home/">Cloud Management Dashboard</a></h1>
  <div id="user_info" class="pull-right">
  <div id="tenant_switcher" class="dropdown switcher_bar hide_image " tabindex="1">
  <div>admin</div>
  </div>
  <div id="profile_editor_switcher" class="dropdown switcher_bar" tabindex='1'>
  <a class="dropdown-toggle" data-toggle="dropdown" href="#profile_editor_switcher">
  <div>admin</div>
  </a>
  <ul id="editor_list" class="dropdown-menu">
  <li class='divider'></li>
  <li><a href="/settings/">Settings</a></li>
  2014/9/12 505
  TOC
  <li><a href="http://docs.openstack.org" target="_new">Help</a></li>
  <li><a href="/auth/logout/">Sign Out</a></li>
  </ul>
  </div>
  <img class="brand_icon" src="/static/dashboard/img/logo.png" alt=""/>
  </div>
  </div>
  <div id='main_content'>
  <div class="messages">
  </div>
  <div class='sidebar'>
  <div>
  <dl class="nav_accordion">
  <dt >
  <div>Project</div>
  </dt>
  <dd style="display:none;">
  <div><h4><div>Compute</div></h4>
  <ul>
  <li><a href="/project/" tabindex="1" >Overview</a></li>
  <li><a href="/project/instances/" tabindex="2" >Instances</a></li>
  <li><a href="/project/volumes/" tabindex="3" >Volumes</a></li>
  <li><a href="/project/images/" tabindex="4" >Images</a></li>
  <li><a href="/project/access_and_security/" tabindex="5" >Access &amp; Security</a></li>
  </ul>
  </div>
  <div><h4><div>Network</div></h4>
  <ul>
  <li><a href="/project/network_topology/" tabindex="1" >Network Topology</a></li>
  <li><a href="/project/networks/" tabindex="2" >Networks</a></li>
  <li><a href="/project/routers/" tabindex="3" >Routers</a></li>
  </ul>
  </div>
  <div><h4><div>Orchestration</div></h4>
  <ul>
  <li><a href="/project/stacks/" tabindex="1" >Stacks</a></li>
  </ul>
  </div>
  ...
  ...
  ...

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



From 1372643 at bugs.launchpad.net  Mon Oct  6 15:35:18 2014
From: 1372643 at bugs.launchpad.net (Robert Clark)
Date: Mon, 06 Oct 2014 15:35:18 -0000
Subject: [Openstack-security] [Bug 1372643] Re: MITM vulnerability with XIV
	driver
References: <20140922204545.32411.9337.malonedeb@gac.canonical.com>
Message-ID: <20141006153518.25549.3795.malone@soybean.canonical.com>

While this might not need to be embargoed I think it should be taken
more seriously. Bug 1188189 was just over a year ago and since then most
projects have improved their security. So what we have here is an
outlying driver that offers a significantly lower standard of security
than the rest of the system.

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

Title:
  MITM vulnerability with XIV driver

Status in Cinder:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The XIV driver in Juno appears to blindly trust whatever certificate
  it gets back from the device without any validation. This would leave
  it open to a MITM attack.

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



From alonma at il.ibm.com  Mon Oct  6 19:19:56 2014
From: alonma at il.ibm.com (Alon Marx)
Date: Mon, 06 Oct 2014 19:19:56 -0000
Subject: [Openstack-security] [Bug 1372643] Re: MITM vulnerability with XIV
	driver
References: <20140922204545.32411.9337.malonedeb@gac.canonical.com>
Message-ID: <20141006191956.25143.71008.malone@soybean.canonical.com>

I apologise for not updating this issue for a while.

I am working on a solution for this issue in the Juno timeframe. Because
we are close to release I am trying to get it to work without making any
changes in the open source code. In Kilo I plan an additional value in
cinder.conf to indicate the relevant paths, but for now I think we can
live with having a wide enough path internally.

** Changed in: ossa
     Assignee: (unassigned) => Alon Marx (alonma)

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

Title:
  MITM vulnerability with XIV driver

Status in Cinder:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The XIV driver in Juno appears to blindly trust whatever certificate
  it gets back from the device without any validation. This would leave
  it open to a MITM attack.

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



From gerrit2 at review.openstack.org  Tue Oct  7 17:44:06 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 07 Oct 2014 17:44:06 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I8e46d41164e9478b820cad569ba82f25de244620
Message-ID: <E1XbYnu-0000tx-W4@review.openstack.org>


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

Log:
commit 13d1da918a18bd8d846408b906987e73c6280e8f
Author: melanie witt <melwitt at yahoo-inc.com>
Date:   Fri Sep 26 05:15:16 2014 +0000

    replace httplib.HTTPSConnection in EC2KeystoneAuth
    
    httplib.HTTPSConnection is known to not verify SSL certificates
    in Python 2.x. This change replaces use of httplib.HTTPSConnection
    with the requests module. It imports config settings related to SSL
    verification: ssl.key_file, ssl.cert_file, and ssl.ca_file. It also
    adds one config setting: keystone_ec2_insecure. By default, SSL
    verification is on, but can be disabled by setting:
    
    keystone_ec2_insecure=true
    
    This patch is based on the keystone middleware ec2 token patch:
    
    https://review.openstack.org/#/c/76476
    
    SecurityImpact
    DocImpact
    Closes-Bug: #1373992
    
    Change-Id: I8e46d41164e9478b820cad569ba82f25de244620




From 1316271 at bugs.launchpad.net  Wed Oct  8 10:06:59 2014
From: 1316271 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 08 Oct 2014 10:06:59 -0000
Subject: [Openstack-security] [Bug 1316271] Change abandoned on nova (master)
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20141008100659.341.94458.malone@gac.canonical.com>

Change abandoned by Daniel Berrange (berrange at redhat.com) on branch: master
Review: https://review.openstack.org/119589
Reason: You've already got this uploaded under a different review

https://review.openstack.org/#/c/117628/

Soince that review is older and has alot of relevant historical comments
I'm marking this one abandoned. Please continue to post new versions to
your original review.

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

Title:
  Network Security: VM hosts can SSH to compute node

Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  Hi guys,

      We're still using nova-network and we'll be using it for a while
  and we noticed that the VM guests can contact the compute nodes on all
  ports ... The one we're the most preoccupied with is SSH.   We've
  written the following patch in order to isolate the VM guests from the
  VM hosts.

  --- linux_net.py.orig   2014-05-05 17:25:10.171746968 +0000
  +++ linux_net.py        2014-05-05 18:42:54.569209220 +0000
  @@ -805,6 +805,24 @@

  
   @utils.synchronized('lock_gateway', external=True)
  +def isolate_compute_from_guest(network_ref):
  +    if not network_ref:
  +        return
  +
  +    iptables_manager.ipv4['filter'].add_rule('INPUT',
  +                                             '-p tcp -d %s --dport 8775 '
  +                                             '-j ACCEPT' % network_ref['dhcp_server'])
  +    iptables_manager.ipv4['filter'].add_rule('FORWARD',
  +                                             '-p tcp -d %s --dport 8775 '
  +                                             '-j ACCEPT' % network_ref['dhcp_server'])
  +    iptables_manager.ipv4['filter'].add_rule('INPUT',
  +                                             '-d %s '
  +                                             '-j DROP' % network_ref['dhcp_server'])
  +    iptables_manager.ipv4['filter'].add_rule('FORWARD',
  +                                             '-d %s '
  +                                             '-j DROP' % network_ref['dhcp_server'])
  +    iptables_manager.apply()
  +
   def initialize_gateway_device(dev, network_ref):
       if not network_ref:
           return
  @@ -1046,6 +1064,7 @@
               try:
                   _execute('kill', '-HUP', pid, run_as_root=True)
                   _add_dnsmasq_accept_rules(dev)
  +                isolate_compute_from_guest(network_ref)
                   return
               except Exception as exc:  # pylint: disable=W0703
                   LOG.error(_('Hupping dnsmasq threw %s'), exc)
  @@ -1098,6 +1117,7 @@

       _add_dnsmasq_accept_rules(dev)

  +    isolate_compute_from_guest(network_ref)

   @utils.synchronized('radvd_start')
   def update_ra(context, dev, network_ref):

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



From gerrit2 at review.openstack.org  Wed Oct  8 17:15:00 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 08 Oct 2014 17:15:00 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I8e46d41164e9478b820cad569ba82f25de244620
Message-ID: <E1XbupI-0007d8-5R@review.openstack.org>


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

Log:
commit 881eaaf3bdb454e9f1d50340d7b59d0b6057fa01
Author: melanie witt <melwitt at yahoo-inc.com>
Date:   Fri Sep 26 05:15:16 2014 +0000

    replace httplib.HTTPSConnection in EC2KeystoneAuth
    
    httplib.HTTPSConnection is known to not verify SSL certificates
    in Python 2.x. This change replaces use of httplib.HTTPSConnection
    with the requests module. It imports config settings related to SSL
    verification: ssl.key_file, ssl.cert_file, and ssl.ca_file. It also
    adds one config setting: keystone_ec2_insecure. By default, SSL
    verification is on, but can be disabled by setting:
    
    keystone_ec2_insecure=true
    
    This patch is based on the keystone middleware ec2 token patch:
    
    https://review.openstack.org/#/c/76476
    
    SecurityImpact
    DocImpact
    Closes-Bug: #1373992
    
    Change-Id: I8e46d41164e9478b820cad569ba82f25de244620




From bknudson at us.ibm.com  Wed Oct  8 18:53:31 2014
From: bknudson at us.ibm.com (Brant Knudson)
Date: Wed, 08 Oct 2014 18:53:31 -0000
Subject: [Openstack-security] [Bug 1367022] Re: Un-sanitized eval may have
	security impact
References: <20140908225246.18130.67662.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141008185333.25418.73733.launchpad@soybean.canonical.com>

** Changed in: ceilometer
     Assignee: Brant Knudson (blk-u) => (unassigned)

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

Title:
  Un-sanitized eval may have security impact

Status in OpenStack Telemetry (Ceilometer):
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  On this line:
  https://github.com/openstack/ceilometer/blob/master/ceilometer/transformer/conversions.py#L62
  eval is used for some transformation.  The comments near by suggest
  that it is used for a 'multiplicative factor or else a string to be
  eval'd'.

  If an attacker is able to provide an input like
  "__import__('os').system('rm -rf /etc')" the process will delete the
  etc directory with the privileges of the user that is running
  Ceilometer.

  Eval input should always be sanitized.  I was unable to find any
  places that this is actually used, but this should definitely be
  hardened.

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



From gerrit2 at review.openstack.org  Wed Oct  8 21:27:58 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 08 Oct 2014 21:27:58 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I241ca72329f1ec9df778498b346d7b29c224d528
Message-ID: <E1Xbym6-0003d5-SK@review.openstack.org>


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

Log:
commit fd6547d8441fdc8838665b8fa76ccea65fd0ef26
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Aug 27 17:06:44 2014 -0500

    pki/ssl_setup configurable digest
    
    The digest to use for pki_setup couldn't be configured. The value was
    `default`, which means that the digest was sha1. Some security
    standards require the digest to be stronger (SHA2), so making the
    digest configurable will allow deployments to be compliant.
    
    SecurityImpact
    
    DocImpact
    
    New `message_digest_algorithm` configuration options are added to the
    [signing] and [ssl] sections which default to `default`.
    
    Change-Id: I241ca72329f1ec9df778498b346d7b29c224d528
    Closes-Bug: #1362343




From gerrit2 at review.openstack.org  Wed Oct  8 21:28:03 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 08 Oct 2014 21:28:03 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I9e42c9bafc307ba1334fa641bab76f251722044d
Message-ID: <E1XbymB-0003dM-Ri@review.openstack.org>


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

Log:
commit 0c748c594891d509eeca4ad21a3c4fbfa785c128
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Aug 27 17:11:06 2014 -0500

    Change the default digest for pki/ssl_setup to sha256
    
    The default digest was `default`, which meant that the digest was the
    openssl default of sha1. The default setting should be a SHA2
    algorithm since this meets current security standards.
    
    This is for security hardening.
    
    SecurityImpact
    
    DocImpact
    
    The `default_message_digest` configuration options now default to
    `sha256` instead of `default`.
    
    Change-Id: I9e42c9bafc307ba1334fa641bab76f251722044d
    Related-Bug: #1362343




From bknudson at us.ibm.com  Thu Oct  9 03:17:30 2014
From: bknudson at us.ibm.com (Brant Knudson)
Date: Thu, 09 Oct 2014 03:17:30 -0000
Subject: [Openstack-security] [Bug 1329301] Re: Update how tokens are
 redacted from plaintext exposure
References: <20140612121824.4650.65306.malonedeb@wampee.canonical.com>
Message-ID: <20141009031730.4798.59996.malone@wampee.canonical.com>

This is https://review.openstack.org/#/c/123819/ in python-
keystoneclient.

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

Title:
  Update how tokens are redacted from plaintext exposure

Status in Python client library for Glance:
  Fix Released
Status in Python client library for Keystone:
  In Progress

Bug description:
  We should move from this approach:

  https://review.openstack.org/#/c/83350/

  to whatever cross-project approach is agreed upon:

  See this thread:

  http://lists.openstack.org/pipermail/openstack-
  dev/2014-June/037345.html

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



From thierry.carrez+lp at gmail.com  Thu Oct  9 09:27:00 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 09 Oct 2014 09:27:00 -0000
Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC
	VMAX driver
References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com>
Message-ID: <20141009092701.24784.92676.launchpad@soybean.canonical.com>

** Information type changed from Private Security to Public

** Tags added: security

** Changed in: ossa
       Status: Incomplete => Won't Fix

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

Title:
  MITM vulnerability with EMC VMAX driver

Status in Cinder:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The EMC VMAX driver in Juno appears to blindly trust whatever
  certificate it gets back from the device without any validation (it
  does not specify the ca_certs parameter, etc. on
  WBEMConnection.__init__). This would leave it open to a MITM attack.

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



From gerrit2 at review.openstack.org  Thu Oct  9 11:32:11 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 09 Oct 2014 11:32:11 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I0b8e6319a4cc39876b1e396ef705f0fc5def1e44
Message-ID: <E1XcBx5-0003i3-Q3@review.openstack.org>


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

Log:
commit 1c81fa1e5c1b6ee9a01f27cc57d05a86cc69d984
Author: Sylvain Bauza <sbauza at redhat.com>
Date:   Mon Sep 29 13:33:50 2014 +0200

    Fix unsafe SSL connection on TrustedFilter
    
    TrustedFilter was using httplib which doesn't check for CAs.
    Here the change is using Requests and verifies local CAs by default (or another
    one if provided)
    This effort is related to CVE 2013-2255.
    
    SecurityImpact
    
    Closes-Bug: #1373993
    (cherry picked from commit 30871e8702737edbbfbcbbb5f21858873b37685c)
    
    Conflicts:
    	nova/tests/scheduler/test_host_filters.py
    
    Change-Id: I0b8e6319a4cc39876b1e396ef705f0fc5def1e44




From gerrit2 at review.openstack.org  Thu Oct  9 13:18:38 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 09 Oct 2014 13:18:38 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I0b8e6319a4cc39876b1e396ef705f0fc5def1e44
Message-ID: <E1XcDc6-0003G3-DT@review.openstack.org>


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

Log:
commit d90a19e99f1b75b9fb8b9f65d64a0e97bc06d102
Author: Sylvain Bauza <sbauza at redhat.com>
Date:   Mon Sep 29 13:33:50 2014 +0200

    Fix unsafe SSL connection on TrustedFilter
    
    TrustedFilter was using httplib which doesn't check for CAs.
    Here the change is using Requests and verifies local CAs by default (or another
    one if provided)
    This effort is related to CVE 2013-2255.
    
    SecurityImpact
    
    Closes-Bug: #1373993
    (cherry picked from commit 30871e8702737edbbfbcbbb5f21858873b37685c)
    
    Conflicts:
    	nova/tests/scheduler/test_host_filters.py
    
    Change-Id: I0b8e6319a4cc39876b1e396ef705f0fc5def1e44




From fungi at yuggoth.org  Thu Oct  9 13:14:12 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Thu, 09 Oct 2014 13:14:12 -0000
Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC
	VMAX driver
References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com>
Message-ID: <20141009131412.25513.47957.malone@soybean.canonical.com>

I don't necessarily disagree with this stance, but from a pragmatic
perspective the VMT lacks any real authority to put all OpenStack
development on lockdown and hold developers hostage so that they're
forced to redesign internal communication between components with more
secure mechanisms rather than work on their various pet features. As
much as I wish we could...

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

Title:
  MITM vulnerability with EMC VMAX driver

Status in Cinder:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The EMC VMAX driver in Juno appears to blindly trust whatever
  certificate it gets back from the device without any validation (it
  does not specify the ca_certs parameter, etc. on
  WBEMConnection.__init__). This would leave it open to a MITM attack.

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



From 1329301 at bugs.launchpad.net  Thu Oct  9 15:01:11 2014
From: 1329301 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 09 Oct 2014 15:01:11 -0000
Subject: [Openstack-security] [Bug 1329301] Re: Update how tokens are
 redacted from plaintext exposure
References: <20140612121824.4650.65306.malonedeb@wampee.canonical.com>
Message-ID: <20141009150111.24721.23301.malone@soybean.canonical.com>

Reviewed:  https://review.openstack.org/123819
Committed: https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=23d20452d24dc3adeb404ab44799585ec1169247
Submitter: Jenkins
Branch:    master

commit 23d20452d24dc3adeb404ab44799585ec1169247
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Sep 24 14:24:39 2014 -0500

    Log token with sha1
    
    By logging the sha1 hash of the token, it can be tracked through
    different services.
    
    Closes-bug: #1329301
    Change-Id: I9c338f6a418ab8dd34dbaaf918b0ea6e9cbe79d7


** Changed in: python-keystoneclient
       Status: In Progress => Fix Committed

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

Title:
  Update how tokens are redacted from plaintext exposure

Status in Python client library for Glance:
  Fix Released
Status in Python client library for Keystone:
  Fix Committed

Bug description:
  We should move from this approach:

  https://review.openstack.org/#/c/83350/

  to whatever cross-project approach is agreed upon:

  See this thread:

  http://lists.openstack.org/pipermail/openstack-
  dev/2014-June/037345.html

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



From 1174499 at bugs.launchpad.net  Fri Oct 10 05:07:46 2014
From: 1174499 at bugs.launchpad.net (Akihiro Motoki)
Date: Fri, 10 Oct 2014 05:07:46 -0000
Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20141010050748.32380.98244.launchpad@gac.canonical.com>

** Changed in: horizon
    Milestone: None => kilo-1

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

Title:
  Keystone token hashing is MD5

Status in Django OpenStack Auth:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Committed
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  Fix Released

Bug description:
  https://github.com/openstack/python-
  keystoneclient/blob/master/keystoneclient/common/cms.py

  def cms_hash_token(token_id):
      """
  return: for ans1_token, returns the hash of the passed in token
  otherwise, returns what it was passed in.
  """
      if token_id is None:
          return None
      if is_ans1_token(token_id):
          hasher = hashlib.md5()
          hasher.update(token_id)
          return hasher.hexdigest()
      else:
          return token_id

  
  MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256.
  Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use.

To manage notifications about this bug go to:
https://bugs.launchpad.net/django-openstack-auth/+bug/1174499/+subscriptions



From gerrit2 at review.openstack.org  Fri Oct 10 09:00:19 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 10 Oct 2014 09:00:19 +0000
Subject: [Openstack-security] [openstack/horizon] SecurityImpact review
 request change I6774b9b7215d191259586e4721e357487bb777cd
Message-ID: <E1XcW3f-0003WW-AR@review.openstack.org>


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

Log:
commit 3a64723917366eff4d8896b2b2d3d82fa462d25d
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Sun Aug 24 10:04:10 2014 -0500

    Document token hash algorithm option
    
    With https://review.openstack.org/#/c/116509/ ,
    django-openstack-auth will support a new option for the token hash
    algorithm. This adds the documentation to Horizon's local settings
    example file.
    
    This is for security hardening. The token hash algorithm defaults
    to MD5, which is considered too weak due to the potential for hash
    collisions. Some security standards require a SHA2 hash algorithm to
    be used.
    
    DocImpact
    SecurityImpact
    
    Change-Id: I6774b9b7215d191259586e4721e357487bb777cd
    Closes-Bug: #1174499
    (cherry picked from commit 372d033d89c0f5d305959a6ad5fd3e1159cc91ed)




From thierry.carrez+lp at gmail.com  Fri Oct 10 08:58:49 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Fri, 10 Oct 2014 08:58:49 -0000
Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20141010085852.5401.74020.launchpad@wampee.canonical.com>

** Changed in: horizon
    Milestone: kilo-1 => juno-rc2

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

Title:
  Keystone token hashing is MD5

Status in Django OpenStack Auth:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Committed
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  Fix Released

Bug description:
  https://github.com/openstack/python-
  keystoneclient/blob/master/keystoneclient/common/cms.py

  def cms_hash_token(token_id):
      """
  return: for ans1_token, returns the hash of the passed in token
  otherwise, returns what it was passed in.
  """
      if token_id is None:
          return None
      if is_ans1_token(token_id):
          hasher = hashlib.md5()
          hasher.update(token_id)
          return hasher.hexdigest()
      else:
          return token_id

  
  MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256.
  Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use.

To manage notifications about this bug go to:
https://bugs.launchpad.net/django-openstack-auth/+bug/1174499/+subscriptions



From 1174499 at bugs.launchpad.net  Fri Oct 10 09:00:16 2014
From: 1174499 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 10 Oct 2014 09:00:16 -0000
Subject: [Openstack-security] [Bug 1174499] Fix proposed to horizon
	(proposed/juno)
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20141010090016.18382.48258.malone@chaenomeles.canonical.com>

Fix proposed to branch: proposed/juno
Review: https://review.openstack.org/127452

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

Title:
  Keystone token hashing is MD5

Status in Django OpenStack Auth:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Committed
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  Fix Released

Bug description:
  https://github.com/openstack/python-
  keystoneclient/blob/master/keystoneclient/common/cms.py

  def cms_hash_token(token_id):
      """
  return: for ans1_token, returns the hash of the passed in token
  otherwise, returns what it was passed in.
  """
      if token_id is None:
          return None
      if is_ans1_token(token_id):
          hasher = hashlib.md5()
          hasher.update(token_id)
          return hasher.hexdigest()
      else:
          return token_id

  
  MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256.
  Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use.

To manage notifications about this bug go to:
https://bugs.launchpad.net/django-openstack-auth/+bug/1174499/+subscriptions



From robert.clark at hp.com  Fri Oct 10 10:07:06 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Fri, 10 Oct 2014 10:07:06 +0000
Subject: [Openstack-security] Swift Encryption
Message-ID: <A0C170085C37664D93EE1604364858A11247C6FC@G4W3300.americas.hpqcorp.net>

All,

 

There's a spec and some first-pass code at implementing object encryption in Swift. I know this is something I've discussed with
several of you before so I'm bringing this to your attention.

 

Please review, comment and get involved if you've got the cycles.

 

Spec: https://review.openstack.org/#/c/123220/

Code: https://review.openstack.org/#/c/122773/

 

Cheers

-Rob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141010/03c0fc92/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6187 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141010/03c0fc92/attachment.bin>

From zrlcca at linux.vnet.ibm.com  Fri Oct 10 11:56:55 2014
From: zrlcca at linux.vnet.ibm.com (Christian Cachin)
Date: Fri, 10 Oct 2014 13:56:55 +0200
Subject: [Openstack-security]  Re: Swift Encryption
Message-ID: <20141010135655.32f887d3@genova.zurich.ibm.com>

Robert, all,

> There's a spec and some first-pass code at implementing object
> encryption in Swift. I know this is something I've discussed with
> several of you before so I'm bringing this to your attention.
> 
> Please review, comment and get involved if you've got the cycles.
> 
> Spec: https://review.openstack.org/#/c/123220/
> 
> Code: https://review.openstack.org/#/c/122773/  

Please note that these two are from different sources.  We posted the code
based on earlier designs.  Sam posted the spec above.  I have meanwhile 
created an extended spec that includes material from the spec above:
  https://review.openstack.org/#/c/126880/

Thanks ahead for feedback.

Regards,

	Christian


--- 
Christian Cachin                           email: cca at zurich.ibm.com
IBM Research - Zurich                           tel: +41-44-724-8989
Säumerstrasse 4                                 fax: +41-44-724-8953
CH-8803 Rüschlikon, Switzerland       http://www.zurich.ibm.com/~cca




From 1372635 at bugs.launchpad.net  Thu Oct  9 10:33:13 2014
From: 1372635 at bugs.launchpad.net (Robert Clark)
Date: Thu, 09 Oct 2014 10:33:13 -0000
Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC
	VMAX driver
References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com>
Message-ID: <20141009103313.17842.72903.malone@chaenomeles.canonical.com>

This is how software projects get a bad reputation. I agree with
everything that Matt has said (which won't be a surprise to the VMT).
Deviation from best practice / security failures should be a blocker to
new features/drivers being accepted into the project.

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

Title:
  MITM vulnerability with EMC VMAX driver

Status in Cinder:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The EMC VMAX driver in Juno appears to blindly trust whatever
  certificate it gets back from the device without any validation (it
  does not specify the ca_certs parameter, etc. on
  WBEMConnection.__init__). This would leave it open to a MITM attack.

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



From robert.clark at hp.com  Fri Oct 10 12:46:12 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Fri, 10 Oct 2014 12:46:12 +0000
Subject: [Openstack-security] Swift Encryption
In-Reply-To: <20141010135655.32f887d3@genova.zurich.ibm.com>
References: <20141010135655.32f887d3@genova.zurich.ibm.com>
Message-ID: <A0C170085C37664D93EE1604364858A11247CACA@G4W3300.americas.hpqcorp.net>

> -----Original Message-----
> From: Christian Cachin [mailto:zrlcca at linux.vnet.ibm.com]
> Sent: 10 October 2014 12:57
> To: openstack-security at lists.openstack.org
> Subject: [Openstack-security] Re: Swift Encryption
> 
> Robert, all,
> 
> > There's a spec and some first-pass code at implementing object
> > encryption in Swift. I know this is something I've discussed with
> > several of you before so I'm bringing this to your attention.
> >
> > Please review, comment and get involved if you've got the cycles.
> >
> > Spec: https://review.openstack.org/#/c/123220/
> >
> > Code: https://review.openstack.org/#/c/122773/
> 
> Please note that these two are from different sources.  We posted the code
> based on earlier designs.  Sam posted the spec above.  I have meanwhile
> created an extended spec that includes material from the spec above:
>   https://review.openstack.org/#/c/126880/
> 
> Thanks ahead for feedback.
> 
> Regards,
> 
> 	Christian
> 
> 
> ---
> Christian Cachin                           email: cca at zurich.ibm.com
> IBM Research - Zurich                           tel: +41-44-724-8989
> Säumerstrasse 4                                 fax: +41-44-724-8953
> CH-8803 Rüschlikon, Switzerland       http://www.zurich.ibm.com/~cca
> 
> 

Thanks Christian,

So where does the community stand regarding this spec and the other one (yours and Sam's) ?

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6187 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141010/0b54de31/attachment.bin>

From 1372635 at bugs.launchpad.net  Fri Oct 10 12:44:12 2014
From: 1372635 at bugs.launchpad.net (Robert Clark)
Date: Fri, 10 Oct 2014 12:44:12 -0000
Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC
	VMAX driver
References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com>
Message-ID: <20141010124412.32411.28552.malone@gac.canonical.com>

Is this concern something that could be bubbled up to the technical
committee?

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

Title:
  MITM vulnerability with EMC VMAX driver

Status in Cinder:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The EMC VMAX driver in Juno appears to blindly trust whatever
  certificate it gets back from the device without any validation (it
  does not specify the ca_certs parameter, etc. on
  WBEMConnection.__init__). This would leave it open to a MITM attack.

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



From gerrit2 at review.openstack.org  Fri Oct 10 13:09:25 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 10 Oct 2014 13:09:25 +0000
Subject: [Openstack-security] [openstack/swift-specs] SecurityImpact review
 request change I9adcd8979af8f1d0ebd912c503ae36a8041ed32d
Message-ID: <E1XcZwj-0006mE-R6@review.openstack.org>


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

Log:
commit 43af26fe405ff2d4bca5fecdd6d3485db342a789
Author: Christian Cachin <cca at zurich.ibm.com>
Date:   Wed Oct 8 13:41:40 2014 +0200

    Draft specification for storage encryption in Swift
    
    This draft serves for agreeing on the security goals of encryption
    support in Swift, its design and important implementation choices.
    
    This spec revises the "spec for on-disk encryption" here
      https://review.openstack.org/#/c/123220/
    and extends the security model and the design. It also takes
    into account some of the discussion there.
    
    For relevant background, see also the earlier blueprint
      https://blueprints.launchpad.net/swift/+spec/swift-enc-proxy
    
    The change-id points to relevant prior post of design for on-disk
    encryption.
    
    SecurityImpact
    
    Change-Id: I9adcd8979af8f1d0ebd912c503ae36a8041ed32d




From zrlcca at linux.vnet.ibm.com  Fri Oct 10 13:21:06 2014
From: zrlcca at linux.vnet.ibm.com (Christian Cachin)
Date: Fri, 10 Oct 2014 15:21:06 +0200
Subject: [Openstack-security] Swift Encryption
In-Reply-To: <A0C170085C37664D93EE1604364858A11247CACA@G4W3300.americas.hpqcorp.net>
References: <20141010135655.32f887d3@genova.zurich.ibm.com>
 <A0C170085C37664D93EE1604364858A11247CACA@G4W3300.americas.hpqcorp.net>
Message-ID: <20141010152106.05a335cf@genova.zurich.ibm.com>

On 10 Oct 2014 12:46:12 +0000, "Clark, Robert Graham" <robert.clark at hp.com> wrote:
> 
> Thanks Christian,
> 
> So where does the community stand regarding this spec and the other one
> (yours and Sam's) ?

I believe we're in the process of converging on a set of requirements 
and on important design issues.  The spec I committed takes up the 
architecture from Sam's but greatly extends the security discussion.

	Christian




From fungi at yuggoth.org  Fri Oct 10 14:50:15 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 10 Oct 2014 14:50:15 -0000
Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC
	VMAX driver
References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com>
Message-ID: <20141010145015.18413.517.malone@chaenomeles.canonical.com>

It's more likely something that needs to be bubbled out to the PTLs
managing the projects in question. While the TC has some sway over
cross-project matters, design choices are generally the purview of
individual programs. (TC members: is that an accurate statement?)

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

Title:
  MITM vulnerability with EMC VMAX driver

Status in Cinder:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The EMC VMAX driver in Juno appears to blindly trust whatever
  certificate it gets back from the device without any validation (it
  does not specify the ca_certs parameter, etc. on
  WBEMConnection.__init__). This would leave it open to a MITM attack.

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



From thierry.carrez+lp at gmail.com  Fri Oct 10 15:02:46 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Fri, 10 Oct 2014 15:02:46 -0000
Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC
	VMAX driver
References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com>
Message-ID: <20141010150246.4829.47101.malone@wampee.canonical.com>

@Rob: unfortunately we singled that design flaw a long time ago (you
were still on the VMT then) and nothing was done to fix it. In some
cases it's oversight (like in this driver), in some others it's an
architectural choice (like in Swift using unencrypted rsync on the
management network). Unless a group takes on the task to fix it
throughout OpenStack (and folows up with patches and hangs there until
they get approved and merged), I don't see any progress coming.

Do you think the OSSG could form a workgroup around that ? We already
have one proposed to eradicate XSS from Horizon... we really need one
taking on absence of proper encryption on the management network side.

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

Title:
  MITM vulnerability with EMC VMAX driver

Status in Cinder:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The EMC VMAX driver in Juno appears to blindly trust whatever
  certificate it gets back from the device without any validation (it
  does not specify the ca_certs parameter, etc. on
  WBEMConnection.__init__). This would leave it open to a MITM attack.

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



From mordred at inaugust.com  Fri Oct 10 16:00:36 2014
From: mordred at inaugust.com (Monty Taylor)
Date: Fri, 10 Oct 2014 16:00:36 -0000
Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC
	VMAX driver
References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com>
Message-ID: <20141010160036.25282.7410.malone@soybean.canonical.com>

I support fixing management network encryption.

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

Title:
  MITM vulnerability with EMC VMAX driver

Status in Cinder:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The EMC VMAX driver in Juno appears to blindly trust whatever
  certificate it gets back from the device without any validation (it
  does not specify the ca_certs parameter, etc. on
  WBEMConnection.__init__). This would leave it open to a MITM attack.

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



From farazhyder55 at gmail.com  Sun Oct 12 13:55:33 2014
From: farazhyder55 at gmail.com (Muhammad Faraz Hyder)
Date: Sun, 12 Oct 2014 18:55:33 +0500
Subject: [Openstack-security] Software TPM Emulators for Trusted boot
Message-ID: <CAF47eerLrgq=rsr3G_CyJMJqS9KX6dPULNg_oBbSjCu0u10kpw@mail.gmail.com>

Can I use software based TPM for Trusted boot. I have configured IBM's
software TPM. and I need some guidance , the documentation for the trusted
boot openstack says that compute node must have Intel Trusted Technology
enabled.

Please guide in this regard.

Regards,
Faraz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141012/c02b3e7e/attachment.html>

From gang.wei at intel.com  Mon Oct 13 01:24:12 2014
From: gang.wei at intel.com (Wei, Gang)
Date: Mon, 13 Oct 2014 01:24:12 +0000
Subject: [Openstack-security] Software TPM Emulators for Trusted boot
In-Reply-To: <CAF47eerLrgq=rsr3G_CyJMJqS9KX6dPULNg_oBbSjCu0u10kpw@mail.gmail.com>
References: <CAF47eerLrgq=rsr3G_CyJMJqS9KX6dPULNg_oBbSjCu0u10kpw@mail.gmail.com>
Message-ID: <D0B11485C64D4B47B66902F8A4E901BE01D7BF4A@shsmsx102.ccr.corp.intel.com>

Hi, Faraz,

Sorry, you can’t use S/W TPM for Intel Trusted Execution Technology/Trusted Boot(tboot). Since TXT/tboot requires H/W TPM on bare metal host in the pre-OS phase. You need to use an Intel TXT capable system, and make TXT enabled.

Thanks
Jimmy

From: Muhammad Faraz Hyder [mailto:farazhyder55 at gmail.com]
Sent: Sunday, October 12, 2014 9:56 PM
To: openstack-security at lists.openstack.org
Subject: [Openstack-security] Software TPM Emulators for Trusted boot

Can I use software based TPM for Trusted boot. I have configured IBM's software TPM. and I need some guidance , the documentation for the trusted boot openstack says that compute node must have Intel Trusted Technology enabled.

Please guide in this regard.

Regards,
Faraz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141013/0d9923ea/attachment.html>

From tim.kelsey at hp.com  Mon Oct 13 14:37:14 2014
From: tim.kelsey at hp.com (Tim Kelsey)
Date: Mon, 13 Oct 2014 14:37:14 -0000
Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache
 poisoning by local attacker
References: <20140715043528.2209.47100.malonedeb@gac.canonical.com>
Message-ID: <20141013143720.17678.82246.launchpad@chaenomeles.canonical.com>

** Changed in: ossn
     Assignee: (unassigned) => Tim Kelsey (tim-kelsey)

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

Title:
  suds client subject to cache poisoning by local attacker

Status in Cinder:
  Fix Released
Status in Cinder havana series:
  Fix Released
Status in Cinder icehouse series:
  Fix Released
Status in Gantt:
  New
Status in OpenStack Compute (Nova):
  Fix Released
Status in Oslo VMware library for OpenStack projects:
  Fix Released
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  New

Bug description:
  
  The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. 

  cinder/requirements.txt:suds>=0.4
  gantt/requirements.txt:suds>=0.4
  nova/requirements.txt:suds>=0.4
  oslo.vmware/requirements.txt:suds>=0.4

  
  The details are available here - 
  https://bugzilla.redhat.com/show_bug.cgi?id=978696
  (CVE-2013-2217)

  Although this is an unlikely attack vector steps should be taken to
  prevent this behaviour. Potential ways to fix this are by explicitly
  setting the cache location to a directory created via
  tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or
  using a custom cache implementation that doesn't load / store pickled
  objects from an insecure location.

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



From fungi at yuggoth.org  Mon Oct 13 15:53:08 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 13 Oct 2014 15:53:08 -0000
Subject: [Openstack-security] [Bug 1376915] Re: Ceilometer policy file
	settings ignored
References: <20141002203501.17647.70947.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141013155308.32158.94569.malone@gac.canonical.com>

Okay, so it sounds to me like this is a (perhaps contentious and/or
incomplete) design decision in Ceilometer. It's certainly worth
discussing how to improve this in the project going forward, and the
blueprint linked above appears to be an approved solution if anyone
wants to help address the issue. However it does not match the
Vulnerability Management Team's criteria for issuing an OpenStack
Security Advisory since this sort of ongoing development is not likely
to get backported to any existing stable releases, but would instead be
a behavior change/new feature in an upcoming release.

The OpenStack Security Group may be interested in issuing a security
note about this as an addendum to the Security Guide, so I've tagged it
as "security" accordingly.

** Information type changed from Private Security to Public

** Tags added: security

** Changed in: ossa
       Status: Incomplete => Won't Fix

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

Title:
  Ceilometer policy file settings ignored

Status in OpenStack Telemetry (Ceilometer):
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Configuring the ceilometer policy.json file to restrict certain
  actions has no effect whatsoever. This allows all users access to
  sensitive information, such as audit data stored in the http.request
  meter.

  E.g. policy.json file:

  {
      "adm":  "role:admin",

      "default": "!",

      "meter:get_all": "rule:adm",
      "meters:get_all": "rule:adm"
  }

  With the above policy, tokens for users without the admin role are
  still able to access meters, and any token still works for alarms
  despite the default supposedly being to disallow for everyone.

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



From edmondsw at us.ibm.com  Mon Oct 13 16:17:07 2014
From: edmondsw at us.ibm.com (Matthew Edmonds)
Date: Mon, 13 Oct 2014 16:17:07 -0000
Subject: [Openstack-security] [Bug 1376915] Re: Ceilometer policy file
	settings ignored
References: <20141002203501.17647.70947.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141013161707.18008.49298.malone@chaenomeles.canonical.com>

I wouldn't expect full implementation of those blueprints to get
backported to previous releases, but is full implementation of those
blueprints necessary to close the security issue that is allowing non-
admin users access to information which only admins should be able to
see? I would expect a more limited fix to close this hole in Juno and be
backported to previous releases, with the full blueprint implementations
coming in later.

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

Title:
  Ceilometer policy file settings ignored

Status in OpenStack Telemetry (Ceilometer):
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Configuring the ceilometer policy.json file to restrict certain
  actions has no effect whatsoever. This allows all users access to
  sensitive information, such as audit data stored in the http.request
  meter.

  E.g. policy.json file:

  {
      "adm":  "role:admin",

      "default": "!",

      "meter:get_all": "rule:adm",
      "meters:get_all": "rule:adm"
  }

  With the above policy, tokens for users without the admin role are
  still able to access meters, and any token still works for alarms
  despite the default supposedly being to disallow for everyone.

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



From fungi at yuggoth.org  Mon Oct 13 16:29:34 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 13 Oct 2014 16:29:34 -0000
Subject: [Openstack-security] [Bug 1376915] Re: Ceilometer policy file
	settings ignored
References: <20141002203501.17647.70947.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141013162934.17973.94263.malone@chaenomeles.canonical.com>

That's a decision which will have to be left up to the developers. Did
you have a particular backportable patch to propose (one which would
meet our stable branch guidelines, e.g. no new configuration and no
outward behavior changes)?

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

Title:
  Ceilometer policy file settings ignored

Status in OpenStack Telemetry (Ceilometer):
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Configuring the ceilometer policy.json file to restrict certain
  actions has no effect whatsoever. This allows all users access to
  sensitive information, such as audit data stored in the http.request
  meter.

  E.g. policy.json file:

  {
      "adm":  "role:admin",

      "default": "!",

      "meter:get_all": "rule:adm",
      "meters:get_all": "rule:adm"
  }

  With the above policy, tokens for users without the admin role are
  still able to access meters, and any token still works for alarms
  despite the default supposedly being to disallow for everyone.

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



From 1329214 at bugs.launchpad.net  Tue Oct 14 23:30:56 2014
From: 1329214 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 14 Oct 2014 23:30:56 -0000
Subject: [Openstack-security] [Bug 1329214] Re: tgtadm iscsi chap does not
	work
References: <20140612080140.21505.11780.malonedeb@gac.canonical.com>
Message-ID: <20141014233056.5430.38445.malone@wampee.canonical.com>

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

** Changed in: cinder
     Assignee: ling-yun (zengyunling) => Tomoki Sekiyama (tsekiyama)

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

Title:
  tgtadm iscsi chap does not work

Status in Cinder:
  In Progress

Bug description:
  When using LVMISCSIDriver and iscsi_helper tgtadm, it should support chap unidirectional authentication because target configuration file and db.volume  has record chap user and chap passwd. 
  By testing, I found that tgtadm iscsi chap does not work.
  Is it a security bug for iscsi_helper tgtadm? 

  My detail test work is as follows.
  1. Test details as follows without modify the source code:
  1) Devstack all in one server A(10.250.10.190); another testing server B(10.250.10.191)
  2) create a vm  VM-A  and a cinder volume VOLUME-A, attach VOLUME-A to VM-A
  3) server B directly login the iscsi target that server-A export and get VOLUME-A sucessfully . 
      iscsiadm -m discovery -t sendtargets -p 10.250.10.190
      iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login

  2. Test details as follows with modify the source code:
  1) add creating user/passwd and binding user to tid code before leaving the function TgtAdm:create_iscsi_target. 
          type, name, passwd = chap_auth.split()
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'new',
                        '--user',
                        name,
                        '--password',
                        passwd)
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'bind',
                        '--tid',
                        tid,
                        '--user',
                        name
                        )

  2) try to login VOLUME-A as the steps in item 1, it reported an authorization error as follows.
  root at devaio1:/etc/iscsi#     iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login
  Logging in to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260] (multiple)
  iscsiadm: Could not login to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260].
  iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure)
  iscsiadm: Could not log into all portals

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



From 1329214 at bugs.launchpad.net  Wed Oct 15 03:44:06 2014
From: 1329214 at bugs.launchpad.net (John Griffith)
Date: Wed, 15 Oct 2014 03:44:06 -0000
Subject: [Openstack-security] [Bug 1329214] Re: tgtadm iscsi chap does not
	work
References: <20140612080140.21505.11780.malonedeb@gac.canonical.com>
Message-ID: <20141015034408.17616.59348.launchpad@chaenomeles.canonical.com>

** Changed in: cinder
   Importance: Undecided => Critical

** Changed in: cinder
    Milestone: None => juno-rc3

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

Title:
  tgtadm iscsi chap does not work

Status in Cinder:
  In Progress

Bug description:
  When using LVMISCSIDriver and iscsi_helper tgtadm, it should support chap unidirectional authentication because target configuration file and db.volume  has record chap user and chap passwd. 
  By testing, I found that tgtadm iscsi chap does not work.
  Is it a security bug for iscsi_helper tgtadm? 

  My detail test work is as follows.
  1. Test details as follows without modify the source code:
  1) Devstack all in one server A(10.250.10.190); another testing server B(10.250.10.191)
  2) create a vm  VM-A  and a cinder volume VOLUME-A, attach VOLUME-A to VM-A
  3) server B directly login the iscsi target that server-A export and get VOLUME-A sucessfully . 
      iscsiadm -m discovery -t sendtargets -p 10.250.10.190
      iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login

  2. Test details as follows with modify the source code:
  1) add creating user/passwd and binding user to tid code before leaving the function TgtAdm:create_iscsi_target. 
          type, name, passwd = chap_auth.split()
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'new',
                        '--user',
                        name,
                        '--password',
                        passwd)
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'bind',
                        '--tid',
                        tid,
                        '--user',
                        name
                        )

  2) try to login VOLUME-A as the steps in item 1, it reported an authorization error as follows.
  root at devaio1:/etc/iscsi#     iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login
  Logging in to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260] (multiple)
  iscsiadm: Could not login to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260].
  iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure)
  iscsiadm: Could not log into all portals

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



From 1329214 at bugs.launchpad.net  Wed Oct 15 03:50:20 2014
From: 1329214 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 15 Oct 2014 03:50:20 -0000
Subject: [Openstack-security] [Bug 1329214] Fix proposed to cinder
	(proposed/juno)
References: <20140612080140.21505.11780.malonedeb@gac.canonical.com>
Message-ID: <20141015035021.25315.39416.malone@soybean.canonical.com>

Fix proposed to branch: proposed/juno
Review: https://review.openstack.org/128507

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

Title:
  tgtadm iscsi chap does not work

Status in Cinder:
  In Progress

Bug description:
  When using LVMISCSIDriver and iscsi_helper tgtadm, it should support chap unidirectional authentication because target configuration file and db.volume  has record chap user and chap passwd. 
  By testing, I found that tgtadm iscsi chap does not work.
  Is it a security bug for iscsi_helper tgtadm? 

  My detail test work is as follows.
  1. Test details as follows without modify the source code:
  1) Devstack all in one server A(10.250.10.190); another testing server B(10.250.10.191)
  2) create a vm  VM-A  and a cinder volume VOLUME-A, attach VOLUME-A to VM-A
  3) server B directly login the iscsi target that server-A export and get VOLUME-A sucessfully . 
      iscsiadm -m discovery -t sendtargets -p 10.250.10.190
      iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login

  2. Test details as follows with modify the source code:
  1) add creating user/passwd and binding user to tid code before leaving the function TgtAdm:create_iscsi_target. 
          type, name, passwd = chap_auth.split()
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'new',
                        '--user',
                        name,
                        '--password',
                        passwd)
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'bind',
                        '--tid',
                        tid,
                        '--user',
                        name
                        )

  2) try to login VOLUME-A as the steps in item 1, it reported an authorization error as follows.
  root at devaio1:/etc/iscsi#     iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login
  Logging in to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260] (multiple)
  iscsiadm: Could not login to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260].
  iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure)
  iscsiadm: Could not log into all portals

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



From nkinder at redhat.com  Wed Oct 15 04:49:07 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Wed, 15 Oct 2014 04:49:07 -0000
Subject: [Openstack-security] [Bug 1329214] Re: tgtadm iscsi chap does not
	work
References: <20140612080140.21505.11780.malonedeb@gac.canonical.com>
Message-ID: <20141015044907.24784.7589.malone@soybean.canonical.com>

Did CHAP authentication ever work for this case?   I would like to know
if this is a regression.  This seems worthy of a security note since
people might assume that their volumes are protected when they are in-
fact accessible.

** Also affects: ossn
   Importance: Undecided
       Status: New

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

Title:
  tgtadm iscsi chap does not work

Status in Cinder:
  Fix Committed
Status in OpenStack Security Notes:
  New

Bug description:
  When using LVMISCSIDriver and iscsi_helper tgtadm, it should support chap unidirectional authentication because target configuration file and db.volume  has record chap user and chap passwd. 
  By testing, I found that tgtadm iscsi chap does not work.
  Is it a security bug for iscsi_helper tgtadm? 

  My detail test work is as follows.
  1. Test details as follows without modify the source code:
  1) Devstack all in one server A(10.250.10.190); another testing server B(10.250.10.191)
  2) create a vm  VM-A  and a cinder volume VOLUME-A, attach VOLUME-A to VM-A
  3) server B directly login the iscsi target that server-A export and get VOLUME-A sucessfully . 
      iscsiadm -m discovery -t sendtargets -p 10.250.10.190
      iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login

  2. Test details as follows with modify the source code:
  1) add creating user/passwd and binding user to tid code before leaving the function TgtAdm:create_iscsi_target. 
          type, name, passwd = chap_auth.split()
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'new',
                        '--user',
                        name,
                        '--password',
                        passwd)
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'bind',
                        '--tid',
                        tid,
                        '--user',
                        name
                        )

  2) try to login VOLUME-A as the steps in item 1, it reported an authorization error as follows.
  root at devaio1:/etc/iscsi#     iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login
  Logging in to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260] (multiple)
  iscsiadm: Could not login to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260].
  iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure)
  iscsiadm: Could not log into all portals

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



From 1329214 at bugs.launchpad.net  Wed Oct 15 04:49:52 2014
From: 1329214 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 15 Oct 2014 04:49:52 -0000
Subject: [Openstack-security] [Bug 1329214] Re: tgtadm iscsi chap does not
	work
References: <20140612080140.21505.11780.malonedeb@gac.canonical.com>
Message-ID: <20141015044952.4904.45529.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/128478
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=e3563891545c801726d227f752cf99488ed5c7dd
Submitter: Jenkins
Branch:    master

commit e3563891545c801726d227f752cf99488ed5c7dd
Author: Tomoki Sekiyama <tomoki.sekiyama at hds.com>
Date:   Tue Oct 14 19:09:44 2014 -0400

    Fix LVM iSCSI driver tgtadm CHAP authentication
    
    Currently CHAP Authentication in LVM iSCSI driver with tgtadm does not work.
    This is because the tgtadm helper creates the target configuration file
    with an 'IncomingUser' entry, which is ignored by tgtd.
    This patch fixes it to 'incominguser'.
    
    Change-Id: I14871985a2a916834122f849238f05b75726bc1a
    Closes-Bug: #1329214


** Changed in: cinder
       Status: In Progress => Fix Committed

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

Title:
  tgtadm iscsi chap does not work

Status in Cinder:
  Fix Committed
Status in OpenStack Security Notes:
  New

Bug description:
  When using LVMISCSIDriver and iscsi_helper tgtadm, it should support chap unidirectional authentication because target configuration file and db.volume  has record chap user and chap passwd. 
  By testing, I found that tgtadm iscsi chap does not work.
  Is it a security bug for iscsi_helper tgtadm? 

  My detail test work is as follows.
  1. Test details as follows without modify the source code:
  1) Devstack all in one server A(10.250.10.190); another testing server B(10.250.10.191)
  2) create a vm  VM-A  and a cinder volume VOLUME-A, attach VOLUME-A to VM-A
  3) server B directly login the iscsi target that server-A export and get VOLUME-A sucessfully . 
      iscsiadm -m discovery -t sendtargets -p 10.250.10.190
      iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login

  2. Test details as follows with modify the source code:
  1) add creating user/passwd and binding user to tid code before leaving the function TgtAdm:create_iscsi_target. 
          type, name, passwd = chap_auth.split()
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'new',
                        '--user',
                        name,
                        '--password',
                        passwd)
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'bind',
                        '--tid',
                        tid,
                        '--user',
                        name
                        )

  2) try to login VOLUME-A as the steps in item 1, it reported an authorization error as follows.
  root at devaio1:/etc/iscsi#     iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login
  Logging in to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260] (multiple)
  iscsiadm: Could not login to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260].
  iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure)
  iscsiadm: Could not log into all portals

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



From tim.kelsey at hp.com  Wed Oct 15 10:38:01 2014
From: tim.kelsey at hp.com (Tim Kelsey)
Date: Wed, 15 Oct 2014 10:38:01 -0000
Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache
 poisoning by local attacker
References: <20140715043528.2209.47100.malonedeb@gac.canonical.com>
Message-ID: <20141015103805.23414.44686.launchpad@soybean.canonical.com>

** Changed in: ossn
       Status: New => In Progress

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

Title:
  suds client subject to cache poisoning by local attacker

Status in Cinder:
  Fix Released
Status in Cinder havana series:
  Fix Released
Status in Cinder icehouse series:
  Fix Released
Status in Gantt:
  New
Status in OpenStack Compute (Nova):
  Fix Released
Status in Oslo VMware library for OpenStack projects:
  Fix Released
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  In Progress

Bug description:
  
  The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. 

  cinder/requirements.txt:suds>=0.4
  gantt/requirements.txt:suds>=0.4
  nova/requirements.txt:suds>=0.4
  oslo.vmware/requirements.txt:suds>=0.4

  
  The details are available here - 
  https://bugzilla.redhat.com/show_bug.cgi?id=978696
  (CVE-2013-2217)

  Although this is an unlikely attack vector steps should be taken to
  prevent this behaviour. Potential ways to fix this are by explicitly
  setting the cache location to a directory created via
  tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or
  using a custom cache implementation that doesn't load / store pickled
  objects from an insecure location.

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



From 1329214 at bugs.launchpad.net  Wed Oct 15 10:38:20 2014
From: 1329214 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 15 Oct 2014 10:38:20 -0000
Subject: [Openstack-security] [Bug 1329214] Re: tgtadm iscsi chap does not
	work
References: <20140612080140.21505.11780.malonedeb@gac.canonical.com>
Message-ID: <20141015103820.5162.72237.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/128507
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=be3d4604dc0566e0838959d998ff1d37755de6d3
Submitter: Jenkins
Branch:    proposed/juno

commit be3d4604dc0566e0838959d998ff1d37755de6d3
Author: Tomoki Sekiyama <tomoki.sekiyama at hds.com>
Date:   Tue Oct 14 19:09:44 2014 -0400

    Fix LVM iSCSI driver tgtadm CHAP authentication
    
    Currently CHAP Authentication in LVM iSCSI driver with tgtadm does not work.
    This is because the tgtadm helper creates the target configuration file
    with an 'IncomingUser' entry, which is ignored by tgtd.
    This patch fixes it to 'incominguser'.
    
    Change-Id: I14871985a2a916834122f849238f05b75726bc1a
    Closes-Bug: #1329214
    (cherry picked from commit e3563891545c801726d227f752cf99488ed5c7dd)


** Changed in: cinder
       Status: Fix Committed => Fix Released

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

Title:
  tgtadm iscsi chap does not work

Status in Cinder:
  Fix Released
Status in OpenStack Security Notes:
  New

Bug description:
  When using LVMISCSIDriver and iscsi_helper tgtadm, it should support chap unidirectional authentication because target configuration file and db.volume  has record chap user and chap passwd. 
  By testing, I found that tgtadm iscsi chap does not work.
  Is it a security bug for iscsi_helper tgtadm? 

  My detail test work is as follows.
  1. Test details as follows without modify the source code:
  1) Devstack all in one server A(10.250.10.190); another testing server B(10.250.10.191)
  2) create a vm  VM-A  and a cinder volume VOLUME-A, attach VOLUME-A to VM-A
  3) server B directly login the iscsi target that server-A export and get VOLUME-A sucessfully . 
      iscsiadm -m discovery -t sendtargets -p 10.250.10.190
      iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login

  2. Test details as follows with modify the source code:
  1) add creating user/passwd and binding user to tid code before leaving the function TgtAdm:create_iscsi_target. 
          type, name, passwd = chap_auth.split()
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'new',
                        '--user',
                        name,
                        '--password',
                        passwd)
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'bind',
                        '--tid',
                        tid,
                        '--user',
                        name
                        )

  2) try to login VOLUME-A as the steps in item 1, it reported an authorization error as follows.
  root at devaio1:/etc/iscsi#     iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login
  Logging in to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260] (multiple)
  iscsiadm: Could not login to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260].
  iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure)
  iscsiadm: Could not log into all portals

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



From gerrit2 at review.openstack.org  Wed Oct 15 14:50:50 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 15 Oct 2014 14:50:50 +0000
Subject: [Openstack-security] [openstack/barbican] SecurityImpact review
 request change Id6e78c02992a416c820001cdab431134f3953674
Message-ID: <E1XePuc-0000ns-2a@review.openstack.org>


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

Log:
commit 210c7a9691e5fbed6cd83423141b36407ff6d4d5
Author: Tim Kelsey <tim.kelsey at hp.com>
Date:   Wed Oct 15 15:27:23 2014 +0100

    Bumping default ssl_version to TLSv1, in light of POODLE
    
    SecurityImpact
    Change-Id: Id6e78c02992a416c820001cdab431134f3953674




From 1380642 at bugs.launchpad.net  Mon Oct 13 14:12:56 2014
From: 1380642 at bugs.launchpad.net (Akihiro Motoki)
Date: Mon, 13 Oct 2014 14:12:56 -0000
Subject: [Openstack-security] [Bug 1380642] [NEW] Horizon should not log
	token
References: <20141013141256.17942.18062.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141013141256.17942.18062.malonedeb@chaenomeles.canonical.com>

Public bug reported:

It is Horizon version of bug 1327019.
Various modules in openstack_dashboard/api logs token.
In other modules, token value is not logged now and is output as *REDACTED* or some similar string.
In Horizon case, these log lines are simply removed to fix the issue as it seems this logging is unnecessary in most cases.

I don't think this needs to be private based on the discussion in bug
1327019.

  def novaclient(request):
    insecure = getattr(settings, 'OPENSTACK_SSL_NO_VERIFY', False)
    cacert = getattr(settings, 'OPENSTACK_SSL_CACERT', None)
    LOG.debug('novaclient connection created using token "%s" and url "%s"' %
              (request.user.token.id, base.url_for(request, 'compute')))
    c = nova_client.Client(request.user.username,
                           request.user.token.id,
                           project_id=request.user.tenant_id,
                           auth_url=base.url_for(request, 'compute'),
                           insecure=insecure,
                           cacert=cacert,
                           http_log_debug=settings.DEBUG)
    c.client.auth_token = request.user.token.id
    c.client.management_url = base.url_for(request, 'compute')
    return c

** Affects: horizon
     Importance: High
     Assignee: Akihiro Motoki (amotoki)
         Status: New


** Tags: security

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

Title:
  Horizon should not log token

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  It is Horizon version of bug 1327019.
  Various modules in openstack_dashboard/api logs token.
  In other modules, token value is not logged now and is output as *REDACTED* or some similar string.
  In Horizon case, these log lines are simply removed to fix the issue as it seems this logging is unnecessary in most cases.

  I don't think this needs to be private based on the discussion in bug
  1327019.

    def novaclient(request):
      insecure = getattr(settings, 'OPENSTACK_SSL_NO_VERIFY', False)
      cacert = getattr(settings, 'OPENSTACK_SSL_CACERT', None)
      LOG.debug('novaclient connection created using token "%s" and url "%s"' %
                (request.user.token.id, base.url_for(request, 'compute')))
      c = nova_client.Client(request.user.username,
                             request.user.token.id,
                             project_id=request.user.tenant_id,
                             auth_url=base.url_for(request, 'compute'),
                             insecure=insecure,
                             cacert=cacert,
                             http_log_debug=settings.DEBUG)
      c.client.auth_token = request.user.token.id
      c.client.management_url = base.url_for(request, 'compute')
      return c

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



From 1381405 at bugs.launchpad.net  Wed Oct 15 08:41:22 2014
From: 1381405 at bugs.launchpad.net (Abu Shohel Ahmed)
Date: Wed, 15 Oct 2014 08:41:22 -0000
Subject: [Openstack-security] [Bug 1381405] [NEW] user token is not checked
 for UUID type before sending request for token validation
References: <20141015084122.4736.33268.malonedeb@wampee.canonical.com>
Message-ID: <20141015084122.4736.33268.malonedeb@wampee.canonical.com>

Public bug reported:

user token is not checked for UUID type before sending token validation
request.

def _validate_token(self, token, env, retry=True):
                  ...
                if cms.is_pkiz(token):
                    verified = self._verify_pkiz_token(token, token_ids)
                    data = jsonutils.loads(verified)
                    expires = _confirm_token_not_expired(data)
                elif cms.is_asn1_token(token):
                    verified = self._verify_signed_token(token, token_ids)
                    data = jsonutils.loads(verified)
                    expires = _confirm_token_not_expired(data)
                else:
                    data = self._identity_server.verify_token(token,
                                                              retry)

The 'else' allows any value in token which is not in PKI format be sent to the Identity API for token
validation.  A sanitation check here for UUID type can reduce the load for token validation 
towards Identity API

** Affects: keystonemiddleware
     Importance: Undecided
         Status: New


** Tags: security

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

Title:
  user token is not checked for UUID type before sending request for
  token validation

Status in OpenStack Identity  (Keystone) Middleware:
  New

Bug description:
  user token is not checked for UUID type before sending token
  validation request.

  def _validate_token(self, token, env, retry=True):
                    ...
                  if cms.is_pkiz(token):
                      verified = self._verify_pkiz_token(token, token_ids)
                      data = jsonutils.loads(verified)
                      expires = _confirm_token_not_expired(data)
                  elif cms.is_asn1_token(token):
                      verified = self._verify_signed_token(token, token_ids)
                      data = jsonutils.loads(verified)
                      expires = _confirm_token_not_expired(data)
                  else:
                      data = self._identity_server.verify_token(token,
                                                                retry)

  The 'else' allows any value in token which is not in PKI format be sent to the Identity API for token
  validation.  A sanitation check here for UUID type can reduce the load for token validation 
  towards Identity API

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



From tomoki.sekiyama at hds.com  Wed Oct 15 15:31:00 2014
From: tomoki.sekiyama at hds.com (Tomoki Sekiyama)
Date: Wed, 15 Oct 2014 15:31:00 -0000
Subject: [Openstack-security] [Bug 1329214] Re: tgtadm iscsi chap does not
	work
References: <20140612080140.21505.11780.malonedeb@gac.canonical.com>
Message-ID: <20141015153100.17807.35632.malone@chaenomeles.canonical.com>

Hi Nathan,

I'm not sure if it had worked, but it seems already broken in Jan '14 according to this page:
https://ask.openstack.org/en/users/2406/ale/?sort=recent

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

Title:
  tgtadm iscsi chap does not work

Status in Cinder:
  Fix Released
Status in OpenStack Security Notes:
  New

Bug description:
  When using LVMISCSIDriver and iscsi_helper tgtadm, it should support chap unidirectional authentication because target configuration file and db.volume  has record chap user and chap passwd. 
  By testing, I found that tgtadm iscsi chap does not work.
  Is it a security bug for iscsi_helper tgtadm? 

  My detail test work is as follows.
  1. Test details as follows without modify the source code:
  1) Devstack all in one server A(10.250.10.190); another testing server B(10.250.10.191)
  2) create a vm  VM-A  and a cinder volume VOLUME-A, attach VOLUME-A to VM-A
  3) server B directly login the iscsi target that server-A export and get VOLUME-A sucessfully . 
      iscsiadm -m discovery -t sendtargets -p 10.250.10.190
      iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login

  2. Test details as follows with modify the source code:
  1) add creating user/passwd and binding user to tid code before leaving the function TgtAdm:create_iscsi_target. 
          type, name, passwd = chap_auth.split()
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'new',
                        '--user',
                        name,
                        '--password',
                        passwd)
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'bind',
                        '--tid',
                        tid,
                        '--user',
                        name
                        )

  2) try to login VOLUME-A as the steps in item 1, it reported an authorization error as follows.
  root at devaio1:/etc/iscsi#     iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login
  Logging in to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260] (multiple)
  iscsiadm: Could not login to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260].
  iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure)
  iscsiadm: Could not log into all portals

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



From 1381405 at bugs.launchpad.net  Wed Oct 15 16:22:05 2014
From: 1381405 at bugs.launchpad.net (Dolph Mathews)
Date: Wed, 15 Oct 2014 16:22:05 -0000
Subject: [Openstack-security] [Bug 1381405] Re: user token is not checked
 for UUID type before sending request for token validation
References: <20141015084122.4736.33268.malonedeb@wampee.canonical.com>
Message-ID: <20141015162205.18413.63472.malone@chaenomeles.canonical.com>

What is the misbehavior?

** Changed in: keystonemiddleware
       Status: New => Incomplete

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

Title:
  user token is not checked for UUID type before sending request for
  token validation

Status in OpenStack Identity  (Keystone) Middleware:
  Incomplete

Bug description:
  user token is not checked for UUID type before sending token
  validation request.

  def _validate_token(self, token, env, retry=True):
                    ...
                  if cms.is_pkiz(token):
                      verified = self._verify_pkiz_token(token, token_ids)
                      data = jsonutils.loads(verified)
                      expires = _confirm_token_not_expired(data)
                  elif cms.is_asn1_token(token):
                      verified = self._verify_signed_token(token, token_ids)
                      data = jsonutils.loads(verified)
                      expires = _confirm_token_not_expired(data)
                  else:
                      data = self._identity_server.verify_token(token,
                                                                retry)

  The 'else' allows any value in token which is not in PKI format be sent to the Identity API for token
  validation.  A sanitation check here for UUID type can reduce the load for token validation 
  towards Identity API

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



From bdpayne at acm.org  Wed Oct 15 17:47:01 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Wed, 15 Oct 2014 10:47:01 -0700
Subject: [Openstack-security] Elections for OSSG lead
In-Reply-To: <A0C170085C37664D93EE1604364858A112472CD8@G4W3300.americas.hpqcorp.net>
References: <A0C170085C37664D93EE1604364858A112472CD8@G4W3300.americas.hpqcorp.net>
Message-ID: <CAFpPvXDNWiqjawQzotptrHnfpA1jHoY4TEf+bQ5eRM4edjpMww@mail.gmail.com>

Just a reminder that this Sunday is the last day to announce your candidacy
for the OSSG Lead position.  As of today, we have zero candidates, but I
know that there are people who are interested.  Please go ahead and add
your name to the list!

Cheers,
-bryan



On Sat, Oct 4, 2014 at 4:48 AM, Clark, Robert Graham <robert.clark at hp.com>
wrote:

> Hi All,
>
>
>
> It gives me great pleasure to open the election process for OSSG
> leadership.
>
>
>
> This is the second time the OSSG has had the opportunity to elect
> leadership since the OSSG began nearly three years ago.  The term for
> this position will begin at the Kilo Summit in Paris (November 2014) and
> end at the 'L' Summit in Vancouver (May 2015). The elected leader will be
> responsible for holding a new election to fill the OSSG Lead position for
> the following term. There are no term limits (an individual may be
> re-elected as many times as the community chooses).
>
>
>
> Any member of the election electorate (see wiki for details) can propose
> his/her candidacy for the same election. No nomination is required. They do
> so by sending an email to the openstack-security at lists.openstack.org
> mailing-list, using the subject: "OSSG Lead Candidacy". The email may
> include a description of the candidate platform. The candidacy is then
> confirmed by one of the election officials, after verification of the
> electorate status of the candidate.
>
>
>
> Please read more at the wiki entry here:
> http://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Fall_2014
>
>
>
> Thank you all for being a part of the community and good luck to all the
> candidates!
>
>
>
> -Rob
>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141015/efc9da86/attachment.html>

From cody.bunch at rackspace.com  Wed Oct 15 18:37:55 2014
From: cody.bunch at rackspace.com (Cody Bunch)
Date: Wed, 15 Oct 2014 18:37:55 +0000
Subject: [Openstack-security] Elections for OSSG lead
In-Reply-To: <CAFpPvXDNWiqjawQzotptrHnfpA1jHoY4TEf+bQ5eRM4edjpMww@mail.gmail.com>
References: <A0C170085C37664D93EE1604364858A112472CD8@G4W3300.americas.hpqcorp.net>,
 <CAFpPvXDNWiqjawQzotptrHnfpA1jHoY4TEf+bQ5eRM4edjpMww@mail.gmail.com>
Message-ID: <327FAB32C28C564DAA23CE6D03789DBCC74ADEF5@ORD1EXD01.RACKSPACE.CORP>

Is there a page that lists the responsibilities of said lead? I think it'd be helpful to understand the time commitment involved so one could weigh it against other responsibilities and commitments.

-C

________________________________
From: Bryan D. Payne [bdpayne at acm.org]
Sent: Wednesday, October 15, 2014 12:47 PM
To: Clark, Robert Graham
Cc: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] Elections for OSSG lead

Just a reminder that this Sunday is the last day to announce your candidacy for the OSSG Lead position.  As of today, we have zero candidates, but I know that there are people who are interested.  Please go ahead and add your name to the list!

Cheers,
-bryan



On Sat, Oct 4, 2014 at 4:48 AM, Clark, Robert Graham <robert.clark at hp.com<mailto:robert.clark at hp.com>> wrote:
Hi All,

It gives me great pleasure to open the election process for OSSG leadership.

This is the second time the OSSG has had the opportunity to elect leadership since the OSSG began nearly three years ago.  The term for this position will begin at the Kilo Summit in Paris (November 2014) and end at the 'L' Summit in Vancouver (May 2015). The elected leader will be responsible for holding a new election to fill the OSSG Lead position for the following term. There are no term limits (an individual may be re-elected as many times as the community chooses).

Any member of the election electorate (see wiki for details) can propose his/her candidacy for the same election. No nomination is required. They do so by sending an email to the openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org> mailing-list, using the subject: "OSSG Lead Candidacy". The email may include a description of the candidate platform. The candidacy is then confirmed by one of the election officials, after verification of the electorate status of the candidate.

Please read more at the wiki entry here: http://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Fall_2014

Thank you all for being a part of the community and good luck to all the candidates!

-Rob


_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141015/67cb3df1/attachment.html>

From bdpayne at acm.org  Wed Oct 15 18:48:15 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Wed, 15 Oct 2014 11:48:15 -0700
Subject: [Openstack-security] Elections for OSSG lead
In-Reply-To: <327FAB32C28C564DAA23CE6D03789DBCC74ADEF5@ORD1EXD01.RACKSPACE.CORP>
References: <A0C170085C37664D93EE1604364858A112472CD8@G4W3300.americas.hpqcorp.net>
 <CAFpPvXDNWiqjawQzotptrHnfpA1jHoY4TEf+bQ5eRM4edjpMww@mail.gmail.com>
 <327FAB32C28C564DAA23CE6D03789DBCC74ADEF5@ORD1EXD01.RACKSPACE.CORP>
Message-ID: <CAFpPvXDPXK8+MLArsUALefJJ86Sn3Acttf4LxAjgn+w++0ksmg@mail.gmail.com>

Fair question.  Perhaps Rob can provide some details as he is the current
lead?

I have also served in this role (in an unelected capacity!) in the past.  I
found the lead position to take a fair amount of time... perhaps 5-10 hours
per week.  Tasks include:

- setting the overall direction for the group and making that vision a
reality
- running the weekly IRC meetings
- coordinating with the team leads to ensure work is progressing (this
currently includes OSSN, book, and threat modeling)
- coordinating mid-cycle meetups
- advocating for security throughout the openstack community (mailing list,
conference talking slots, etc)
- serving as a liaison to the VMT

I'm probably missing some things too.  I'll let Rob fill in the remaining
details :-)

Cheers,
-bryan

On Wed, Oct 15, 2014 at 11:37 AM, Cody Bunch <cody.bunch at rackspace.com>
wrote:

>  Is there a page that lists the responsibilities of said lead? I think
> it'd be helpful to understand the time commitment involved so one could
> weigh it against other responsibilities and commitments.
>
>  -C
>
>  ------------------------------
> *From:* Bryan D. Payne [bdpayne at acm.org]
> *Sent:* Wednesday, October 15, 2014 12:47 PM
> *To:* Clark, Robert Graham
> *Cc:* openstack-security at lists.openstack.org
> *Subject:* Re: [Openstack-security] Elections for OSSG lead
>
>   Just a reminder that this Sunday is the last day to announce your
> candidacy for the OSSG Lead position.  As of today, we have zero
> candidates, but I know that there are people who are interested.  Please go
> ahead and add your name to the list!
>
>  Cheers,
> -bryan
>
>
>
> On Sat, Oct 4, 2014 at 4:48 AM, Clark, Robert Graham <robert.clark at hp.com>
> wrote:
>
>>  Hi All,
>>
>>
>>
>> It gives me great pleasure to open the election process for OSSG
>> leadership.
>>
>>
>>
>> This is the second time the OSSG has had the opportunity to elect
>> leadership since the OSSG began nearly three years ago.  The term for
>> this position will begin at the Kilo Summit in Paris (November 2014) and
>> end at the 'L' Summit in Vancouver (May 2015). The elected leader will be
>> responsible for holding a new election to fill the OSSG Lead position for
>> the following term. There are no term limits (an individual may be
>> re-elected as many times as the community chooses).
>>
>>
>>
>> Any member of the election electorate (see wiki for details) can propose
>> his/her candidacy for the same election. No nomination is required. They do
>> so by sending an email to the openstack-security at lists.openstack.org
>> mailing-list, using the subject: "OSSG Lead Candidacy". The email may
>> include a description of the candidate platform. The candidacy is then
>> confirmed by one of the election officials, after verification of the
>> electorate status of the candidate.
>>
>>
>>
>> Please read more at the wiki entry here:
>> http://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Fall_2014
>>
>>
>>
>> Thank you all for being a part of the community and good luck to all the
>> candidates!
>>
>>
>>
>> -Rob
>>
>>
>>
>> _______________________________________________
>> Openstack-security mailing list
>> Openstack-security at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141015/146d43d8/attachment.html>

From robert.clark at hp.com  Wed Oct 15 18:50:00 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Wed, 15 Oct 2014 18:50:00 +0000
Subject: [Openstack-security] OSSG Lead Candidacy
Message-ID: <A0C170085C37664D93EE1604364858A11248F0AC@G9W0763.americas.hpqcorp.net>

Friends,

 

After discussing this with a number of you and reaffirming support from my employer it gives me great pleasure to announce my
candidacy for leadership of the OpenStack Security Group.

 

We've achieved a magnificent amount in the last six months, developing existing processes and inventing some cool new technologies!
Security notes are providing serious value to the community with almost 40 issued. Bandit - the static analysis framework built by
several OSSG members is now in stackforge and ready for primetime. Additionally we had our first mid-cycle meet up in Seattle, which
was a resounding success - it was great to break bread with so many of you.

 

In the future I'd like to continue with these high visibility initiatives, I'd like see core OpenStack projects adopting Bandit and
engaging with the Threat modelling process - we learned at the meet up that without support from core's it doesn't work. The
credibility we have built up over the last release is allowing us to positively engage with developers on this work.

 

To reiterate, I think we've come a long way, we've achieved a heck of a lot but there's a lot more to do, big problems to solve and
significant barriers to overcome. We've built up a great amount of momentum and it would be my honour to continue driving this
forward for the next release.

 

Thanks,

-Rob

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141015/4a531a96/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6187 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141015/4a531a96/attachment.bin>

From robert.clark at hp.com  Wed Oct 15 18:58:18 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Wed, 15 Oct 2014 18:58:18 +0000
Subject: [Openstack-security] Elections for OSSG lead
In-Reply-To: <CAFpPvXDPXK8+MLArsUALefJJ86Sn3Acttf4LxAjgn+w++0ksmg@mail.gmail.com>
References: <A0C170085C37664D93EE1604364858A112472CD8@G4W3300.americas.hpqcorp.net>
 <CAFpPvXDNWiqjawQzotptrHnfpA1jHoY4TEf+bQ5eRM4edjpMww@mail.gmail.com>
 <327FAB32C28C564DAA23CE6D03789DBCC74ADEF5@ORD1EXD01.RACKSPACE.CORP>
 <CAFpPvXDPXK8+MLArsUALefJJ86Sn3Acttf4LxAjgn+w++0ksmg@mail.gmail.com>
Message-ID: <A0C170085C37664D93EE1604364858A11248F0DD@G9W0763.americas.hpqcorp.net>

Hi Cody,

 

I think you’d probably make a great leader of the OSSG, it takes a big commitment, I’ve just announced my candidacy – I was waiting because I wanted others to announce if they were interested without the incumbent being in the way. 

 

To add to Bryan’s list, the overall direction stuff is hard, requires a lot of politicking behind the scenes, a good example of that is how I have had to fight in the past to have a separate security track at the summit or how we have built up our reputation with the VMT and now consult regularly on vulnerability reports.

 

There’s lots of trying to bring organisations into the fold, trying to get cooperation at a high lever (more FTE towards security, OSSG etc) but that’s getting better over time with more organisations recognising what the OSSG is trying to accomplish.

 

In general you can take it wherever you want I suppose that’s part of the virtue of it but also the risk. I’m happy to expand on any specific tasks or points below :)

 

Cheers

-Rob

 

From: bdpayne at gmail.com [mailto:bdpayne at gmail.com] On Behalf Of Bryan D. Payne
Sent: 15 October 2014 19:48
To: Cody Bunch
Cc: Clark, Robert Graham; openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] Elections for OSSG lead

 

Fair question.  Perhaps Rob can provide some details as he is the current lead?

 

I have also served in this role (in an unelected capacity!) in the past.  I found the lead position to take a fair amount of time... perhaps 5-10 hours per week.  Tasks include:

 

- setting the overall direction for the group and making that vision a reality

- running the weekly IRC meetings

- coordinating with the team leads to ensure work is progressing (this currently includes OSSN, book, and threat modeling)

- coordinating mid-cycle meetups

- advocating for security throughout the openstack community (mailing list, conference talking slots, etc)

- serving as a liaison to the VMT

 

I'm probably missing some things too.  I'll let Rob fill in the remaining details :-)

 

Cheers,

-bryan

 

On Wed, Oct 15, 2014 at 11:37 AM, Cody Bunch <cody.bunch at rackspace.com <mailto:cody.bunch at rackspace.com> > wrote:

Is there a page that lists the responsibilities of said lead? I think it'd be helpful to understand the time commitment involved so one could weigh it against other responsibilities and commitments.  

 

-C

 


  _____  


From: Bryan D. Payne [bdpayne at acm.org <mailto:bdpayne at acm.org> ]
Sent: Wednesday, October 15, 2014 12:47 PM
To: Clark, Robert Graham
Cc: openstack-security at lists.openstack.org <mailto:openstack-security at lists.openstack.org> 
Subject: Re: [Openstack-security] Elections for OSSG lead

Just a reminder that this Sunday is the last day to announce your candidacy for the OSSG Lead position.  As of today, we have zero candidates, but I know that there are people who are interested.  Please go ahead and add your name to the list! 

 

Cheers,

-bryan

 

 

 

On Sat, Oct 4, 2014 at 4:48 AM, Clark, Robert Graham <robert.clark at hp.com <mailto:robert.clark at hp.com> > wrote:

Hi All,

 

It gives me great pleasure to open the election process for OSSG leadership. 

 

This is the second time the OSSG has had the opportunity to elect leadership since the OSSG began nearly three years ago.  The term for this position will begin at the Kilo Summit in Paris (November 2014) and end at the 'L' Summit in Vancouver (May 2015). The elected leader will be responsible for holding a new election to fill the OSSG Lead position for the following term. There are no term limits (an individual may be re-elected as many times as the community chooses).

 

Any member of the election electorate (see wiki for details) can propose his/her candidacy for the same election. No nomination is required. They do so by sending an email to the openstack-security at lists.openstack.org <mailto:openstack-security at lists.openstack.org>  mailing-list, using the subject: "OSSG Lead Candidacy". The email may include a description of the candidate platform. The candidacy is then confirmed by one of the election officials, after verification of the electorate status of the candidate.

 

Please read more at the wiki entry here: http://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Fall_2014 

 

Thank you all for being a part of the community and good luck to all the candidates!

 

-Rob

 


_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org <mailto:Openstack-security at lists.openstack.org> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141015/edb56a45/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6187 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141015/edb56a45/attachment.bin>

From bdpayne at acm.org  Wed Oct 15 19:25:09 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Wed, 15 Oct 2014 12:25:09 -0700
Subject: [Openstack-security] OSSG Lead Candidacy
In-Reply-To: <A0C170085C37664D93EE1604364858A11248F0AC@G9W0763.americas.hpqcorp.net>
References: <A0C170085C37664D93EE1604364858A11248F0AC@G9W0763.americas.hpqcorp.net>
Message-ID: <CAFpPvXAQXNC1sxkgT1m+xMyMREe9+j-9nfV5UmrjsNRh3FZevg@mail.gmail.com>

I confirm that Rob is eligible to run.

Cheers,
-bryan

On Wed, Oct 15, 2014 at 11:50 AM, Clark, Robert Graham <robert.clark at hp.com>
wrote:

> Friends,
>
>
>
> After discussing this with a number of you and reaffirming support from my
> employer it gives me great pleasure to announce my candidacy for leadership
> of the OpenStack Security Group.
>
>
>
> We’ve achieved a magnificent amount in the last six months, developing
> existing processes and inventing some cool new technologies! Security notes
> are providing serious value to the community with almost 40 issued. Bandit
> – the static analysis framework built by several OSSG members is now in
> stackforge and ready for primetime. Additionally we had our first mid-cycle
> meet up in Seattle, which was a resounding success – it was great to break
> bread with so many of you.
>
>
>
> In the future I’d like to continue with these high visibility initiatives,
> I’d like see core OpenStack projects adopting Bandit and engaging with the
> Threat modelling process – we learned at the meet up that without support
> from core’s it doesn’t work. The credibility we have built up over the last
> release is allowing us to positively engage with developers on this work.
>
>
>
> To reiterate, I think we’ve come a long way, we’ve achieved a heck of a
> lot but there’s a lot more to do, big problems to solve and significant
> barriers to overcome. We’ve built up a great amount of momentum and it
> would be my honour to continue driving this forward for the next release.
>
>
>
> Thanks,
>
> -Rob
>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141015/dcb54137/attachment.html>

From cody.bunch at rackspace.com  Wed Oct 15 19:28:26 2014
From: cody.bunch at rackspace.com (Cody Bunch)
Date: Wed, 15 Oct 2014 19:28:26 +0000
Subject: [Openstack-security] OSSG Lead Candidacy
Message-ID: <327FAB32C28C564DAA23CE6D03789DBCC74AEFE5@ORD1EXD01.RACKSPACE.CORP>

Hello All!

I am going to throw my hat in the ring for the leadership position in the OSSG.

I wish I was better at the self description bit, however, I do look forward to the opportunity to helping the OSSG continue to do great things. I have spoken at the summit a few times on the journey to compliance with OpenStack and participated in the writing on the the Security Guide.

Thanks for your consideration,
-C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141015/f4e8ac1b/attachment.html>

From bdpayne at acm.org  Wed Oct 15 19:31:14 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Wed, 15 Oct 2014 12:31:14 -0700
Subject: [Openstack-security] OSSG Lead Candidacy
In-Reply-To: <327FAB32C28C564DAA23CE6D03789DBCC74AEFE5@ORD1EXD01.RACKSPACE.CORP>
References: <327FAB32C28C564DAA23CE6D03789DBCC74AEFE5@ORD1EXD01.RACKSPACE.CORP>
Message-ID: <CAFpPvXAoKZd5MTJgjFkR1pmXmyh+9A0TK=TMq5huY_rNBQ9DRg@mail.gmail.com>

I confirm that Cody is eligible to run.

Cheers,
-bryan



On Wed, Oct 15, 2014 at 12:28 PM, Cody Bunch <cody.bunch at rackspace.com>
wrote:

>  Hello All!
>
>  I am going to throw my hat in the ring for the leadership position in
> the OSSG.
>
>  I wish I was better at the self description bit, however, I do look
> forward to the opportunity to helping the OSSG continue to do great things.
> I have spoken at the summit a few times on the journey to compliance with
> OpenStack and participated in the writing on the the Security Guide.
>
>  Thanks for your consideration,
> -C
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141015/6f927f7f/attachment.html>

From 1334926 at bugs.launchpad.net  Wed Oct 15 22:21:17 2014
From: 1334926 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 15 Oct 2014 22:21:17 -0000
Subject: [Openstack-security] [Bug 1334926] Change abandoned on neutron
	(master)
References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com>
Message-ID: <20141015222117.32267.2829.malone@gac.canonical.com>

Change abandoned by Carl Baldwin (carl at ecbaldwin.net) on branch: master
Review: https://review.openstack.org/121689
Reason: I'll restore this change when the spec is up.

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

Title:
  floatingip still working once connected even after it is disociated

Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in neutron icehouse series:
  Fix Released
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  After we create an SSH connection to a VM via its floating ip, even
  though we have removed the floating ip association, we can still
  access the VM via that connection. Namely, SSH is not disconnected
  when the floating ip is not valid

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 08:15:34 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 08:15:34 -0000
Subject: [Openstack-security] [Bug 1236675] Re: Keystone getting oauth
 access token by brute-forcing oauth_verifier code
References: <20131008030759.26826.41914.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141016081536.376.80726.launchpad@gac.canonical.com>

** Changed in: keystone
    Milestone: juno-1 => 2014.2

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

Title:
  Keystone getting oauth access token by brute-forcing oauth_verifier
  code

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  Title: Keystone getting oauth access token by brute-forcing
  oauth_verifier code
  Reporter: Phuong Cao
  Products: openstack/keystone
  Affects: keystone/master branch as of Oct 7th 2013

  Description:
  Phuong Cao reported a vulnerability in OAuth SQL backend of
  keystone/master branch.

  How does the attack work?
  By creating many access token requests with oauth_verifier code selected
  from the range 1000 to 9999,
  an attacker can request a valid access token to a role and a project,
  overriding a user who actually request access to the role and the project.

  Before describing in detail how the attack works, this is how OAuth
  works (summarized from RFC5849)

  1. Alice registers as a consumer with the Openstack admin.
  2. Alice asks the Openstack admin a token with a specified role and a
  project on behalf of Bob (Bob is the owner of the project).
  3. The Openstack admin returns to Alice a request token key.
  4. Alice sends the request token key to Bob to ask for permissions to
  access the project.
  5. Bob authorizes Alice's request token to have access to the project
  with the specified role.
  6. Bob generates an oauth_verifier code ranging from 1000 to 9999, then
  sends back to Alice an oauth_verifier code.
  7. Alice use the oauth_verifier code and the request token key to ask
  the Openstack admin for the access token to the project.

  This is how the attack works:
  At step 4, assuming an attacker can sniff Alice's request token key.
  This can be done by acting as a man in the middle if Alice interacts
  with Keystone using HTTP requests,
  or acting as a local user to list the process arguments if Alice is
  interacts with Keystone using openstack commandline tools (this case is
  similar to CVE 2013-2013).

  Now the attacker has Alice's request token key, he/she need to wait for
  Bob to authorizes Alice's request token (step 5), then repeatedly
  brute-forcing Keystone with the pair(oauth_verifier, Alice's request
  token key) using oauth_verifier from the range 1000 to 9999. Since the
  oauth_verifier is in a short range, and Openstack/Keystone doesn't have
  any mechanism to limit number of requests, the attacker can bruteforce
  for the valid oauth_verifier key until the request token expires.

  A more aggressive way is to keep brute-forcing Keystone until Bob
  authorizes Alice's request token, by doing this the attacker will have
  more chance getting the access token key before Alice.

  Where are the vulnerable code locations?
  Line 210 of sql.py file:
  https://github.com/openstack/keystone/blob/master/keystone/contrib/oauth1/backends/sql.py#L210

  In OAuth SQL backend of keystone/master branch, the oauth_verifier code,
  a fundamental part of OAuth1 protocol, is generated using random numbers
  from 1000 to 9999.
  This is a small range of numbers and it is easy to be guessed/brute-forced.
  This attack is classified as "CWE-330: Use of Insufficiently Random
  Values" (http://cwe.mitre.org/data/definitions/330.html).

  What are the possible fixes?
  We suggest using a long random string (e.g., 32-bit or 64-bit). Using
  os.urandom() is a good one, it has been recommended for generating
  random number for cryptographic purposes.
  A patch is attached in the attached file (please note: we haven't tested
  this patch).

  Where is the exploit code?
  We attach a snippet code that we modify from test_bad_verifier()
  Keystone test case.
  The snippet is a sketch of how oauth_verifier code brute-forcing can be
  implemented.

  What is the affected version?
  The keystone/master on github as of Oct 7th 2013 is affected.

  References:
  Link to oauth1 file and vulnerable code location (sql.py, line #210):
  https://github.com/openstack/keystone/blob/master/keystone/contrib/oauth1/backends/sql.py#L210
  CWE-330: Use of Insufficiently Random Values:
  (http://cwe.mitre.org/data/definitions/330.html).
  RFC5849: http://tools.ietf.org/html/rfc5849
  os.urandom(): http://docs.python.org/2/library/os.html
  OAuth in keystone tutorial:
  http://www.unitedstack.com/blog/oauth-in-keystone/

  # Patch
  --- /tmp/keystone/keystone/contrib/oauth1/backends/sql.py       2013-10-07 17:06:04.170603933 -0500
  +++ /home/vagrant/keystone/keystone/contrib/oauth1/backends/sql.py      2013-10-07 17:01:39.124008733 -0500
  @@ -17,6 +17,8 @@
   import datetime
   import random
   import uuid
  +import os
  +import binascii

   from keystone.common import sql
   from keystone.common.sql import migration
  @@ -207,7 +209,7 @@
               token_ref = self._get_request_token(session, request_token_id)
               token_dict = token_ref.to_dict()
               token_dict['authorizing_user_id'] = user_id
  -            token_dict['verifier'] = str(random.randint(1000, 9999))
  +            token_dict['verifier'] = binascii.b2a_hex(os.urandom(16))
               token_dict['role_ids'] = jsonutils.dumps(role_ids)

               new_token = RequestToken.from_dict(token_dict)

  # Test brute force
  class MaliciousOAuth1Tests(OAuth1Tests):

      # modified from test_bad_verifier()
      def test_bruteforce_verifier(self):
          
          # create consumer for oauth
          consumer = self._create_single_consumer()
          consumer_id = consumer.get('id')
          consumer_secret = consumer.get('secret')
          consumer = oauth1.Consumer(consumer_id, consumer_secret)

          url, headers = self._create_request_token(consumer,
                                                    self.project_id)
          # get request token
          content = self.post(url, headers=headers)
          credentials = urlparse.parse_qs(content.result)
          request_key = credentials.get('oauth_token')[0]
          request_secret = credentials.get('oauth_token_secret')[0]
          request_token = oauth1.Token(request_key, request_secret)

  
          # authorize request token
          url = self._authorize_request_token(request_key)
          
          body = {'roles': [{'id': self.role_id}]}
          resp = self.put(url, body=body, expected_status=200)
          verifier = resp.result['token']['oauth_verifier']
          self.assertIsNotNone(verifier)

          # we are not going to use received oauth_verifier here, instead, we brute-force to find the valid oauth_verifier
          for i in range(1000,10000):
              request_token.set_verifier(str(i))
              url, headers = self._create_access_token(consumer,
                                                       request_token)
              # We expect 401 status code for most of requests since most oauth_verifier code
              # that we try will be invalid.
              # The test will crash at the valid oauth_verifier code when returned status = 201,
              # which is different from the expected 401 status.
              r = self.post(url, headers=headers, expected_status=401)
              
              # Print out oauth_verifier, and raw response request that contains access token.
              if (r == 201): # We have found correct oauth_verifier code
                  print 'oauth_verifier: {}, raw access_token response request: {}'.format(str(i), str(r))

  
  We are looking forward hearing from you.

  Thank you.

  Best,

  Phuong Cao
  Research Assistant
  DEPEND group
  Coordinated Science Laboratory
  University of Illinois at Urbana Champaign
  Urbana, IL 61801, USA

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 08:18:49 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 08:18:49 -0000
Subject: [Openstack-security] [Bug 1335208] Re: Shell injection possibility
	in cmd/control.py
References: <20140627163123.19133.62950.malonedeb@gac.canonical.com>
Message-ID: <20141016081851.17973.10571.launchpad@chaenomeles.canonical.com>

** Changed in: glance
    Milestone: juno-2 => 2014.2

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

Title:
  Shell injection possibility in cmd/control.py

Status in OpenStack Image Registry and Delivery Service (Glance):
  Fix Released
Status in OpenStack Security Advisories:
  Invalid

Bug description:
  The glance/cmd/control.py file contains a possible shell injection
  vulnerability:
  https://github.com/openstack/glance/blob/master/glance/cmd/control.py#L134
  .  Setting 'shell=True' here opens the possibility of shell injection
  by setting server to something like '; rm -rf /'.  This will cause the
  command 'rm -rf /' to be run with the privileges of the user that ran
  Glance.

  This may not be a major security concern at this time because the only
  place that I found for 'server' to come from is a Glance configuration
  file, which should be locked down.  Only privileged users should have
  write access to the config file, and if they want to do bad things on
  the system there are easier ways.

  Still, 'shell=True' appears to be completely unnecessary for this
  call.  Simply omitting the shell parameter here will cause it to
  revert to the default behavior, which requires that the command to be
  run be specified in a separate parameter than the arguments to the
  command.  This effectively prevents shell injection vulnerabilities.

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 08:15:49 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 08:15:49 -0000
Subject: [Openstack-security] [Bug 1299012] Re: V3 api authentication method
	chaining
References: <20140328141330.5958.57146.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141016081551.5296.4633.launchpad@wampee.canonical.com>

** Changed in: keystone
    Milestone: juno-1 => 2014.2

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

Title:
  V3 api authentication method chaining

Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack Security Advisories:
  Invalid

Bug description:
  When using authentication method chaining for token creation (POST)
  in Keystone V3 api , it is possible to use authentication credentials
  for two different users . For example, if i have an existing token for
  a Demo user, say 6bb934a0120f097a32b5d3cc71f83beb ( created earlier
  for demo tenant) and i have a user say 'test131' in admin tenant

  Now i can make an authentication call using auth method chaining

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "token" 
           ],
          "token":{
              "id":"6bb934a0120f097a32b5d3cc71f83beb"
           },
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"test131",
                 "password":"test131"
              }
           }
        }
     }
  }

  The call will succeed even though two different users authentication
  credentials are used.  The generated token will get properties of
  test131 user although the expirary date is set by demo user token.  If
  we change the methods sequence, the generated token will get all
  properties from demo users token.

  
  This is an undesired security behaviour - token should not  be allowed to generate using credentials from two different users.

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 08:18:06 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 08:18:06 -0000
Subject: [Openstack-security] [Bug 1175904] Re: passlib trunc_password
 MAX_PASSWORD_LENGTH password truncation
References: <20130503065124.14566.73303.malonedeb@gac.canonical.com>
Message-ID: <20141016081809.4829.68308.launchpad@wampee.canonical.com>

** Changed in: keystone
    Milestone: juno-2 => 2014.2

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

Title:
  passlib trunc_password MAX_PASSWORD_LENGTH password truncation

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  Grant Murphy originally reported:

  * Insecure / bad practice

     The trunc_password function attempts to correct and truncate passwords 
     that are over the MAX_PASSWORD_LENGTH value (default 4096). As the 
     MAX_PASSWORD_LENGTH field is globally mutable it could be modified 
     to restrict all passwords to length = 1. This scenario might be unlikely 
     but generally speaking we should not try to 'fix' invalid input and 
     continue on processing as if nothing happened. 

  If this is exploitable it will need a CVE, if not we should still
  harden it so it can't be monkeyed with in the future.

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



From 1381405 at bugs.launchpad.net  Thu Oct 16 08:26:01 2014
From: 1381405 at bugs.launchpad.net (Abu Shohel Ahmed)
Date: Thu, 16 Oct 2014 08:26:01 -0000
Subject: [Openstack-security] [Bug 1381405] Re: user token is not checked
 for UUID type before sending request for token validation
References: <20141015084122.4736.33268.malonedeb@wampee.canonical.com>
Message-ID: <20141016082601.5331.59529.malone@wampee.canonical.com>

Everything which is not in PKI format is treated as a UUID token and
send for token validation to the Identity API. IMO,  here exist a
program flow based on an untrusted input (Token) without any sanitation
check.  Any garbage value can take this path possibly
consuming/exhausting system resource.

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

Title:
  user token is not checked for UUID type before sending request for
  token validation

Status in OpenStack Identity  (Keystone) Middleware:
  Incomplete

Bug description:
  user token is not checked for UUID type before sending token
  validation request.

  def _validate_token(self, token, env, retry=True):
                    ...
                  if cms.is_pkiz(token):
                      verified = self._verify_pkiz_token(token, token_ids)
                      data = jsonutils.loads(verified)
                      expires = _confirm_token_not_expired(data)
                  elif cms.is_asn1_token(token):
                      verified = self._verify_signed_token(token, token_ids)
                      data = jsonutils.loads(verified)
                      expires = _confirm_token_not_expired(data)
                  else:
                      data = self._identity_server.verify_token(token,
                                                                retry)

  The 'else' allows any value in token which is not in PKI format be sent to the Identity API for token
  validation.  A sanitation check here for UUID type can reduce the load for token validation 
  towards Identity API

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 08:28:06 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 08:28:06 -0000
Subject: [Openstack-security] [Bug 1319943] Re: libvirt driver's to_xml
 method logs iscsi auth_password if debug
References: <20140515172919.15967.70050.malonedeb@gac.canonical.com>
Message-ID: <20141016082808.17873.46033.launchpad@chaenomeles.canonical.com>

** Changed in: nova
    Milestone: juno-1 => 2014.2

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

Title:
  libvirt driver's to_xml method logs iscsi auth_password if debug

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Compute (nova) icehouse series:
  Fix Released

Bug description:
  If you have debug logging enabled the libvirt driver's to_xml method
  logs the iscsi auth_password in plain text.

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 08:21:27 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 08:21:27 -0000
Subject: [Openstack-security] [Bug 1292283] Re: revocation events: deleting
 a token revokes all tokens with same expiration
References: <20140314003341.30362.66976.malonedeb@gac.canonical.com>
Message-ID: <20141016082129.18130.8040.launchpad@chaenomeles.canonical.com>

** Changed in: keystone
    Milestone: juno-rc1 => 2014.2

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

Title:
  revocation events: deleting a token revokes all tokens with same
  expiration

Status in OpenStack Dashboard (Horizon):
  Invalid
Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  As part of the design process for revocation events it was determined
  that a mechanism to revoke all dependent tokens was needed. This
  covers the case of revoking a token and ensuring all tokens that were
  created from that token are also revoked.

  To accomplish this, the revocation of a specific token is done by
  expiration_time. The expiration_time attribute is never changed on
  subsequent tokens. This means it is easy to ensure revocation of an
  entire chain of tokens.

  This poses an issue if any specific token (or all tokens that are a
  child of a specific token) should be revoked, but the parent tokens
  should not be revoked.

  Use case:

  Get Unscoped token
  Get Scoped Token from Unscoped token
  Get New Scoped Token
  Revoke first unscoped token
  Now all tokens (including the Unscoped token) are revoked because they share an expiration_time.

  Likely there needs to be a solution that allows for revoking based
  upon expiration_time and issued_at and one that revokes on
  expiration_time alone. Revoking by expiration_time alone is API
  incompatible with previous API mechanisms (both V2 and V3).

  This is the reason bug https://bugs.launchpad.net/horizon/+bug/1291099
  was identified.

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 08:43:52 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 08:43:52 -0000
Subject: [Openstack-security] [Bug 1334938] Re: established floating ip
 connection won't get disconnected after disassociating floating ip
References: <20140627031928.26375.32794.malonedeb@wampee.canonical.com>
Message-ID: <20141016084354.341.83654.launchpad@gac.canonical.com>

** Changed in: nova
    Milestone: juno-2 => 2014.2

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

Title:
  established floating ip connection won't get disconnected after
  disassociating floating ip

Status in OpenStack Compute (Nova):
  Fix Released

Bug description:
  Established connections via floating ip won't get disconnected after
  we disassociating that floating ip.

  As mentioned in maillist by Vish, we should move clean_conntrack() from migration code to  remove_floating_ip.
  https://github.com/openstack/nova/blob/master/nova/network/floating_ips.py#L575

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 08:43:05 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 08:43:05 -0000
Subject: [Openstack-security] [Bug 1320028] Re: libvirt volume.py's
 _run_iscsiadm function logs iscsi node.session.auth.password if debug
References: <20140515234022.31230.32833.malonedeb@soybean.canonical.com>
Message-ID: <20141016084308.4829.53965.launchpad@wampee.canonical.com>

** Changed in: nova
    Milestone: juno-2 => 2014.2

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

Title:
  libvirt volume.py's _run_iscsiadm function logs iscsi
  node.session.auth.password if debug

Status in OpenStack Compute (Nova):
  Fix Released
Status in The Oslo library incubator:
  Fix Released

Bug description:
  If debug logging is enabled, the  _run_iscsiadm function in volume.py
  logs the iscsi node.session.auth.password in plain text.

  2014-05-13 08:12:21.915 29013 DEBUG nova.virt.libvirt.volume [req-
  d21bb680-feb9-4242-9d18-057af79d26e8 0
  3112d0d7268b458bb5c997c33cd8a8c0] iscsiadm ('--op', 'update', '-n',
  'node.session.auth.password', '-v', u'password'): stdout= stderr=
  _run_iscsiadm /usr/lib/python2.7/site-
  packages/nova/virt/libvirt/volume.py:248

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 08:31:27 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 08:31:27 -0000
Subject: [Openstack-security] [Bug 1308727] Re: [OSSA 2014-023] XSS in
 Horizon Heat template - resource name (CVE-2014-3473)
References: <20140416193338.27100.82700.malonedeb@gac.canonical.com>
Message-ID: <20141016083130.25484.19013.launchpad@soybean.canonical.com>

** Changed in: horizon
    Milestone: juno-2 => 2014.2

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

Title:
  [OSSA 2014-023] XSS in Horizon Heat template - resource name
  (CVE-2014-3473)

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Dashboard (Horizon) havana series:
  Fix Released
Status in OpenStack Dashboard (Horizon) icehouse series:
  Fix Released
Status in OpenStack Security Advisories:
  Fix Released

Bug description:
  The attached yaml will result in a Cross Site Script when viewing the
  resources or events of an Orchestration stack in the following paths:

  /project/stacks/stack/{stack_id}/?tab=stack_details__resources
  /project/stacks/stack/{stack_id}/?tab=stack_details__events

  The A tag's href attribute does not properly URL encode the name of
  the resource string resulting in escaping out of the attribute and
  arbitrary HTML written to the page.

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 08:53:49 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 08:53:49 -0000
Subject: [Openstack-security] [Bug 1369627] Re: libvirt disk.config will
 have issues when booting two with different config drive values
References: <20140915153310.17745.11485.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141016085351.18087.52374.launchpad@chaenomeles.canonical.com>

** Changed in: nova
    Milestone: juno-rc1 => 2014.2

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

Title:
  libvirt disk.config will have issues when booting two with different
  config drive values

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Currently, in the image creating code for Juno we have

          if configdrive.required_by(instance):
              LOG.info(_LI('Using config drive'), instance=instance)

              image_type = self._get_configdrive_image_type()
              backend = image('disk.config', image_type)
              backend.cache(fetch_func=self._create_configdrive,
                            filename='disk.config' + suffix,
                            instance=instance,
                            admin_pass=admin_pass,
                            files=files,
                            network_info=network_info)

  The important thing to notice here is that we have
  "filename='disk.confg' + suffix".  This means that the filename for
  the config drive in the cache directory will be simply 'disk.config'
  followed by any potential suffix (e.g. '.rescue').  This name is not
  unique to the instance whose config drive we are creating.  Therefore,
  when we go to boot another instance with a different config drive, the
  cache function will detect the old config drive, and decide it doesn't
  need to create the new config drive with the appropriate config for
  the new instance.

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 08:59:17 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 08:59:17 -0000
Subject: [Openstack-security] [Bug 1369487] Re: NIST: increase RSA key
	length to 2048 bit
References: <20140915100120.18130.90286.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141016085919.32349.34466.launchpad@gac.canonical.com>

** Changed in: nova
    Milestone: juno-rc1 => 2014.2

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

Title:
  NIST: increase RSA key length to 2048 bit

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  According to NIST 800-131A, RSA key lenght for digital signature must
  >= 2048 bit.

  In crypto.py, we use 1024 bit as the default key length to generate
  cert file, and does not specify any larger number to override the
  default value when utilizing it.

  def generate_x509_cert(user_id, project_id, bits=1024):

  Need to increase the default key length to 2048 bit.

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 09:18:40 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 09:18:40 -0000
Subject: [Openstack-security] [Bug 1367238] Re: IBM NAS cinder driver sets
 'rw' permissions to all during volume create operation,
 which is security issue
References: <20140909112305.32185.63569.malonedeb@gac.canonical.com>
Message-ID: <20141016091842.310.97725.launchpad@gac.canonical.com>

** Changed in: cinder
    Milestone: juno-rc1 => 2014.2

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

Title:
  IBM NAS cinder driver sets 'rw' permissions to all during volume
  create operation, which is security issue

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

Bug description:
  IBM NAS cinder driver sets 'rw' permissions to all during volume create operation from a volume snapshot or from an existing volume (volume clone operation).
  This is not required as 'rw' permissions to the user only should be sufficient.
  This also helps resolve the security issue setting 'rw' permissions to all.

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 08:58:22 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 08:58:22 -0000
Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache
 poisoning by local attacker
References: <20140715043528.2209.47100.malonedeb@gac.canonical.com>
Message-ID: <20141016085826.17616.26321.launchpad@chaenomeles.canonical.com>

** Changed in: nova
    Milestone: juno-rc1 => 2014.2

** Changed in: cinder
    Milestone: juno-3 => 2014.2

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

Title:
  suds client subject to cache poisoning by local attacker

Status in Cinder:
  Fix Released
Status in Cinder havana series:
  Fix Released
Status in Cinder icehouse series:
  Fix Released
Status in Gantt:
  New
Status in OpenStack Compute (Nova):
  Fix Released
Status in Oslo VMware library for OpenStack projects:
  Fix Released
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  In Progress

Bug description:
  
  The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. 

  cinder/requirements.txt:suds>=0.4
  gantt/requirements.txt:suds>=0.4
  nova/requirements.txt:suds>=0.4
  oslo.vmware/requirements.txt:suds>=0.4

  
  The details are available here - 
  https://bugzilla.redhat.com/show_bug.cgi?id=978696
  (CVE-2013-2217)

  Although this is an unlikely attack vector steps should be taken to
  prevent this behaviour. Potential ways to fix this are by explicitly
  setting the cache location to a directory created via
  tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or
  using a custom cache implementation that doesn't load / store pickled
  objects from an insecure location.

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 08:53:01 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 08:53:01 -0000
Subject: [Openstack-security] [Bug 1337349] Re: Nova qemu hypervisor host
 smbios serial number is leaked to guest
References: <20140703142824.27562.82896.malonedeb@gac.canonical.com>
Message-ID: <20141016085303.32614.50637.launchpad@gac.canonical.com>

** Changed in: nova
    Milestone: juno-3 => 2014.2

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

Title:
  Nova qemu hypervisor host smbios serial number is leaked to guest

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  Erwan Velu from eNovance reported a vulnerability in OpenStack Nova.

  The hypervisor is passing host system uuid (-smbios version) to guests, and this happen to be a critical info leak.
  The defect have been pinpointed to:
   https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3054

  From a simple virtual machine, this may allow numerous info leak like:
      Allow compute hardware enumeration from guests
      Deduce service tag and get all hardware configuration
      Ability to know if two instances are on the same compute

  Dell hardware is particulary impacted as :
      - the uuid encodes the service tag
      - the service tag can be used on support site to determine:
      - detailled hardware configuration
      - date & country where the hw was shipped
      - date & type of support contract
      - amount of servers bought during this shipment

  If there is no use case for this, we should scrambled that piece of
  information.

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 09:21:14 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 09:21:14 -0000
Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working
 once connected even after it is disociated
References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com>
Message-ID: <20141016092116.17807.8427.launchpad@chaenomeles.canonical.com>

** Changed in: neutron
    Milestone: juno-rc1 => 2014.2

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

Title:
  floatingip still working once connected even after it is disociated

Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in neutron icehouse series:
  Fix Released
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  After we create an SSH connection to a VM via its floating ip, even
  though we have removed the floating ip association, we can still
  access the VM via that connection. Namely, SSH is not disconnected
  when the floating ip is not valid

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 09:21:48 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 09:21:48 -0000
Subject: [Openstack-security] [Bug 1329214] Re: tgtadm iscsi chap does not
	work
References: <20140612080140.21505.11780.malonedeb@gac.canonical.com>
Message-ID: <20141016092150.32745.4357.launchpad@gac.canonical.com>

** Changed in: cinder
    Milestone: juno-rc3 => 2014.2

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

Title:
  tgtadm iscsi chap does not work

Status in Cinder:
  Fix Released
Status in OpenStack Security Notes:
  New

Bug description:
  When using LVMISCSIDriver and iscsi_helper tgtadm, it should support chap unidirectional authentication because target configuration file and db.volume  has record chap user and chap passwd. 
  By testing, I found that tgtadm iscsi chap does not work.
  Is it a security bug for iscsi_helper tgtadm? 

  My detail test work is as follows.
  1. Test details as follows without modify the source code:
  1) Devstack all in one server A(10.250.10.190); another testing server B(10.250.10.191)
  2) create a vm  VM-A  and a cinder volume VOLUME-A, attach VOLUME-A to VM-A
  3) server B directly login the iscsi target that server-A export and get VOLUME-A sucessfully . 
      iscsiadm -m discovery -t sendtargets -p 10.250.10.190
      iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login

  2. Test details as follows with modify the source code:
  1) add creating user/passwd and binding user to tid code before leaving the function TgtAdm:create_iscsi_target. 
          type, name, passwd = chap_auth.split()
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'new',
                        '--user',
                        name,
                        '--password',
                        passwd)
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'bind',
                        '--tid',
                        tid,
                        '--user',
                        name
                        )

  2) try to login VOLUME-A as the steps in item 1, it reported an authorization error as follows.
  root at devaio1:/etc/iscsi#     iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login
  Logging in to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260] (multiple)
  iscsiadm: Could not login to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260].
  iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure)
  iscsiadm: Could not log into all portals

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 08:56:43 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 08:56:43 -0000
Subject: [Openstack-security] [Bug 1321080] Re: [OSSA 2014-021] auth token
 is exposed in meter http.request (CVE-2014-4615)
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20141016085646.18130.73519.launchpad@chaenomeles.canonical.com>

** Changed in: neutron
    Milestone: juno-1 => 2014.2

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

Title:
  [OSSA 2014-021] auth token is exposed in meter http.request
  (CVE-2014-4615)

Status in OpenStack Telemetry (Ceilometer):
  Invalid
Status in Ceilometer havana series:
  Fix Released
Status in Ceilometer icehouse series:
  Fix Committed
Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in neutron icehouse series:
  Fix Released
Status in The Oslo library incubator:
  Fix Released
Status in oslo-incubator havana series:
  Fix Committed
Status in oslo-incubator icehouse series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Released
Status in pyCADF:
  Fix Released

Bug description:
  auth token is exposed in meter http.request

  # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd'
  -H 'Content-Type: application/json' -H 'Accept: application/json' -H
  'User-Agent: python-ceilometerclient'
  http://0.0.0.0:8777/v2/meters/http.request

  -----------
  snip..
  {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0",
  snip...

  auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478".
  But it is exposed in  "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478"

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 09:12:32 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 09:12:32 -0000
Subject: [Openstack-security] [Bug 1320056] Re: Cinder utils SSHPool should
 allow customized ssh host keys and missing policy
References: <20140516032022.25328.55432.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141016091236.17842.77514.launchpad@chaenomeles.canonical.com>

** Changed in: cinder
    Milestone: juno-2 => 2014.2

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

Title:
  Cinder utils SSHPool should allow customized ssh host keys and missing
  policy

Status in Cinder:
  Fix Released
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  In cinder/utils.py, SSHPool is using paramiko.AutoAddPolicy() as
  default. This may lead security issue without being notified. The
  utility should allow customized usage when create the pool or session.
  Also the host_keys file should be allowed to be customized so that any
  driver utilizing the SSHPool should have their customized security
  setting or delegate to customer's scenario & configuration to
  determine the policy and key files.

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 09:10:30 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 09:10:30 -0000
Subject: [Openstack-security] [Bug 1319643] Re: Using random.random() should
 not be used to generate randomness used for security reasons
References: <20140515052815.2825.61709.malonedeb@wampee.canonical.com>
Message-ID: <20141016091032.4767.78152.launchpad@wampee.canonical.com>

** Changed in: cinder
    Milestone: juno-1 => 2014.2

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

Title:
  Using random.random() should not be used to generate randomness used
  for security reasons

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

Bug description:
  In cinder code : /cinder/transfer/api.py . Below line of code used
  random.random() to generate a random number, Standard random number
  generators should not be used to generate randomness used for security
  reasons. Could we use a crytographic randomness generator to provide
  sufficient entropy to instead of it?

  rndstr = ""
  random.seed(datetime.datetime.now().microsecond)
  while len(rndstr) < length:
   rndstr += hashlib.sha224(str(random.random())).hexdigest()   ---------------> This line has described issues. 

   return rndstr[0:length]

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 09:13:05 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 09:13:05 -0000
Subject: [Openstack-security] [Bug 1319639] Re: Standard random number
 generators (using shuffle ) should not be used to generate randomness
References: <20140515051014.31551.82176.malonedeb@soybean.canonical.com>
Message-ID: <20141016091308.32512.88778.launchpad@gac.canonical.com>

** Changed in: cinder
    Milestone: juno-2 => 2014.2

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

Title:
  Standard random number generators (using shuffle )  should not be used
  to generate randomness

Status in Cinder:
  Fix Released

Bug description:
  In cinder code :  /cinder/utils.py . Below two lines of code used
  shuffle to generate a random number, Standard random number generators
  should not be used to generate randomness used for security reasons.
  Could we use a crytographic randomness generator to provide sufficient
  entropy to instead of it?

   # If length < len(symbolgroups), the leading characters will only
   # be from the first length groups. Try our best to not be predictable
   # by shuffling and then truncating.
   r.shuffle(password) ----------------> This line of code has described issue.
   password = password[:length]
   length -= len(password)

  # finally shuffle to ensure first x characters aren't from a
  # predictable group
  r.shuffle(password) ----------------> This line of code has described issue.

  return ''.join(password)

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 08:50:59 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 08:50:59 -0000
Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent
 does not recreate flows after ovsdb-server restarts
References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com>
Message-ID: <20141016085102.4798.84554.launchpad@wampee.canonical.com>

** Changed in: neutron
    Milestone: juno-1 => 2014.2

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

Title:
  neutron-openvswitch-agent does not recreate flows after ovsdb-server
  restarts

Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in neutron icehouse series:
  Fix Released
Status in tripleo - openstack on openstack:
  Fix Released

Bug description:
  The DHCP requests were not being responded to after they were seen on
  the undercloud network interface.  The neutron services were restarted
  in an attempt to ensure they had the newest configuration and knew
  they were supposed to respond to the requests.

  Rather than using the heat stack create (called in
  devtest_overcloud.sh) to test, it was simple to use the following to
  directly boot a baremetal node.

      nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \
            --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \
            bm-test1

  Whilst the baremetal node was attempting to pxe boot a restart of the
  neutron services was performed.  This allowed the baremetal node to
  boot.

  It has been observed that a neutron restart was needed for each
  subsequent reboot of the baremetal nodes to succeed.

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 08:52:20 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 08:52:20 -0000
Subject: [Openstack-security] [Bug 1262759] Re: ICMPv6 RAs should only be
 permitted from known routers
References: <20131219170628.26400.87374.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141016085222.32442.63761.launchpad@gac.canonical.com>

** Changed in: neutron
    Milestone: juno-1 => 2014.2

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

Title:
  ICMPv6 RAs should only be permitted from known routers

Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in OpenStack Security Advisories:
  Invalid

Bug description:
  ICMPv6 is now allowed in from any host but other hosts can offer bogus
  routes.

  Change security group/port filtering to respect known routers:

  - tenant routers attached to subnets and passing v6
  - physical routers on provider networks provided on the network (as some sort of admin configurable list for that network).

  (Security issue: One VM sharing a neutron network can divert outgoing
  traffic from other VMs.)

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



From 1380642 at bugs.launchpad.net  Thu Oct 16 09:43:30 2014
From: 1380642 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 16 Oct 2014 09:43:30 -0000
Subject: [Openstack-security] [Bug 1380642] Re: Horizon should not log token
References: <20141013141256.17942.18062.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141016094330.18348.29187.malone@chaenomeles.canonical.com>

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

** Changed in: horizon
       Status: New => In Progress

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

Title:
  Horizon should not log token

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  It is Horizon version of bug 1327019.
  Various modules in openstack_dashboard/api logs token.
  In other modules, token value is not logged now and is output as *REDACTED* or some similar string.
  In Horizon case, these log lines are simply removed to fix the issue as it seems this logging is unnecessary in most cases.

  I don't think this needs to be private based on the discussion in bug
  1327019.

    def novaclient(request):
      insecure = getattr(settings, 'OPENSTACK_SSL_NO_VERIFY', False)
      cacert = getattr(settings, 'OPENSTACK_SSL_CACERT', None)
      LOG.debug('novaclient connection created using token "%s" and url "%s"' %
                (request.user.token.id, base.url_for(request, 'compute')))
      c = nova_client.Client(request.user.username,
                             request.user.token.id,
                             project_id=request.user.tenant_id,
                             auth_url=base.url_for(request, 'compute'),
                             insecure=insecure,
                             cacert=cacert,
                             http_log_debug=settings.DEBUG)
      c.client.auth_token = request.user.token.id
      c.client.management_url = base.url_for(request, 'compute')
      return c

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 09:48:22 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 09:48:22 -0000
Subject: [Openstack-security] [Bug 1336225] Re: Password is exposed in the
	log file
References: <20140701103304.7888.77002.malonedeb@wampee.canonical.com>
Message-ID: <20141016094824.5362.13238.launchpad@wampee.canonical.com>

** Changed in: heat
    Milestone: juno-2 => 2014.2

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

Title:
  Password is exposed in the log file

Status in Orchestration API (Heat):
  Fix Released

Bug description:
  heat-keystone-setup-domain is logging the password to the log file.
  This defect is filed to remove the logging statement as its security
  concerns

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



From thierry.carrez+lp at gmail.com  Thu Oct 16 09:40:06 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 16 Oct 2014 09:40:06 -0000
Subject: [Openstack-security] [Bug 1321906] Re: [EDP] Swift credentials
	passed in plain text
References: <20140521195819.29499.71748.malonedeb@wampee.canonical.com>
Message-ID: <20141016094007.32675.48924.launchpad@gac.canonical.com>

** Changed in: sahara
    Milestone: juno-rc1 => 2014.2

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

Title:
  [EDP] Swift credentials passed in plain text

Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Data Processing (Sahara, ex. Savanna):
  Fix Released

Bug description:
  For Sahara, we support job binaries and data sources in Swift.  Job
  binaries are accessed from the Sahara process, and data sources are
  accessed from Hadoop at job execution time.  Username/password
  credentials are required for swift access.  These credentials might
  be/are compromised in the following ways:

  1) For both job binaries and data sources, objects are created and
  stored in the Sahara database that contain the path and the associated
  credentials in plain text.  Anyone gaining access to the database can
  therefore read the username/password credentials stored there with the
  swift path.

  2) For data sources, the credentials are passed as part of the Hadoop
  job configuration.  Currently all Hadoop jobs are run as Oozie
  workflows.  The swift username and password values are set in the
  workflow.xml file, and are visible to anyone that can access the Oozie
  UI console, use the Oozie command line to retrieve the workflow.xml,
  or even use hadoop fs to look at the files uploaded for the job (which
  include the workflow.xml)

  We need a way for Sahara and Hadoop to access swift objects securely,
  without exposing swift credentials in workflow.xml or storing them in
  the database in plain text.  In the future we will support mechanisms
  other than Oozie so this is not just an Oozie issue per se.

  For further background, here is the Hadoop patch that allows Hadoop to
  access swift paths.  It uses a service suffix in the netlocation
  portion of the URL to match the URL against credential values in the
  job configuration.  Any solution to this issue will require a new
  patch to Hadoop itself, as well as changes to the Sahara code base.

  https://issues.apache.org/jira/browse/HADOOP-8545

  It's been suggested within the Sahara team that we can potentially
  accomplish this with trusts.

  Note, this vulnerability isn't really a secret to anyone observant who
  is familiar with Sahara EDP, but it is probably better not to trumpet
  it too loudly.

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



From gerrit2 at review.openstack.org  Thu Oct 16 11:51:56 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 16 Oct 2014 11:51:56 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Ibda02ce311b322cf666aadfc8f28e642f98e4edc
Message-ID: <E1Xejb2-0007RC-8O@review.openstack.org>


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

Log:
commit 7c9aa6da92805f20083203a6ec8f93b1b592fc13
Author: He Jie Xu <xuhj at linux.vnet.ibm.com>
Date:   Sun Oct 5 00:20:01 2014 +0800

    Fix pci_request_id break the upgrade from icehouse to juno
    
    commit a8a5d44c8aca218f00649232c2b8a46aee59b77e add pci_request_id
    as one item for the request_network tuple. But the icehouse code
    assume only three items in the tuple.
    
    This patch filters pci_request_id out from the tuple.
    
    Cherry-Pick from:
    https://review.openstack.org/#/c/126144/6
    
    Change-Id: I991e1c68324fe92fac647583f3ec8f6aec637913
    Closes-Bug: #1377447

commit 10a5eecd0973096b57efd31f8b27d7295a44ab89
Author: Andreas Jaeger <aj at suse.de>
Date:   Thu Oct 9 12:22:36 2014 +0200

    Updated translations
    
    Commands run:-
    $ python setup.py extract_messages
    $ python setup.py update_catalog --no-fuzzy-matching \
      --ignore-obsolete=true
    $ source \
      ../openstack-infra/project-config/jenkins/scripts/common_translation_update.sh
    $ setup_loglevel_vars
    $ cleanup_po_file nova
    
    Change-Id: I64b2b468f7edd44dbb445b5b4e68b65c3fa53d9e

commit 3f9003270efd9ac036f3c229b36baa0bb05203bf
Author: Russell Bryant <rbryant at redhat.com>
Date:   Wed Oct 8 12:14:31 2014 +0000

    Fix broken cert revocation
    
    Cert revocation was broken by
    32b0adb591f80ad2c5c19519b4ffc2b55dbea672.  os.chdir() never returns
    anything, so this method would always raise an exception.  The proper
    way to handle an error from os.chdir() is to catch OSError.
    
    There were existing tests for this code, but they conveniently mocked
    os.chdir() to return values that are never actually returned.  The
    tests were fixed to match the real behavior.
    
    Change-Id: I7549bb60a7d43d53d6f81eecea31cbb9720cc8b6
    Closes-bug: #1376368
    (cherry picked from commit c8538208da00c3b0d0646629c9d668aa69944b85)

commit 6ed57972093835f449ad645b3783bbb8b3c4245e
Author: Russell Bryant <rbryant at redhat.com>
Date:   Fri Oct 3 16:41:03 2014 -0400

    Update rpc version aliases for juno
    
    Update all of the rpc client API classes to include a version alias
    for the latest version implemented in Juno.  This alias is needed when
    doing rolling upgrades from Juno to Kilo.  With this in place, you can
    ensure all services only send messages that both Juno and Kilo will
    understand.
    
    Closes-bug: #1378786
    Change-Id: Ia81538130bf8530b70b5f55c7a3d565903ff54b4
    (cherry picked from commit f98d725103c53e767a1cddb0b7e2c3822309db17)

commit ee3594072a7ef1c3f5661021fb31118069cbd646
Author: Tristan Cacqueray <tristan.cacqueray at enovance.com>
Date:   Fri Oct 3 19:53:42 2014 +0000

    Mask passwords in exceptions and error messages
    
    When a ProcessExecutionError is thrown by processutils.ssh_execute(),
    the exception may contain information such as password. Upstream
    applications that just log the message (as several appear to do)
    could inadvertently expose these passwords to a user with read access to
    the log files. It is therefore considered prudent to invoke
    strutils.mask_password() on the command, stdout and stderr in the
    exception. A test case has been added (to oslo-incubator) in order to
    ensure that all three are properly masked.
    
    An earlier commit (853d8f9897f8563851441108a9be26b10908c076) failed
    to address ssh_execute(). This change set addresses ssh_execute.
    
    OSSA is aware of this change request.
    
    Change-Id: Ie0caf32469126dd9feb44867adf27acb6e383958
    Closes-Bug: #1377981

commit f98c28228b6db5b0796e9669b6bd692b82bbfa6d
Author: liyingjun <liyingjun1988 at gmail.com>
Date:   Sat Sep 6 18:41:51 2014 +0800

    Fix KeyError for euca-describe-images
    
    EC2 describe images crashes on volume backed instance snapshot which has
    several volumes.
    
    Change-Id: Ibe278688b118db01c9c3ae1763954adf19c7ee0d
    Closes-bug: #1370265
    (cherry picked from commit 1dea1cd710d54d4a2a584590e4ccf59dd3a41faa)

commit 0aeffa12a62604ee3238323d969345e41937b642
Author: Vishvananda Ishaya <vishvananda at gmail.com>
Date:   Wed Oct 1 07:43:19 2014 -0700

    Fix the os_networks display to show cidr properly
    
    Converting network_get and network_get_all to use objects broke
    the display of the os_networks extension, because IPAddress
    fields in Network objects are dumped as lists by the jsonutils
    extension. We therefore must explicitly convert these object
    field values to string.
    
    The tests are updated to use objects so that we pick up bugs
    like this in the future. Incorrect assertEqual parameter order
    is fixed in the tests too since these are comparing dicts and
    it's not fun debugging a MismatchError when the reference/actual
    values are backwards.
    
    Change-Id: I0f05a9b4d7bbe5fe0a3b110c191455ca7edefcb5
    Closes-Bug: #1376945
    Co-authored-by: Matt Riedemann <mriedem at us.ibm.com>
    (cherry picked from commit da25467aafce9b62dd3fdff9d6cd84121fbee17e)

commit 0251b53966eaa9e724377a300ea247367fd778c7
Author: Matt Riedemann <mriedem at us.ibm.com>
Date:   Sun Oct 5 05:56:35 2014 -0700

    Disable libvirt NUMA topology support if libvirt < 1.0.4
    
    If you're not at a new enough version of libvirt, the compute service
    fails on startup because VirtNUMATopologyCellUsage is not fully
    populated.
    
    This add a min version check before trying to get host NUMA topology
    information.
    
    Closes-Bug: #1376307
    
    Change-Id: I00f6325cb554bc5e34d9f0fe651af39630f35b5d
    (cherry picked from commit 8ba0d9188d492028fcf4e65f908aa2d3db571952)

commit 5065aeca1b4acad513c07e3832ec0e12de2e6568
Author: Arnaud Legendre <arnaudleg at gmail.com>
Date:   Wed Oct 1 15:46:22 2014 -0700

    Destroy orig VM during resize if triggered by user
    
    Patch I7598afbf0dc3c527471af34224003d28e64daaff introduces a
    Minesweeper failure, due to the fact that it doesn't distinguish
    between destroy operation triggered by the user and by the revert
    resize.
    
    This patch fixes the issue by checking the task state. If the task
    state is revert_resize, the original VM doesn't get deleted.
    
    Closes-Bug: #1376492
    
    Change-Id: Idb9ac6c1ec5dcea52ce8e028f5cce08da1779321
    (cherry picked from commit e464bc518e8590d59c2741948466777982ca3319)

commit 7caf12e258f01bf0811302bbe0d47dd40b56e6f0
Author: Sean Dague <sean at dague.net>
Date:   Thu Sep 25 12:25:26 2014 -0400

    move integrated api client to requests library
    
    The integrated api client previously did the HTTPConnection /
    HTTPSConnection url parsing dance. In python 2.x HTTPSConnection
    doesn't care about SSL certs at all. While not actually an issue for
    these tests, it does mean we keep around an example in the code that
    uses HTTPSConnection, which will prevent us from creating a hacking
    rule to keep those out once the other 4 actual security issues with
    HTTPSConnection are removed.
    
    Change-Id: Idd7d5a055600dda663f9c56b39883510f8688b12
    Related-Bug: #1188189
    (cherry picked from commit 777a5870c9f29949e6af704bfa03c2e204065ab1)

commit cc88417637e4967860619e8d7e43f5d28957fcda
Author: Sylvain Bauza <sbauza at redhat.com>
Date:   Mon Sep 29 13:33:50 2014 +0200

    Fix unsafe SSL connection on TrustedFilter
    
    TrustedFilter was using httplib which doesn't check for CAs.
    Here the change is using Requests and verifies local CAs by default (or another
    one if provided)
    This effort is related to CVE 2013-2255.
    
    SecurityImpact
    
    Closes-Bug: #1373993
    
    Change-Id: I0b8e6319a4cc39876b1e396ef705f0fc5def1e44
    (cherry picked from commit 30871e8702737edbbfbcbbb5f21858873b37685c)




From gerrit2 at review.openstack.org  Thu Oct 16 13:20:49 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 16 Oct 2014 13:20:49 +0000
Subject: [Openstack-security] [openstack/horizon] SecurityImpact review
 request change I0127fe09d211cec231dab26d5987dafe720c91dd
Message-ID: <E1Xekz3-0004Qj-BF@review.openstack.org>


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

Log:
commit 3a64723917366eff4d8896b2b2d3d82fa462d25d
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Sun Aug 24 10:04:10 2014 -0500

    Document token hash algorithm option
    
    With https://review.openstack.org/#/c/116509/ ,
    django-openstack-auth will support a new option for the token hash
    algorithm. This adds the documentation to Horizon's local settings
    example file.
    
    This is for security hardening. The token hash algorithm defaults
    to MD5, which is considered too weak due to the potential for hash
    collisions. Some security standards require a SHA2 hash algorithm to
    be used.
    
    DocImpact
    SecurityImpact
    
    Change-Id: I6774b9b7215d191259586e4721e357487bb777cd
    Closes-Bug: #1174499
    (cherry picked from commit 372d033d89c0f5d305959a6ad5fd3e1159cc91ed)

commit f1a8abb9250f158ba1f04cf2055f717e78ef8184
Author: Akihiro Motoki <motoki at da.jp.nec.com>
Date:   Sun Oct 5 03:53:51 2014 +0900

    Warn OPENSTACK_QUANTUM_NETWORK setting as deprecated
    
    Change-Id: If2f762fe665b9a88153a77a658f52bcd56185c53
    Closes-Bug: #1377498
    (cherry picked from commit 530e5fee789ce5ed19d90a6b4901f01e8efde5ff)

commit 9b0ba951c07af13aa4c386b19876474b971e7946
Author: Akihiro Motoki <motoki at da.jp.nec.com>
Date:   Sun Oct 5 14:23:43 2014 +0900

    Import translations from Transifex for Juno
    
    * Import ~100% completed translations
      (translations available for 12 languages)
    * Update language list in openstack_dashboard settings.py
    * Update English POT files
    * Update Transifex resource name in .tx/config for Juno.
    * Remove compiled message catalogs (Related-Bug: #1196982)
    
    Closes-Bug: #1376542
    
    The instruction on how to compile message catalogs will be
    covered by https://review.openstack.org/#/c/126169/
    or the installation guide.
    
    Change-Id: Ib36562168009fa34b9818e99154df350678abd4b




From 1329214 at bugs.launchpad.net  Thu Oct 16 13:26:35 2014
From: 1329214 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 16 Oct 2014 13:26:35 -0000
Subject: [Openstack-security] [Bug 1329214] Fix proposed to cinder (master)
References: <20140612080140.21505.11780.malonedeb@gac.canonical.com>
Message-ID: <20141016132635.18348.8693.malone@chaenomeles.canonical.com>

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

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

Title:
  tgtadm iscsi chap does not work

Status in Cinder:
  Fix Released
Status in OpenStack Security Notes:
  New

Bug description:
  When using LVMISCSIDriver and iscsi_helper tgtadm, it should support chap unidirectional authentication because target configuration file and db.volume  has record chap user and chap passwd. 
  By testing, I found that tgtadm iscsi chap does not work.
  Is it a security bug for iscsi_helper tgtadm? 

  My detail test work is as follows.
  1. Test details as follows without modify the source code:
  1) Devstack all in one server A(10.250.10.190); another testing server B(10.250.10.191)
  2) create a vm  VM-A  and a cinder volume VOLUME-A, attach VOLUME-A to VM-A
  3) server B directly login the iscsi target that server-A export and get VOLUME-A sucessfully . 
      iscsiadm -m discovery -t sendtargets -p 10.250.10.190
      iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login

  2. Test details as follows with modify the source code:
  1) add creating user/passwd and binding user to tid code before leaving the function TgtAdm:create_iscsi_target. 
          type, name, passwd = chap_auth.split()
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'new',
                        '--user',
                        name,
                        '--password',
                        passwd)
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'bind',
                        '--tid',
                        tid,
                        '--user',
                        name
                        )

  2) try to login VOLUME-A as the steps in item 1, it reported an authorization error as follows.
  root at devaio1:/etc/iscsi#     iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login
  Logging in to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260] (multiple)
  iscsiadm: Could not login to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260].
  iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure)
  iscsiadm: Could not log into all portals

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



From 1343657 at bugs.launchpad.net  Thu Oct 16 15:46:59 2014
From: 1343657 at bugs.launchpad.net (Amrith)
Date: Thu, 16 Oct 2014 15:46:59 -0000
Subject: [Openstack-security] [Bug 1343657] Re: Shell Injection in backup
	strategies
References: <20140717230743.8188.12182.malonedeb@soybean.canonical.com>
Message-ID: <20141016154659.18315.63936.malone@chaenomeles.canonical.com>

I was intending to fix the bug in a manner similar to what Nathan
(nkinder) suggests in #15 above only that I'd rather take the guesswork
out of the client side (trove, for example) code and instead encapsulate
it into oslo.

To that end, I was thinking of extending execute() and providing
execute_extended() which would take a series of command lines and
construct the pipeline for you instead.

An important thing to bear in mind in this kind of pipelined execution
is that things get a tad bit hairy when people start doing redirection
in the command line (and there is pipelining). For example:

cmd1 2>&1 | cmd2

So, when you get something like this, subprocess.Popen() will puke on
the 2>&1 unless you use shell=true.

But, this is a reasonable limitation to help eliminate the necessity to
use shell=True

Note: I'm dubious about the use of the preexec_fn os.setsid that nkinder
recommends as that is process wide and not thread specific.

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

Title:
  Shell Injection in backup strategies

Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released
Status in Openstack Database (Trove):
  New

Bug description:
  Trove uses subprocess.Popen with shell=True in
  trove/trove/guestagent/strategies/backup/base.py line 61:

      def run(self):
          self.process = subprocess.Popen(self.command, shell=True,
                                          stdout=subprocess.PIPE,
                                          stderr=subprocess.PIPE,
                                          preexec_fn=os.setsid)
          self.pid = self.process.pid

  This could be used, maliciously or not, to inject arbitrary commands
  into a command line string. An example of this could be triggered is
  in trove/trove/guestagent/strategies/backup/mysql_imply.py line 37. It
  is creating a MySQL string with single quote. If the password, either
  maliciously or just happens to contain another single quote, it will
  escape from the command and arbitrary data will be executed instead.

  For more information on subprocess, shell=True and command injection
  see: https://docs.python.org/2/library/subprocess.html#frequently-
  used-arguments

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



From 1381405 at bugs.launchpad.net  Thu Oct 16 15:58:20 2014
From: 1381405 at bugs.launchpad.net (Dolph Mathews)
Date: Thu, 16 Oct 2014 15:58:20 -0000
Subject: [Openstack-security] [Bug 1381405] Re: user token is not checked
 for UUID type before sending request for token validation
References: <20141015084122.4736.33268.malonedeb@wampee.canonical.com>
Message-ID: <20141016155820.24721.52487.malone@soybean.canonical.com>

That's entirely by design. PKI tokens are a bit special in that they can
be validated on the remote service side (in keystone middleware), and
keystone itself supports pluggable token formats.

So if the extra entropy was desirable in my environment, I could issue
128 character base 62 tokens from keystone, and I'd expect keystone
middleware to call back to keystone to validate them.

** Changed in: keystonemiddleware
       Status: Incomplete => Invalid

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

Title:
  user token is not checked for UUID type before sending request for
  token validation

Status in OpenStack Identity  (Keystone) Middleware:
  Invalid

Bug description:
  user token is not checked for UUID type before sending token
  validation request.

  def _validate_token(self, token, env, retry=True):
                    ...
                  if cms.is_pkiz(token):
                      verified = self._verify_pkiz_token(token, token_ids)
                      data = jsonutils.loads(verified)
                      expires = _confirm_token_not_expired(data)
                  elif cms.is_asn1_token(token):
                      verified = self._verify_signed_token(token, token_ids)
                      data = jsonutils.loads(verified)
                      expires = _confirm_token_not_expired(data)
                  else:
                      data = self._identity_server.verify_token(token,
                                                                retry)

  The 'else' allows any value in token which is not in PKI format be sent to the Identity API for token
  validation.  A sanitation check here for UUID type can reduce the load for token validation 
  towards Identity API

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



From nkinder at redhat.com  Thu Oct 16 16:52:52 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Thu, 16 Oct 2014 16:52:52 -0000
Subject: [Openstack-security] [Bug 1343657] Re: Shell Injection in backup
	strategies
References: <20140717230743.8188.12182.malonedeb@soybean.canonical.com>
Message-ID: <20141016165253.4935.98013.malone@wampee.canonical.com>

@amrith
I simply copied the 'preexec_fn' from the initial code snippet in this bug showing how Trove uses Popen today.  I'm not recommending it's usage.

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

Title:
  Shell Injection in backup strategies

Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released
Status in Openstack Database (Trove):
  New

Bug description:
  Trove uses subprocess.Popen with shell=True in
  trove/trove/guestagent/strategies/backup/base.py line 61:

      def run(self):
          self.process = subprocess.Popen(self.command, shell=True,
                                          stdout=subprocess.PIPE,
                                          stderr=subprocess.PIPE,
                                          preexec_fn=os.setsid)
          self.pid = self.process.pid

  This could be used, maliciously or not, to inject arbitrary commands
  into a command line string. An example of this could be triggered is
  in trove/trove/guestagent/strategies/backup/mysql_imply.py line 37. It
  is creating a MySQL string with single quote. If the password, either
  maliciously or just happens to contain another single quote, it will
  escape from the command and arbitrary data will be executed instead.

  For more information on subprocess, shell=True and command injection
  see: https://docs.python.org/2/library/subprocess.html#frequently-
  used-arguments

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



From 1343657 at bugs.launchpad.net  Thu Oct 16 17:30:28 2014
From: 1343657 at bugs.launchpad.net (Amrith)
Date: Thu, 16 Oct 2014 17:30:28 -0000
Subject: [Openstack-security] [Bug 1343657] Re: Shell Injection in backup
	strategies
References: <20140717230743.8188.12182.malonedeb@soybean.canonical.com>
Message-ID: <20141016173028.17842.67854.malone@chaenomeles.canonical.com>

ouch, that's not good

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

Title:
  Shell Injection in backup strategies

Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released
Status in Openstack Database (Trove):
  New

Bug description:
  Trove uses subprocess.Popen with shell=True in
  trove/trove/guestagent/strategies/backup/base.py line 61:

      def run(self):
          self.process = subprocess.Popen(self.command, shell=True,
                                          stdout=subprocess.PIPE,
                                          stderr=subprocess.PIPE,
                                          preexec_fn=os.setsid)
          self.pid = self.process.pid

  This could be used, maliciously or not, to inject arbitrary commands
  into a command line string. An example of this could be triggered is
  in trove/trove/guestagent/strategies/backup/mysql_imply.py line 37. It
  is creating a MySQL string with single quote. If the password, either
  maliciously or just happens to contain another single quote, it will
  escape from the command and arbitrary data will be executed instead.

  For more information on subprocess, shell=True and command injection
  see: https://docs.python.org/2/library/subprocess.html#frequently-
  used-arguments

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



From anish2good at yahoo.co.in  Thu Oct 16 17:53:34 2014
From: anish2good at yahoo.co.in (Anish)
Date: Fri, 17 Oct 2014 01:53:34 +0800
Subject: [Openstack-security] "OSSG Lead Candidacy"
Message-ID: <1413482014.21775.YahooMailNeo@web193305.mail.sg3.yahoo.com>

Expertise in Kali Linux
	* Metasploit
	* Burp
	* DPI, Wireshark
	* MITM
	* SSL Sniff,SSL Split
	* Team Member
	* OWASP
	* XSS
--
Anish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141017/67d7ef60/attachment.html>

From matt at nycresistor.com  Thu Oct 16 18:01:21 2014
From: matt at nycresistor.com (matt)
Date: Thu, 16 Oct 2014 14:01:21 -0400
Subject: [Openstack-security] "OSSG Lead Candidacy"
In-Reply-To: <1413482014.21775.YahooMailNeo@web193305.mail.sg3.yahoo.com>
References: <1413482014.21775.YahooMailNeo@web193305.mail.sg3.yahoo.com>
Message-ID: <CAP_sDUEgca8v_PEjVUxick=nvMSuzptxaXw5g=wSANmorms6UQ@mail.gmail.com>

=D  kudos anish!

On Thu, Oct 16, 2014 at 1:53 PM, Anish <anish2good at yahoo.co.in> wrote:

> Expertise in Kali Linux
>
>    - Metasploit
>    - Burp
>    - DPI, Wireshark
>    - MITM
>    - SSL Sniff,SSL Split
>    - Team Member
>    - OWASP
>    - XSS
>
> --
> Anish
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141016/02887d3c/attachment.html>

From jsbryant at us.ibm.com  Thu Oct 16 23:18:14 2014
From: jsbryant at us.ibm.com (Jay Bryant)
Date: Thu, 16 Oct 2014 23:18:14 -0000
Subject: [Openstack-security] [Bug 1372643] Re: MITM vulnerability with XIV
	driver
References: <20140922204545.32411.9337.malonedeb@gac.canonical.com>
Message-ID: <20141016231814.5063.2015.malone@wampee.canonical.com>

Alon, any update on this?  Are you going to be able to fix this in the
XIV code so that we don't have to try and get anything into Cinder now
that Juno has released?

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

** Changed in: cinder
   Importance: Undecided => High

** Changed in: cinder
    Milestone: None => kilo-1

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

Title:
  MITM vulnerability with XIV driver

Status in Cinder:
  Triaged
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The XIV driver in Juno appears to blindly trust whatever certificate
  it gets back from the device without any validation. This would leave
  it open to a MITM attack.

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



From jsbryant at us.ibm.com  Thu Oct 16 23:23:49 2014
From: jsbryant at us.ibm.com (Jay Bryant)
Date: Thu, 16 Oct 2014 23:23:49 -0000
Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC
	VMAX driver
References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com>
Message-ID: <20141016232349.32745.10987.malone@gac.canonical.com>

Xing,

Any update on this?  It would be nice to get this fixed in master so we
can at least cherry-pick it back to icehouse and juno.  Let me know what
you think and if you have any better idea when you might have a fix.

Thanks!

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

** Changed in: cinder
   Importance: Undecided => High

** Changed in: cinder
    Milestone: next => kilo-1

** Tags added: drivers emc

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

Title:
  MITM vulnerability with EMC VMAX driver

Status in Cinder:
  Triaged
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The EMC VMAX driver in Juno appears to blindly trust whatever
  certificate it gets back from the device without any validation (it
  does not specify the ca_certs parameter, etc. on
  WBEMConnection.__init__). This would leave it open to a MITM attack.

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



From jsbryant at us.ibm.com  Thu Oct 16 23:26:16 2014
From: jsbryant at us.ibm.com (Jay Bryant)
Date: Thu, 16 Oct 2014 23:26:16 -0000
Subject: [Openstack-security] [Bug 1372643] Re: MITM vulnerability with XIV
	driver
References: <20140922204545.32411.9337.malonedeb@gac.canonical.com>
Message-ID: <20141016232617.32512.74243.launchpad@gac.canonical.com>

** Tags added: drivers xiv

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

Title:
  MITM vulnerability with XIV driver

Status in Cinder:
  Triaged
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The XIV driver in Juno appears to blindly trust whatever certificate
  it gets back from the device without any validation. This would leave
  it open to a MITM attack.

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



From 1372635 at bugs.launchpad.net  Fri Oct 17 03:27:19 2014
From: 1372635 at bugs.launchpad.net (Xing Yang)
Date: Fri, 17 Oct 2014 03:27:19 -0000
Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC
	VMAX driver
References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com>
Message-ID: <20141017032719.310.89909.malone@gac.canonical.com>

Jay,

The code changes required in the driver is minimum:

We just need to use the two new parameters "ca_cert" and "no_verification" in the new Connection API:
    conn = pywbem.WBEMConnection(url,
                                creds,
                                default_namespace=namespace,
                                x509=None,
                                verify_callback=None,
                                ca_certs=’/etc/cinder/ca_certs/dsib2202.lss.emc.com.crt’,
                                no_verification=False)

However, we encountered problems when testing this.  The pywbem library
packaged with Ubuntu 12.04 and 14.04 is 0.7.0, which was released in
12/12/2008.  It doesn't support "ca_certs" and "no_verification".
Version 0.8.0 is still  under development.

There are newer RPM packages that have these parameters and we tried to
convert the RPM package but couldn't get it to work on Ubuntu.  Until
Ubuntu has the newer version of the pywbem library, we can't make these
changes that don't work on Ubuntu.

Let me know if you have other suggestions.  Thanks.

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

Title:
  MITM vulnerability with EMC VMAX driver

Status in Cinder:
  Triaged
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The EMC VMAX driver in Juno appears to blindly trust whatever
  certificate it gets back from the device without any validation (it
  does not specify the ca_certs parameter, etc. on
  WBEMConnection.__init__). This would leave it open to a MITM attack.

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



From 1380642 at bugs.launchpad.net  Fri Oct 17 09:24:59 2014
From: 1380642 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 17 Oct 2014 09:24:59 -0000
Subject: [Openstack-security] [Bug 1380642] Re: Horizon should not log token
References: <20141013141256.17942.18062.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141017092459.479.51694.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/128859
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=47f1d49690fe3787a356175a069723f33ca12cfd
Submitter: Jenkins
Branch:    master

commit 47f1d49690fe3787a356175a069723f33ca12cfd
Author: Akihiro Motoki <motoki at da.jp.nec.com>
Date:   Thu Oct 16 04:34:30 2014 +0900

    Do not log keystone token
    
    Previously token values are logged as DEBUG level when a new client
    object is instantiated. In other project and clients, token values
    are now not logged and is output as *REDACTED* instead.
    In Horizon these log lines do not have much meaning and
    we can simply remove them.
    
    Change-Id: I67617ac6424907574d79ec2a57b513a548e220d2
    Closes-Bug: #1380642


** Changed in: horizon
       Status: In Progress => Fix Committed

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

Title:
  Horizon should not log token

Status in OpenStack Dashboard (Horizon):
  Fix Committed

Bug description:
  It is Horizon version of bug 1327019.
  Various modules in openstack_dashboard/api logs token.
  In other modules, token value is not logged now and is output as *REDACTED* or some similar string.
  In Horizon case, these log lines are simply removed to fix the issue as it seems this logging is unnecessary in most cases.

  I don't think this needs to be private based on the discussion in bug
  1327019.

    def novaclient(request):
      insecure = getattr(settings, 'OPENSTACK_SSL_NO_VERIFY', False)
      cacert = getattr(settings, 'OPENSTACK_SSL_CACERT', None)
      LOG.debug('novaclient connection created using token "%s" and url "%s"' %
                (request.user.token.id, base.url_for(request, 'compute')))
      c = nova_client.Client(request.user.username,
                             request.user.token.id,
                             project_id=request.user.tenant_id,
                             auth_url=base.url_for(request, 'compute'),
                             insecure=insecure,
                             cacert=cacert,
                             http_log_debug=settings.DEBUG)
      c.client.auth_token = request.user.token.id
      c.client.management_url = base.url_for(request, 'compute')
      return c

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



From jsbryant at us.ibm.com  Fri Oct 17 15:30:31 2014
From: jsbryant at us.ibm.com (Jay Bryant)
Date: Fri, 17 Oct 2014 15:30:31 -0000
Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC
	VMAX driver
References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com>
Message-ID: <20141017153032.17807.6914.malone@chaenomeles.canonical.com>

Thanks for the update Xing.

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

Title:
  MITM vulnerability with EMC VMAX driver

Status in Cinder:
  Triaged
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The EMC VMAX driver in Juno appears to blindly trust whatever
  certificate it gets back from the device without any validation (it
  does not specify the ca_certs parameter, etc. on
  WBEMConnection.__init__). This would leave it open to a MITM attack.

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



From anish2good at yahoo.co.in  Fri Oct 17 16:22:49 2014
From: anish2good at yahoo.co.in (ANish)
Date: Fri, 17 Oct 2014 16:22:49 -0000
Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC
	VMAX driver
References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com>
Message-ID: <20141017162249.442.74337.malone@gac.canonical.com>

should we proceed with the communication, if there is any verify error,
in this scenario

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

Title:
  MITM vulnerability with EMC VMAX driver

Status in Cinder:
  Triaged
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The EMC VMAX driver in Juno appears to blindly trust whatever
  certificate it gets back from the device without any validation (it
  does not specify the ca_certs parameter, etc. on
  WBEMConnection.__init__). This would leave it open to a MITM attack.

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



From 1372635 at bugs.launchpad.net  Fri Oct 17 16:42:28 2014
From: 1372635 at bugs.launchpad.net (Xing Yang)
Date: Fri, 17 Oct 2014 16:42:28 -0000
Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC
	VMAX driver
References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com>
Message-ID: <20141017164229.27950.35821.malone@wampee.canonical.com>

Sorry, but we can't provide a fix that doesn't work on Ubuntu.

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

Title:
  MITM vulnerability with EMC VMAX driver

Status in Cinder:
  Triaged
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The EMC VMAX driver in Juno appears to blindly trust whatever
  certificate it gets back from the device without any validation (it
  does not specify the ca_certs parameter, etc. on
  WBEMConnection.__init__). This would leave it open to a MITM attack.

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



From dmccowan at cisco.com  Fri Oct 17 18:44:44 2014
From: dmccowan at cisco.com (Dave McCowan)
Date: Fri, 17 Oct 2014 18:44:44 -0000
Subject: [Openstack-security] [Bug 1197459] Re: noVNC contains the session
 token in URL and insecurely sets the session cookie
References: <20130703161152.14968.85936.malonedeb@gac.canonical.com>
Message-ID: <20141017184446.32614.73485.launchpad@gac.canonical.com>

** Changed in: nova
     Assignee: Michael H Wilson (geekinutah) => Dave McCowan (dave-mccowan)

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

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

Status in OpenStack Compute (Nova):
  Opinion
Status in OpenStack Security Advisories:
  Won't Fix

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

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



From fungi at yuggoth.org  Fri Oct 17 22:46:07 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 17 Oct 2014 22:46:07 -0000
Subject: [Openstack-security] [Bug 1382562] Re: security groups remote_group
 fails with CIDR in address pairs
References: <20141017134212.4935.31773.malonedeb@wampee.canonical.com>
Message-ID: <20141017224607.5362.83163.malone@wampee.canonical.com>

Thanks Kevin. In that case I've tagged it as a security hardening
opportunity (removes a foot-cannon), and switched the advisory task to
won't-fix.

** Information type changed from Public Security to Public

** Changed in: ossa
       Status: Incomplete => Won't Fix

** Tags added: security

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

Title:
  security groups remote_group fails with CIDR in address pairs

Status in OpenStack Neutron (virtual network service):
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Add a CIDR to allowed address pairs of a host. RPC calls from the
  agents will run into this issue now when retrieving the security group
  members' IPs. I haven't confirmed because I came across this working
  on other code, but I think this may stop all members of the security
  groups referencing that group from getting their rules over the RPC
  channel.

  
    File "neutron/api/rpc/handlers/securitygroups_rpc.py", line 75, in security_group_info_for_devices
      return self.plugin.security_group_info_for_ports(context, ports)
    File "neutron/db/securitygroups_rpc_base.py", line 202, in security_group_info_for_ports
      return self._get_security_group_member_ips(context, sg_info)
    File "neutron/db/securitygroups_rpc_base.py", line 209, in _get_security_group_member_ips
      ethertype = 'IPv%d' % netaddr.IPAddress(ip).version
    File "/home/administrator/code/neutron/.tox/py27/local/lib/python2.7/site-packages/netaddr/ip/__init__.py", line 281, in __init__
      % self.__class__.__name__)
  ValueError: IPAddress() does not support netmasks or subnet prefixes! See documentation for details.

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



From gerrit2 at review.openstack.org  Sat Oct 18 00:16:12 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Sat, 18 Oct 2014 00:16:12 +0000
Subject: [Openstack-security] [openstack/swift-specs] SecurityImpact review
 request change I9adcd8979af8f1d0ebd912c503ae36a8041ed32d
Message-ID: <E1XfHgq-0000sP-T7@review.openstack.org>


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

Log:
commit a40a417375db6c127ab7ba87c97abe93ffb0c479
Author: Samuel Merritt <sam at swiftstack.com>
Date:   Mon Sep 22 11:57:55 2014 -0700

    First draft of spec for at-rest encryption.
    
    SecurityImpact
    
    Change-Id: I9adcd8979af8f1d0ebd912c503ae36a8041ed32d




From gerrit2 at review.openstack.org  Sat Oct 18 16:52:56 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Sat, 18 Oct 2014 16:52:56 +0000
Subject: [Openstack-security] [openstack/swift-specs] SecurityImpact review
 request change I9adcd8979af8f1d0ebd912c503ae36a8041ed32d
Message-ID: <E1XfXFQ-0000Vu-Ox@review.openstack.org>


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

Log:
commit 052b591d53953600d40c5d9fd4e93dc2b0ab6b71
Author: Samuel Merritt <sam at swiftstack.com>
Date:   Mon Sep 22 11:57:55 2014 -0700

    First draft of spec for at-rest encryption.
    
    SecurityImpact
    
    Change-Id: I9adcd8979af8f1d0ebd912c503ae36a8041ed32d




From bdpayne at acm.org  Sun Oct 19 23:03:37 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Sun, 19 Oct 2014 16:03:37 -0700
Subject: [Openstack-security] "OSSG Lead Candidacy"
In-Reply-To: <1413482014.21775.YahooMailNeo@web193305.mail.sg3.yahoo.com>
References: <1413482014.21775.YahooMailNeo@web193305.mail.sg3.yahoo.com>
Message-ID: <CAFpPvXDmyZ4FgkfMUUTx+tzb5LsKObiJ6fawQk3UxBcA4a423w@mail.gmail.com>

Per the OSSG election rules, all candidates must be members of the
electorate.  I do not believe that Anish qualifies as a member of the
electorate, so I cannot confirm Anish's candidacy.  If you believe that
this is an error, please contact me as soon as possible.  Elections will be
starting tomorrow.

See the page below for details:
https://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Fall_2014

Thanks,
-bryan (OSSG Election Chair)


On Thu, Oct 16, 2014 at 10:53 AM, Anish <anish2good at yahoo.co.in> wrote:

> Expertise in Kali Linux
>
>    - Metasploit
>    - Burp
>    - DPI, Wireshark
>    - MITM
>    - SSL Sniff,SSL Split
>    - Team Member
>    - OWASP
>    - XSS
>
> --
> Anish
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141019/3929c75a/attachment.html>

From bdpayne at acm.org  Sun Oct 19 23:10:42 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Sun, 19 Oct 2014 16:10:42 -0700
Subject: [Openstack-security] OSSG Elections Reminder
Message-ID: <CAFpPvXBWQ-xZDrd4SwPzJdZK0-rbij6shR-8A2AZF7uZ_RZ+rA@mail.gmail.com>

I just wanted to remind everyone that the OSSG lead elections will begin
tomorrow.  I have put together a list of the electorate.  Everyone on this
list will be receiving an email with voting instructions around mid-day
tomorrow (pacific time).

You are welcome to review the electorate list by following the link below.
If you believe that you have been omitted in error, please contact me
immediately.

https://docs.google.com/spreadsheet/ccc?key=0AqnzHH5YYzZvdC1QNHMxcVljdnQ3V0dtRWdjWE1kV1E&usp=sharing

As a reminder, the rules for who can vote are listed on the election wiki
page:
https://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Fall_2014

Thanks to everyone for helping to support this process and making OSSG a
strong, community-driven organization.  Please be watching for your voting
instructions tomorrow.

Cheers,
bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141019/9d11e8e9/attachment.html>

From 1260679 at bugs.launchpad.net  Mon Oct 20 17:25:32 2014
From: 1260679 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 20 Oct 2014 17:25:32 -0000
Subject: [Openstack-security] [Bug 1260679] Re: Multiple drivers set
	insecure file permissions
References: <20131213105542.17101.92136.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141020172534.25348.71730.launchpad@soybean.canonical.com>

** Changed in: cinder
     Assignee: Glenn M. Gobeli (glenng) => Ben Swartzlander (bswartz)

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

Title:
  Multiple drivers set insecure file permissions

Status in Cinder:
  In Progress
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  GPFS from various places calls "chmod 666" as root:

  ./cinder/volume/drivers/gpfs.py:        self._execute('chmod', '666', path, run_as_root=True)
  ./cinder/volume/drivers/gpfs.py:            self._execute('chmod', '666', vol_path, run_as_root=True)

  the Huawei driver sets 777 permissions as root on some files:

  ./cinder/volume/drivers/huawei/ssh_common.py: utils.execute('chmod', '777', filepath, run_as_root=True)
  ./cinder/volume/drivers/huawei/rest_common.py: utils.execute('chmod', '777', filepath, run_as_root=True)

  the Scality driver sets 666 permissions on all volumes:

  cinder/volume/drivers/scality.py:

      def _create_file(self, path, size):
          with open(path, "ab") as f:
              f.truncate(size)
          os.chmod(path, 0o666)

  Similarly, the NFS and NEXENTA driver have an implementation of

  def _set_rw_permissions_for_all()

  that is being called on all newly created volumes.

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



From marton.kiss at gmail.com  Mon Oct 20 18:14:38 2014
From: marton.kiss at gmail.com (Marton Kiss)
Date: Mon, 20 Oct 2014 20:14:38 +0200
Subject: [Openstack-security] Openstackid sec question
Message-ID: <CAMwrYFEA1gx8wzJzYYOnX7cVftBgnewy2MqHA=eJtdRNXC0aPw@mail.gmail.com>

Dear all,

The short story that we want to move from login.launchpad.net to an infra
hosted solution at openstackid.org, so the plan is that infra team will
operate the service in the future. The advantage of this service over the
existing one, that it is directly connected with openstack.org profile
database, so this can be the basic source of profile and auth data for all
OpenStack services.

The service behind openstackid.org had been written by a third party, and
it is based on a PHP/Laravel framework. The source code is accessible at
https://github.com/openstack-infra/openstackid, and all of the deployment
scripts available at openstack-infra/system-config repo.

As this service will handle authentication and membership data, I want to
ask whether any of you as the member of openstack security team would like
to suggest some extra hardening or security related advice to lower the
possibly security risks of operating such a service.

We have several options in our mind:
a, put a simple cloudflare service in front of openstackid.org to filter
out well-known patterns as a hosted solution
b, put a mod_security hosted by Us and in front of openstackid.org
c, do a code-audit on the openstackid source code
d, trust-in the code and open up the service without any other security
consideration

I appreciate all your feedbacks in this topic.

Brgds,
  Marton Kiss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141020/b6a0d476/attachment.html>

From fungi at yuggoth.org  Mon Oct 20 18:30:55 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 20 Oct 2014 18:30:55 +0000
Subject: [Openstack-security] Openstackid sec question
In-Reply-To: <CAMwrYFEA1gx8wzJzYYOnX7cVftBgnewy2MqHA=eJtdRNXC0aPw@mail.gmail.com>
References: <CAMwrYFEA1gx8wzJzYYOnX7cVftBgnewy2MqHA=eJtdRNXC0aPw@mail.gmail.com>
Message-ID: <20141020183055.GQ9816@yuggoth.org>

On 2014-10-20 20:14:38 +0200 (+0200), Marton Kiss wrote:
[...]
> c, do a code-audit on the openstackid source code
[...]

The question I was interested in seeing asked was more about this
item in particular (and less around how the Project Infrastructure
team should go about doing its work to manage systems).

As I gather there are members of the OpenStack community who may
have some interest in performing security audits of source code, I
thought the openstack-security mailing list might be a great first
place to ask for possible volunteers.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141020/b3dfa932/attachment.sig>

From 1260679 at bugs.launchpad.net  Mon Oct 20 21:12:11 2014
From: 1260679 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 20 Oct 2014 21:12:11 -0000
Subject: [Openstack-security] [Bug 1260679] Re: Multiple drivers set
	insecure file permissions
References: <20131213105542.17101.92136.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141020211213.2046.59214.launchpad@gac.canonical.com>

** Changed in: cinder
     Assignee: Ben Swartzlander (bswartz) => Eric Harney (eharney)

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

Title:
  Multiple drivers set insecure file permissions

Status in Cinder:
  In Progress
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  GPFS from various places calls "chmod 666" as root:

  ./cinder/volume/drivers/gpfs.py:        self._execute('chmod', '666', path, run_as_root=True)
  ./cinder/volume/drivers/gpfs.py:            self._execute('chmod', '666', vol_path, run_as_root=True)

  the Huawei driver sets 777 permissions as root on some files:

  ./cinder/volume/drivers/huawei/ssh_common.py: utils.execute('chmod', '777', filepath, run_as_root=True)
  ./cinder/volume/drivers/huawei/rest_common.py: utils.execute('chmod', '777', filepath, run_as_root=True)

  the Scality driver sets 666 permissions on all volumes:

  cinder/volume/drivers/scality.py:

      def _create_file(self, path, size):
          with open(path, "ab") as f:
              f.truncate(size)
          os.chmod(path, 0o666)

  Similarly, the NFS and NEXENTA driver have an implementation of

  def _set_rw_permissions_for_all()

  that is being called on all newly created volumes.

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



From 1260679 at bugs.launchpad.net  Mon Oct 20 21:12:30 2014
From: 1260679 at bugs.launchpad.net (Eric Harney)
Date: Mon, 20 Oct 2014 21:12:30 -0000
Subject: [Openstack-security] [Bug 1260679] Re: Multiple drivers set
	insecure file permissions
References: <20131213105542.17101.92136.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141020211233.3654.24463.launchpad@wampee.canonical.com>

** Changed in: cinder
     Assignee: Eric Harney (eharney) => Ben Swartzlander (bswartz)

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

Title:
  Multiple drivers set insecure file permissions

Status in Cinder:
  In Progress
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  GPFS from various places calls "chmod 666" as root:

  ./cinder/volume/drivers/gpfs.py:        self._execute('chmod', '666', path, run_as_root=True)
  ./cinder/volume/drivers/gpfs.py:            self._execute('chmod', '666', vol_path, run_as_root=True)

  the Huawei driver sets 777 permissions as root on some files:

  ./cinder/volume/drivers/huawei/ssh_common.py: utils.execute('chmod', '777', filepath, run_as_root=True)
  ./cinder/volume/drivers/huawei/rest_common.py: utils.execute('chmod', '777', filepath, run_as_root=True)

  the Scality driver sets 666 permissions on all volumes:

  cinder/volume/drivers/scality.py:

      def _create_file(self, path, size):
          with open(path, "ab") as f:
              f.truncate(size)
          os.chmod(path, 0o666)

  Similarly, the NFS and NEXENTA driver have an implementation of

  def _set_rw_permissions_for_all()

  that is being called on all newly created volumes.

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



From alonma at il.ibm.com  Tue Oct 21 19:15:15 2014
From: alonma at il.ibm.com (Alon Marx)
Date: Tue, 21 Oct 2014 19:15:15 -0000
Subject: [Openstack-security] [Bug 1372643] Re: MITM vulnerability with XIV
	driver
References: <20140922204545.32411.9337.malonedeb@gac.canonical.com>
Message-ID: <20141021191515.2081.94783.malone@gac.canonical.com>

Hi Jay,
Yes, we have this fixed. The fix is available in our Juno driver. 
The fix requires a certificate file to be put in the file system in well known directories (e.g. /etc/ssl/certs). This means that the user can also set his own certificates if he so wishes (one can set his own certification on the XIV storage).
We still have some work on packaging and documentation ahead of us.
Alon

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

Title:
  MITM vulnerability with XIV driver

Status in Cinder:
  Triaged
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The XIV driver in Juno appears to blindly trust whatever certificate
  it gets back from the device without any validation. This would leave
  it open to a MITM attack.

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



From jsbryant at us.ibm.com  Tue Oct 21 19:17:21 2014
From: jsbryant at us.ibm.com (Jay Bryant)
Date: Tue, 21 Oct 2014 19:17:21 -0000
Subject: [Openstack-security] [Bug 1372643] Re: MITM vulnerability with XIV
	driver
References: <20140922204545.32411.9337.malonedeb@gac.canonical.com>
Message-ID: <20141021191721.3659.91641.malone@soybean.canonical.com>

Excellent news.  Thanks Alon!

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

Title:
  MITM vulnerability with XIV driver

Status in Cinder:
  Triaged
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The XIV driver in Juno appears to blindly trust whatever certificate
  it gets back from the device without any validation. This would leave
  it open to a MITM attack.

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



From alonma at il.ibm.com  Wed Oct 22 13:37:59 2014
From: alonma at il.ibm.com (Alon Marx)
Date: Wed, 22 Oct 2014 13:37:59 -0000
Subject: [Openstack-security] [Bug 1372643] Re: MITM vulnerability with XIV
	driver
References: <20140922204545.32411.9337.malonedeb@gac.canonical.com>
Message-ID: <20141022133759.3592.98689.malone@soybean.canonical.com>

The fix is in the closed source driver, so there is no specific commit
in Juno code.

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

Title:
  MITM vulnerability with XIV driver

Status in Cinder:
  Triaged
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The XIV driver in Juno appears to blindly trust whatever certificate
  it gets back from the device without any validation. This would leave
  it open to a MITM attack.

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



From robert.clark at hp.com  Wed Oct 22 15:34:09 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Wed, 22 Oct 2014 15:34:09 +0000
Subject: [Openstack-security] X.509 Keypairs as Nova Windows VM credentials
Message-ID: <A0C170085C37664D93EE1604364858A1124E94CF@G9W0763.americas.hpqcorp.net>

Interesting specification going through Nova at the moment https://review.openstack.org/#/c/105034/

 

In short, it provides a mechanism to authenticate with Windows compute instances that's similar in look and feel to the way we use
SSH keys for Linux instances.

 

Would be good to get some OSSG eyes on it, I'm not very familiar with this method of windows authentication but it looks smart.

 

-Rob

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141022/139382f9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6187 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141022/139382f9/attachment.bin>

From mriedem at us.ibm.com  Wed Oct 22 19:53:21 2014
From: mriedem at us.ibm.com (Matt Riedemann)
Date: Wed, 22 Oct 2014 19:53:21 -0000
Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC
	VMAX driver
References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com>
Message-ID: <20141022195322.3549.62227.malone@wampee.canonical.com>

Per comment 25, has anyone reported a bug against Ubuntu for packaging
of pywbem?

Otherwise, we could put some conditional logic in the code that checks
the signature of the pywbem library and if the args are available use
them, if not don't - or try to use them and catch an exception and
handle it gracefully with a note about why we have to do the conditional
checks.

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

Title:
  MITM vulnerability with EMC VMAX driver

Status in Cinder:
  Triaged
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The EMC VMAX driver in Juno appears to blindly trust whatever
  certificate it gets back from the device without any validation (it
  does not specify the ca_certs parameter, etc. on
  WBEMConnection.__init__). This would leave it open to a MITM attack.

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



From 1382562 at bugs.launchpad.net  Sat Oct 18 09:32:31 2014
From: 1382562 at bugs.launchpad.net (Kevin Benton)
Date: Sat, 18 Oct 2014 09:32:31 -0000
Subject: [Openstack-security] [Bug 1382562] Re: security groups remote_group
 fails with CIDR in address pairs
References: <20141017134212.4935.31773.malonedeb@wampee.canonical.com>
Message-ID: <20141018093231.17589.86911.malone@chaenomeles.canonical.com>

Is that the right classification? It sounds like that is reserved for a
case where users are using something wrong.  This is a bug in neutron
and not a mistake on the user's part.

In this case the user is using address pairs in a completely legitimate
way by specifying a CIDR. The neutron function that checks the address
pairs when calculating members of security groups just breaks if it's a
CIDR.

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

Title:
  security groups remote_group fails with CIDR in address pairs

Status in OpenStack Neutron (virtual network service):
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Add a CIDR to allowed address pairs of a host. RPC calls from the
  agents will run into this issue now when retrieving the security group
  members' IPs. I haven't confirmed because I came across this working
  on other code, but I think this may stop all members of the security
  groups referencing that group from getting their rules over the RPC
  channel.

  
    File "neutron/api/rpc/handlers/securitygroups_rpc.py", line 75, in security_group_info_for_devices
      return self.plugin.security_group_info_for_ports(context, ports)
    File "neutron/db/securitygroups_rpc_base.py", line 202, in security_group_info_for_ports
      return self._get_security_group_member_ips(context, sg_info)
    File "neutron/db/securitygroups_rpc_base.py", line 209, in _get_security_group_member_ips
      ethertype = 'IPv%d' % netaddr.IPAddress(ip).version
    File "/home/administrator/code/neutron/.tox/py27/local/lib/python2.7/site-packages/netaddr/ip/__init__.py", line 281, in __init__
      % self.__class__.__name__)
  ValueError: IPAddress() does not support netmasks or subnet prefixes! See documentation for details.

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



From thingee at gmail.com  Wed Oct 22 12:45:18 2014
From: thingee at gmail.com (Mike Perez)
Date: Wed, 22 Oct 2014 12:45:18 -0000
Subject: [Openstack-security] [Bug 1372643] Re: MITM vulnerability with XIV
	driver
References: <20140922204545.32411.9337.malonedeb@gac.canonical.com>
Message-ID: <20141022124519.3726.65310.malone@soybean.canonical.com>

Alon, which commit in particular makes this available in Juno?

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

Title:
  MITM vulnerability with XIV driver

Status in Cinder:
  Triaged
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The XIV driver in Juno appears to blindly trust whatever certificate
  it gets back from the device without any validation. This would leave
  it open to a MITM attack.

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



From zhuzhubj at cn.ibm.com  Thu Oct 23 09:07:11 2014
From: zhuzhubj at cn.ibm.com (zhu zhu)
Date: Thu, 23 Oct 2014 09:07:11 -0000
Subject: [Openstack-security] [Bug 1384626] [NEW] SSL certification
 verification failed when Heat calls Glanceclient using insecure=False
References: <20141023090711.3131.60470.malonedeb@wampee.canonical.com>
Message-ID: <20141023090711.3131.60470.malonedeb@wampee.canonical.com>

Public bug reported:

Glance server is configured Https.

Configured Heat with heat.conf 
[clients_glance]
ca_file=<ca file path>
insecure=<false>

When trying to create stack, heat will raise exception during heat to load image data.
[Errno 1] _ssl.c:492: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

The root cause is that: ca_file as below is a wrong argument to
initialize the glance client,  it should be cacert which is supported
arguments by glanceclient.

class GlanceClientPlugin(client_plugin.ClientPlugin):

    exceptions_module = exc

    def _create(self):

        con = self.context
        endpoint_type = self._get_client_option('glance', 'endpoint_type')
        endpoint = self.url_for(service_type='image',
                                endpoint_type=endpoint_type)
        args = {
            'auth_url': con.auth_url,
            'service_type': 'image',
            'project_id': con.tenant,
            'token': self.auth_token,
            'endpoint_type': endpoint_type,
            'ca_file': self._get_client_option('glance', 'ca_file'),
            'cert_file': self._get_client_option('glance', 'cert_file'),
            'key_file': self._get_client_option('glance', 'key_file'),
            'insecure': self._get_client_option('glance', 'insecure')

** Affects: heat
     Importance: Undecided
         Status: New


** Tags: security

** Tags added: security

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

Title:
  SSL certification verification failed when Heat calls Glanceclient
  using insecure=False

Status in Orchestration API (Heat):
  New

Bug description:
  Glance server is configured Https.

  Configured Heat with heat.conf 
  [clients_glance]
  ca_file=<ca file path>
  insecure=<false>

  When trying to create stack, heat will raise exception during heat to load image data.
  [Errno 1] _ssl.c:492: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

  The root cause is that: ca_file as below is a wrong argument to
  initialize the glance client,  it should be cacert which is supported
  arguments by glanceclient.

  class GlanceClientPlugin(client_plugin.ClientPlugin):

      exceptions_module = exc

      def _create(self):

          con = self.context
          endpoint_type = self._get_client_option('glance', 'endpoint_type')
          endpoint = self.url_for(service_type='image',
                                  endpoint_type=endpoint_type)
          args = {
              'auth_url': con.auth_url,
              'service_type': 'image',
              'project_id': con.tenant,
              'token': self.auth_token,
              'endpoint_type': endpoint_type,
              'ca_file': self._get_client_option('glance', 'ca_file'),
              'cert_file': self._get_client_option('glance', 'cert_file'),
              'key_file': self._get_client_option('glance', 'key_file'),
              'insecure': self._get_client_option('glance', 'insecure')

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



From zhuzhubj at cn.ibm.com  Thu Oct 23 11:40:53 2014
From: zhuzhubj at cn.ibm.com (zhu zhu)
Date: Thu, 23 Oct 2014 11:40:53 -0000
Subject: [Openstack-security] [Bug 1384626] Re: SSL certification
 verification failed when Heat calls Glanceclient with ca cert
References: <20141023090711.3131.60470.malonedeb@wampee.canonical.com>
Message-ID: <20141023114053.3257.85186.launchpad@wampee.canonical.com>

** Summary changed:

- SSL certification verification failed when Heat calls Glanceclient using insecure=False
+ SSL certification verification failed when Heat calls Glanceclient with ca cert

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

Title:
  SSL certification verification failed when Heat calls Glanceclient
  with ca cert

Status in Orchestration API (Heat):
  New

Bug description:
  Glance server is configured Https.

  Configured Heat with heat.conf 
  [clients_glance]
  ca_file=<ca file path>
  insecure=<false>

  When trying to create stack, heat will raise exception during heat to load image data.
  [Errno 1] _ssl.c:492: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

  The root cause is that: ca_file as below is a wrong argument to
  initialize the glance client,  it should be cacert which is supported
  arguments by glanceclient.

  class GlanceClientPlugin(client_plugin.ClientPlugin):

      exceptions_module = exc

      def _create(self):

          con = self.context
          endpoint_type = self._get_client_option('glance', 'endpoint_type')
          endpoint = self.url_for(service_type='image',
                                  endpoint_type=endpoint_type)
          args = {
              'auth_url': con.auth_url,
              'service_type': 'image',
              'project_id': con.tenant,
              'token': self.auth_token,
              'endpoint_type': endpoint_type,
              'ca_file': self._get_client_option('glance', 'ca_file'),
              'cert_file': self._get_client_option('glance', 'cert_file'),
              'key_file': self._get_client_option('glance', 'key_file'),
              'insecure': self._get_client_option('glance', 'insecure')

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



From mriedem at us.ibm.com  Thu Oct 23 14:12:43 2014
From: mriedem at us.ibm.com (Matt Riedemann)
Date: Thu, 23 Oct 2014 14:12:43 -0000
Subject: [Openstack-security] [Bug 1376915] Re: Ceilometer policy file
	settings ignored
References: <20141002203501.17647.70947.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141023141243.2019.16639.malone@gac.canonical.com>

So it sounds like the 'workaround' in this case is for the
deployer/application building on ceilometer to change role/project
definitions so non-admin users aren't in the same project as admin
users, and then they won't share access to the same data.

I don't see anyone working either of the blueprints:

https://blueprints.launchpad.net/ceilometer/+spec/advanced-policy-rule
https://blueprints.launchpad.net/ceilometer/+spec/admin-only-api-access

And those have been open for awhile.  If people want the design changed
to allow different configurations, the blueprints should be worked.

As Matthew pointed out in comment 12, blueprint changes wouldn't be
backport-able, so I'm wondering if there is a more tactical fix here
until the BPs could be implemented?

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

Title:
  Ceilometer policy file settings ignored

Status in OpenStack Telemetry (Ceilometer):
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Configuring the ceilometer policy.json file to restrict certain
  actions has no effect whatsoever. This allows all users access to
  sensitive information, such as audit data stored in the http.request
  meter.

  E.g. policy.json file:

  {
      "adm":  "role:admin",

      "default": "!",

      "meter:get_all": "rule:adm",
      "meters:get_all": "rule:adm"
  }

  With the above policy, tokens for users without the admin role are
  still able to access meters, and any token still works for alarms
  despite the default supposedly being to disallow for everyone.

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



From steve.weston at triniplex.com  Thu Oct 23 17:17:48 2014
From: steve.weston at triniplex.com (Steven Weston)
Date: Thu, 23 Oct 2014 17:17:48 -0000
Subject: [Openstack-security] [Bug 1329214] Re: tgtadm iscsi chap does not
	work
References: <20140612080140.21505.11780.malonedeb@gac.canonical.com>
Message-ID: <20141023171750.7783.27821.launchpad@chaenomeles.canonical.com>

** Changed in: ossn
     Assignee: (unassigned) => Steven Weston (steve.weston)

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

Title:
  tgtadm iscsi chap does not work

Status in Cinder:
  Fix Released
Status in OpenStack Security Notes:
  New

Bug description:
  When using LVMISCSIDriver and iscsi_helper tgtadm, it should support chap unidirectional authentication because target configuration file and db.volume  has record chap user and chap passwd. 
  By testing, I found that tgtadm iscsi chap does not work.
  Is it a security bug for iscsi_helper tgtadm? 

  My detail test work is as follows.
  1. Test details as follows without modify the source code:
  1) Devstack all in one server A(10.250.10.190); another testing server B(10.250.10.191)
  2) create a vm  VM-A  and a cinder volume VOLUME-A, attach VOLUME-A to VM-A
  3) server B directly login the iscsi target that server-A export and get VOLUME-A sucessfully . 
      iscsiadm -m discovery -t sendtargets -p 10.250.10.190
      iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login

  2. Test details as follows with modify the source code:
  1) add creating user/passwd and binding user to tid code before leaving the function TgtAdm:create_iscsi_target. 
          type, name, passwd = chap_auth.split()
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'new',
                        '--user',
                        name,
                        '--password',
                        passwd)
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'bind',
                        '--tid',
                        tid,
                        '--user',
                        name
                        )

  2) try to login VOLUME-A as the steps in item 1, it reported an authorization error as follows.
  root at devaio1:/etc/iscsi#     iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login
  Logging in to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260] (multiple)
  iscsiadm: Could not login to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260].
  iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure)
  iscsiadm: Could not log into all portals

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



From morgan.fainberg at gmail.com  Thu Oct 23 17:26:59 2014
From: morgan.fainberg at gmail.com (Morgan Fainberg)
Date: Thu, 23 Oct 2014 17:26:59 -0000
Subject: [Openstack-security] [Bug 1371355] Re: Keystone client logs
 x-subject-token at the debug log level
References: <20140919000453.18243.72646.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141023172701.3690.48035.launchpad@soybean.canonical.com>

** Changed in: python-keystoneclient
    Milestone: None => 0.11.2

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

Title:
  Keystone client logs x-subject-token at the debug log level

Status in OpenStack Security Advisories:
  Won't Fix
Status in Python client library for Keystone:
  Fix Committed

Bug description:
  When you invoke any OpenStack API of any of the OpenStack services
  listed below, then it logs readable x-subject-token as a debug log
  message in the respective log file.

  x-subject-token is introduced in v3, so only setups using v3 keystone
  apis are affected.

  
  All OpenStack services using keystone client for authentication and debug log level are affected
  Service affected are:
  glance
  neutron
  cinder
  heat
  ceilometer
  nova
  keystone
  neutron

  
  Example, I tried to list servers from nova using "nova list” command, then it records following log message in the nova-api.log

  nova-api.log
  {{{
  2014-09-18 15:48:14.491 20940 DEBUG keystoneclient.session [-] REQ: curl -i -X GET http://10.69.4.172:35357/v3/auth/tokens -H "X-Subject-Token: TOKEN_REDACTED" -H "User-Agent: python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: TOKEN_REDACTED" _http_log_request /opt/stack/python-keystoneclient/keystoneclient/session.py:153

  2014-09-18 15:48:14.533 20940 DEBUG keystoneclient.session [-] RESP: [200] CaseInsensitiveDict({'content-length': '7113', 'x-subject-token': '7574276dc55f45878f18e14396dcf7f5', 'vary': 'X-Auth-Token', 'server': 'Apache/2.4.7 (Ubuntu)', 'date': 'Thu, 18 Sep 2014 22:48:14 GMT', 'content-type': 'application/json’})
  }}}

  
  I can then simply use x-subject-token': ‘7574276dc55f45878f18e14396dcf7f5 as X-auth-token in the curl command and access tenant’s information.

  {{{
  openstack at ubuntu:~$ curl -i 'http://10.69.4.172:8774/v2/d8a8252b035b4c18bee9215292485f78/servers/detail' -X GET -H "Accept: application/json" -H "X-Auth-Project-Id: demo" -H "X-Auth-Token: 7574276dc55f45878f18e14396dcf7f5"

  HTTP/1.1 200 OK
  Content-Type: application/json
  Content-Length: 15
  X-Compute-Request-Id: req-20ad9134-0c61-46de-91a1-da89283a057d
  Date: Thu, 18 Sep 2014 22:58:56 GMT
  {"servers": []}

  }}}

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



From morgan.fainberg at gmail.com  Thu Oct 23 17:27:09 2014
From: morgan.fainberg at gmail.com (Morgan Fainberg)
Date: Thu, 23 Oct 2014 17:27:09 -0000
Subject: [Openstack-security] [Bug 1362343] Re: weak digest algorithm for PKI
References: <20140827212906.28020.52551.malonedeb@wampee.canonical.com>
Message-ID: <20141023172711.2307.57625.launchpad@gac.canonical.com>

** Changed in: python-keystoneclient
    Milestone: None => 0.11.2

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

Title:
  weak digest algorithm for PKI

Status in OpenStack Identity (Keystone):
  In Progress
Status in Python client library for Keystone:
  Fix Committed

Bug description:
  The digest algorithm for PKI tokens is the openssl default of sha1.
  This is a weak algorithm and some security standards require a
  stronger algorithm such as sha256. Keystone should make the token
  digest hash algorithm configurable so that deployments can use a
  stronger algorithm.

  Also, the default could be stronger.

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



From morgan.fainberg at gmail.com  Thu Oct 23 17:27:07 2014
From: morgan.fainberg at gmail.com (Morgan Fainberg)
Date: Thu, 23 Oct 2014 17:27:07 -0000
Subject: [Openstack-security] [Bug 1329301] Re: Update how tokens are
 redacted from plaintext exposure
References: <20140612121824.4650.65306.malonedeb@wampee.canonical.com>
Message-ID: <20141023172708.7654.83104.launchpad@chaenomeles.canonical.com>

** Changed in: python-keystoneclient
    Milestone: None => 0.11.2

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

Title:
  Update how tokens are redacted from plaintext exposure

Status in Python client library for Glance:
  Fix Released
Status in Python client library for Keystone:
  Fix Committed

Bug description:
  We should move from this approach:

  https://review.openstack.org/#/c/83350/

  to whatever cross-project approach is agreed upon:

  See this thread:

  http://lists.openstack.org/pipermail/openstack-
  dev/2014-June/037345.html

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



From morgan.fainberg at gmail.com  Thu Oct 23 17:47:03 2014
From: morgan.fainberg at gmail.com (Morgan Fainberg)
Date: Thu, 23 Oct 2014 17:47:03 -0000
Subject: [Openstack-security] [Bug 1371355] Re: Keystone client logs
 x-subject-token at the debug log level
References: <20140919000453.18243.72646.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141023174706.8096.10707.launchpad@chaenomeles.canonical.com>

** Changed in: python-keystoneclient
       Status: Fix Committed => Fix Released

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

Title:
  Keystone client logs x-subject-token at the debug log level

Status in OpenStack Security Advisories:
  Won't Fix
Status in Python client library for Keystone:
  Fix Released

Bug description:
  When you invoke any OpenStack API of any of the OpenStack services
  listed below, then it logs readable x-subject-token as a debug log
  message in the respective log file.

  x-subject-token is introduced in v3, so only setups using v3 keystone
  apis are affected.

  
  All OpenStack services using keystone client for authentication and debug log level are affected
  Service affected are:
  glance
  neutron
  cinder
  heat
  ceilometer
  nova
  keystone
  neutron

  
  Example, I tried to list servers from nova using "nova list” command, then it records following log message in the nova-api.log

  nova-api.log
  {{{
  2014-09-18 15:48:14.491 20940 DEBUG keystoneclient.session [-] REQ: curl -i -X GET http://10.69.4.172:35357/v3/auth/tokens -H "X-Subject-Token: TOKEN_REDACTED" -H "User-Agent: python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: TOKEN_REDACTED" _http_log_request /opt/stack/python-keystoneclient/keystoneclient/session.py:153

  2014-09-18 15:48:14.533 20940 DEBUG keystoneclient.session [-] RESP: [200] CaseInsensitiveDict({'content-length': '7113', 'x-subject-token': '7574276dc55f45878f18e14396dcf7f5', 'vary': 'X-Auth-Token', 'server': 'Apache/2.4.7 (Ubuntu)', 'date': 'Thu, 18 Sep 2014 22:48:14 GMT', 'content-type': 'application/json’})
  }}}

  
  I can then simply use x-subject-token': ‘7574276dc55f45878f18e14396dcf7f5 as X-auth-token in the curl command and access tenant’s information.

  {{{
  openstack at ubuntu:~$ curl -i 'http://10.69.4.172:8774/v2/d8a8252b035b4c18bee9215292485f78/servers/detail' -X GET -H "Accept: application/json" -H "X-Auth-Project-Id: demo" -H "X-Auth-Token: 7574276dc55f45878f18e14396dcf7f5"

  HTTP/1.1 200 OK
  Content-Type: application/json
  Content-Length: 15
  X-Compute-Request-Id: req-20ad9134-0c61-46de-91a1-da89283a057d
  Date: Thu, 18 Sep 2014 22:58:56 GMT
  {"servers": []}

  }}}

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



From morgan.fainberg at gmail.com  Thu Oct 23 17:47:17 2014
From: morgan.fainberg at gmail.com (Morgan Fainberg)
Date: Thu, 23 Oct 2014 17:47:17 -0000
Subject: [Openstack-security] [Bug 1362343] Re: weak digest algorithm for PKI
References: <20140827212906.28020.52551.malonedeb@wampee.canonical.com>
Message-ID: <20141023174720.3396.5589.launchpad@soybean.canonical.com>

** Changed in: python-keystoneclient
       Status: Fix Committed => Fix Released

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

Title:
  weak digest algorithm for PKI

Status in OpenStack Identity (Keystone):
  In Progress
Status in Python client library for Keystone:
  Fix Released

Bug description:
  The digest algorithm for PKI tokens is the openssl default of sha1.
  This is a weak algorithm and some security standards require a
  stronger algorithm such as sha256. Keystone should make the token
  digest hash algorithm configurable so that deployments can use a
  stronger algorithm.

  Also, the default could be stronger.

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



From morgan.fainberg at gmail.com  Thu Oct 23 17:47:14 2014
From: morgan.fainberg at gmail.com (Morgan Fainberg)
Date: Thu, 23 Oct 2014 17:47:14 -0000
Subject: [Openstack-security] [Bug 1329301] Re: Update how tokens are
 redacted from plaintext exposure
References: <20140612121824.4650.65306.malonedeb@wampee.canonical.com>
Message-ID: <20141023174716.3257.24240.launchpad@wampee.canonical.com>

** Changed in: python-keystoneclient
       Status: Fix Committed => Fix Released

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

Title:
  Update how tokens are redacted from plaintext exposure

Status in Python client library for Glance:
  Fix Released
Status in Python client library for Keystone:
  Fix Released

Bug description:
  We should move from this approach:

  https://review.openstack.org/#/c/83350/

  to whatever cross-project approach is agreed upon:

  See this thread:

  http://lists.openstack.org/pipermail/openstack-
  dev/2014-June/037345.html

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



From sbaker at redhat.com  Thu Oct 23 19:56:36 2014
From: sbaker at redhat.com (Steve Baker)
Date: Thu, 23 Oct 2014 19:56:36 -0000
Subject: [Openstack-security] [Bug 1384626] Re: SSL certification
 verification failed when Heat calls Glanceclient with ca cert
References: <20141023090711.3131.60470.malonedeb@wampee.canonical.com>
Message-ID: <20141023195637.2449.53756.launchpad@gac.canonical.com>

** Tags added: juno-backport-potential

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

Title:
  SSL certification verification failed when Heat calls Glanceclient
  with ca cert

Status in Orchestration API (Heat):
  In Progress

Bug description:
  Glance server is configured Https.

  Configured Heat with heat.conf 
  [clients_glance]
  ca_file=<ca file path>
  insecure=<false>

  When trying to create stack, heat will raise exception during heat to load image data.
  [Errno 1] _ssl.c:492: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

  The root cause is that: ca_file as below is a wrong argument to
  initialize the glance client,  it should be cacert which is supported
  arguments by glanceclient.

  class GlanceClientPlugin(client_plugin.ClientPlugin):

      exceptions_module = exc

      def _create(self):

          con = self.context
          endpoint_type = self._get_client_option('glance', 'endpoint_type')
          endpoint = self.url_for(service_type='image',
                                  endpoint_type=endpoint_type)
          args = {
              'auth_url': con.auth_url,
              'service_type': 'image',
              'project_id': con.tenant,
              'token': self.auth_token,
              'endpoint_type': endpoint_type,
              'ca_file': self._get_client_option('glance', 'ca_file'),
              'cert_file': self._get_client_option('glance', 'cert_file'),
              'key_file': self._get_client_option('glance', 'key_file'),
              'insecure': self._get_client_option('glance', 'insecure')

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



From sbaker at redhat.com  Thu Oct 23 20:12:44 2014
From: sbaker at redhat.com (Steve Baker)
Date: Thu, 23 Oct 2014 20:12:44 -0000
Subject: [Openstack-security] [Bug 1384626] Re: SSL certification
 verification failed when Heat calls Glanceclient with ca cert
References: <20141023090711.3131.60470.malonedeb@wampee.canonical.com>
Message-ID: <20141023201246.3549.54215.launchpad@wampee.canonical.com>

** Changed in: heat
   Importance: Undecided => High

** Changed in: heat
    Milestone: None => kilo-1

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

Title:
  SSL certification verification failed when Heat calls Glanceclient
  with ca cert

Status in Orchestration API (Heat):
  In Progress

Bug description:
  Glance server is configured Https.

  Configured Heat with heat.conf 
  [clients_glance]
  ca_file=<ca file path>
  insecure=<false>

  When trying to create stack, heat will raise exception during heat to load image data.
  [Errno 1] _ssl.c:492: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

  The root cause is that: ca_file as below is a wrong argument to
  initialize the glance client,  it should be cacert which is supported
  arguments by glanceclient.

  class GlanceClientPlugin(client_plugin.ClientPlugin):

      exceptions_module = exc

      def _create(self):

          con = self.context
          endpoint_type = self._get_client_option('glance', 'endpoint_type')
          endpoint = self.url_for(service_type='image',
                                  endpoint_type=endpoint_type)
          args = {
              'auth_url': con.auth_url,
              'service_type': 'image',
              'project_id': con.tenant,
              'token': self.auth_token,
              'endpoint_type': endpoint_type,
              'ca_file': self._get_client_option('glance', 'ca_file'),
              'cert_file': self._get_client_option('glance', 'cert_file'),
              'key_file': self._get_client_option('glance', 'key_file'),
              'insecure': self._get_client_option('glance', 'insecure')

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



From 1260679 at bugs.launchpad.net  Fri Oct 24 12:11:13 2014
From: 1260679 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 24 Oct 2014 12:11:13 -0000
Subject: [Openstack-security] [Bug 1260679] Fix merged to cinder (master)
References: <20131213105542.17101.92136.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141024121113.4150.61541.malone@soybean.canonical.com>

Reviewed:  https://review.openstack.org/107693
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=6879bd0720b2c4c5ef4d2f2c42fe0e4e436ba998
Submitter: Jenkins
Branch:    master

commit 6879bd0720b2c4c5ef4d2f2c42fe0e4e436ba998
Author: Glenn M. Gobeli <Glenn.Gobeli at netapp.com>
Date:   Thu Jun 12 09:31:25 2014 -0400

    NFS Security Enhancements: allows secure NFS environment setup
    
    This patch allows an OpenStack environment to run as a secure NAS
    environment from the client and server perspective, including having
    root squash enabled and not running file operations as the 'root'
    user. This also sets Cinder file permissions as 660: removing
    other/world file access.
    
    The "nas_secure_file_permissions" option controls the setting of file
    permissions when Cinder volumes are created. The option defaults to
    "auto" to gracefully handle upgrade scenarios. When set to "auto",
    a check is done during Cinder startup to determine if there are
    existing Cinder volumes: no volumes will set the option to 'true',
    and use secure file permissions. The detection of existing volumes will
    set the option to 'false', and use the current insecure method of
    handling file permissions.
    
    The "nas_secure_file_operations" option controls whether file
    operations are run as the 'root' user or the current OpenStack
    'process' user. The option defaults to "auto" to gracefully handle
    upgrade scenarios. When set to "auto", a check is done during Cinder
    startup to determine if there are existing Cinder volumes: no volumes
    will set the option to 'true', be secure and do NOT run as the 'root'
    user. The detection of existing volumes will set the option to 'false',
    and use the current method of running operations as the 'root' user.
    For new installations, a 'marker file' is written so that subsequent
    restarts of Cinder will know what the original determination had been.
    
    This patch enables this functionality only for the NFS driver.
    Other similar drivers can use this code to enable the same
    functionality with the same config options.
    
    DocImpact
    Change-Id: I3d25f593beab7f5462576b14ab62d13d8c53e7c6
    Implements: blueprint secure-nfs
    Partial-Bug: 1260679

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

Title:
  Multiple drivers set insecure file permissions

Status in Cinder:
  In Progress
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  GPFS from various places calls "chmod 666" as root:

  ./cinder/volume/drivers/gpfs.py:        self._execute('chmod', '666', path, run_as_root=True)
  ./cinder/volume/drivers/gpfs.py:            self._execute('chmod', '666', vol_path, run_as_root=True)

  the Huawei driver sets 777 permissions as root on some files:

  ./cinder/volume/drivers/huawei/ssh_common.py: utils.execute('chmod', '777', filepath, run_as_root=True)
  ./cinder/volume/drivers/huawei/rest_common.py: utils.execute('chmod', '777', filepath, run_as_root=True)

  the Scality driver sets 666 permissions on all volumes:

  cinder/volume/drivers/scality.py:

      def _create_file(self, path, size):
          with open(path, "ab") as f:
              f.truncate(size)
          os.chmod(path, 0o666)

  Similarly, the NFS and NEXENTA driver have an implementation of

  def _set_rw_permissions_for_all()

  that is being called on all newly created volumes.

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



From edmondsw at us.ibm.com  Fri Oct 24 13:44:58 2014
From: edmondsw at us.ibm.com (Matthew Edmonds)
Date: Fri, 24 Oct 2014 13:44:58 -0000
Subject: [Openstack-security] [Bug 1376915] Re: Ceilometer policy file
	settings ignored
References: <20141002203501.17647.70947.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141024134458.3131.1208.malone@wampee.canonical.com>

I don't see any way to workaround this security issue with role/project
definition restructuring... Unless you're suggesting we have a separate
project for each non-admin user (which is obviously unworkable), non-
admins in the same project would have access to each other's data. Non-
admin users must not be allowed access to anyone else's data.

I'm not familiar enough with the alarms and resources portions of the
ceilometer API to speak there, but when it comes to meters I think the
simplest option for a backportable solution would be to restrict meters
requests to admins until those blueprints can be implemented. Another
option would be allowing anyone to make the requests but filtering the
results that are returned such that non-admin users only get back data
for themselves.

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

Title:
  Ceilometer policy file settings ignored

Status in OpenStack Telemetry (Ceilometer):
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Configuring the ceilometer policy.json file to restrict certain
  actions has no effect whatsoever. This allows all users access to
  sensitive information, such as audit data stored in the http.request
  meter.

  E.g. policy.json file:

  {
      "adm":  "role:admin",

      "default": "!",

      "meter:get_all": "rule:adm",
      "meters:get_all": "rule:adm"
  }

  With the above policy, tokens for users without the admin role are
  still able to access meters, and any token still works for alarms
  despite the default supposedly being to disallow for everyone.

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



From fungi at yuggoth.org  Fri Oct 24 14:11:22 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 24 Oct 2014 14:11:22 -0000
Subject: [Openstack-security] [Bug 1381365] Re: SSL Version and cipher
	selection not possible
References: <20141015072233.17942.25827.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141024141124.7561.43975.launchpad@chaenomeles.canonical.com>

** Information type changed from Private Security to Public

** Tags added: security

** Changed in: ossa
       Status: Incomplete => Won't Fix

** CVE removed: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2014-3511

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

Title:
  SSL Version and cipher selection not possible

Status in Cinder:
  New
Status in OpenStack Image Registry and Delivery Service (Glance):
  New
Status in OpenStack Identity (Keystone):
  New
Status in OpenStack Compute (Nova):
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  We configure keystone to use SSL always. Due to the poodle issue, I was trying to configure keystone to disable SSLv3 completely. 
  http://googleonlinesecurity.blogspot.fi/2014/10/this-poodle-bites-exploiting-ssl-30.html
  https://www.openssl.org/~bodo/ssl-poodle.pdf

  It seems that keystone has no support for configring SSL versions, nor
  ciphers.

  If I'm not mistaken the relevant code is in the start function in
  common/environment/eventlet_server.py

  It calls 
  eventlet.wrap_ssl
  but with no SSL version nor cipher options. Since the interface is identical, I assume it uses ssl.wrap_socket. The default here seems to be  PROTOCOL_SSLv23 (SSL2 disabled), which would make this vulnerable to the poodle issue.

  SSL conifgs should probably be possible to be set in the config file
  (with sane defaults), so that current and newly detected weak ciphers
  can be disabled without code changes.

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



From fungi at yuggoth.org  Fri Oct 24 14:17:32 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 24 Oct 2014 14:17:32 -0000
Subject: [Openstack-security] [Bug 1379077] Re: Tenants can be created with
	invalid ids
References: <20141009004653.32578.45865.malonedeb@gac.canonical.com>
Message-ID: <20141024141733.2551.9291.launchpad@gac.canonical.com>

** Information type changed from Private Security to Public

** Tags added: security

** Changed in: ossa
       Status: Confirmed => Won't Fix

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

Title:
  Tenants can be created with invalid ids

Status in OpenStack Identity (Keystone):
  In Progress
Status in Keystone icehouse series:
  In Progress
Status in Keystone juno series:
  Confirmed
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  When creating a new tenant, there is an optional argument 'id' that
  may be passed:

  https://github.com/openstack/keystone/blob/9025b64a8f2bf5cf01a18453d6728e081bd2c3b9/keystone/assignment/controllers.py#L114

  If not passed, this just creates a uuid and proceeds.  If a value is
  passed, it will use that value.  So a user with priv's to create a
  tenant can pass something like "../../../../../" as the id.  If this
  is done, then the project can't be deleted without manually removing
  the value from the database. This can lead to a DoS that could fill
  the db and take down the cloud, in the worst of circumstances.

  I believe the proper fix here would be to just remove this feature
  altogether.  But this is because I'm not clear about why we would ever
  want to allow someone to set the id manually.  If there's a valid use
  case here, then we should at least do some input validation.

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



From fungi at yuggoth.org  Fri Oct 24 14:19:03 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 24 Oct 2014 14:19:03 -0000
Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not
 released back to the pool leading to choking of new requests
References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com>
Message-ID: <20141024141905.2244.2546.launchpad@gac.canonical.com>

** Information type changed from Private Security to Public

** Tags added: security

** Changed in: ossa
   Importance: High => Undecided

** Changed in: ossa
       Status: Confirmed => Won't Fix

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

Title:
  Eventlet green threads not released back to the pool leading to
  choking of new requests

Status in Cinder:
  In Progress
Status in Cinder icehouse series:
  New
Status in OpenStack Image Registry and Delivery Service (Glance):
  In Progress
Status in Glance icehouse series:
  New
Status in OpenStack Identity (Keystone):
  In Progress
Status in Keystone icehouse series:
  New
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in neutron icehouse series:
  New
Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Compute (nova) icehouse series:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Currently reproduced  on Juno milestone 2. but this issue should be
  reproducible in all releases since its inception.

  It is possible to choke OpenStack API controller services using
  wsgi+eventlet library by simply not closing the client socket
  connection. Whenever a request is received by any OpenStack API
  service for example nova api service, eventlet library creates a green
  thread from the pool and starts processing the request. Even after the
  response is sent to the caller, the green thread is not returned back
  to the pool until the client socket connection is closed. This way,
  any malicious user can send many API requests to the API controller
  node and determine the wsgi pool size configured for the given service
  and then send those many requests to the service and after receiving
  the response, wait there infinitely doing nothing leading to
  disrupting services for other tenants. Even when service providers
  have enabled rate limiting feature, it is possible to choke the API
  services with a group (many tenants) attack.

  Following program illustrates choking of nova-api services (but this
  problem is omnipresent in all other OpenStack API Services using
  wsgi+eventlet)

  Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py.
  After you run the below program, you should try to invoke API
  ============================================================================================
  import time
  import requests
  from multiprocessing import Process

  def request(number):
     #Port is important here
     path = 'http://127.0.0.1:8774/servers'
      try:
          response = requests.get(path)
          print "RESPONSE %s-%d" % (response.status_code, number)
          #during this sleep time, check if the client socket connection is released or not on the API controller node.
          time.sleep(1000)
          print “Thread %d complete" % number
      except requests.exceptions.RequestException as ex:
          print “Exception occurred %d-%s" % (number, str(ex))

  if __name__ == '__main__':
      processes = []
      for number in range(40):
          p = Process(target=request, args=(number,))
          p.start()
          processes.append(p)
      for p in processes:
          p.join()

  ================================================================================================

  Presently, the wsgi server allows persist connections if you configure keepalive to True which is default.
  In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server.

  Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter.
  For example.
  Keep-Alive: timeout=10, max=5

  Note: After we have disabled keepalive in all the OpenStack API
  service using wsgi library, then it might impact all existing
  applications built with the assumptions that OpenStack API services
  uses persistent connections. They might need to modify their
  applications if reconnection logic is not in place and also they might
  experience the performance has slowed down as it will need to
  reestablish the http connection for every request.

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



From gerrit2 at review.openstack.org  Fri Oct 24 15:17:52 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 24 Oct 2014 15:17:52 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change Ic57b2aceb136e8626388cfe4df72b2f47cb0661c
Message-ID: <E1Xhgci-0003Ck-TZ@review.openstack.org>


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

Log:
commit cd71414a1299ed875db019561b782982723ce668
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Tue Oct 21 02:31:15 2014 -0700

    Eventlet green threads not released back to pool
    
    Presently, the wsgi server allows persist connections hence even after
    the response is sent to the client, it doesn't close the client socket
    connection.
    Because of this problem, the green thread is not released back to the pool.
    
    In order to close the client socket connection explicitly after the
    response is sent and read successfully by the client, you simply have to
    set keepalive to False when you create a wsgi server.
    
    DocImpact:
    Added wsgi_keep_alive option (default=True).
    
    SecurityImpact
    
    Closes-Bug: #1361360
    Change-Id: Ic57b2aceb136e8626388cfe4df72b2f47cb0661c




From gerrit2 at review.openstack.org  Fri Oct 24 15:24:35 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 24 Oct 2014 15:24:35 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7
Message-ID: <E1XhgjD-0003hC-GI@review.openstack.org>


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

Log:
commit 8d8a1f47a3d9d68170dff9e75bce97ee49f528cb
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Tue Oct 21 04:10:57 2014 -0700

    Eventlet green threads not released back to pool
    
    Presently, the wsgi server allows persist connections hence even after
    the response is sent to the client, it doesn't close the client socket
    connection.
    Because of this problem, the green thread is not released back to the pool.
    
    In order to close the client socket connection explicitly after the
    response is sent and read successfully by the client, you simply have to
    set keepalive to False when you create a wsgi server.
    
    Add a parameter to take advantage of the new(ish) eventlet socket timeout
    behaviour. Allows closing idle client connections after a period of
    time, eg:
    
    $ time nc localhost 8776
    real    1m0.063s
    
    Setting 'client_socket_timeout = 0' means do not timeout.
    
    DocImpact:
    Added wsgi_keep_alive option (default=True).
    Added client_socket_timeout option (default=900).
    
    SecurityImpact
    
    Closes-Bug: #1361360
    Change-Id: I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7




From gerrit2 at review.openstack.org  Fri Oct 24 15:48:41 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 24 Oct 2014 15:48:41 +0000
Subject: [Openstack-security] [openstack/neutron] SecurityImpact review
 request change I3a361d6590d1800b85791f23ac1cdfd79815341b
Message-ID: <E1Xhh6X-0005bh-Bx@review.openstack.org>


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

Log:
commit 57d1a30f8ad07720848cd49324e242123a944686
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Tue Oct 21 04:15:15 2014 -0700

    Eventlet green threads not released back to pool
    
    Presently, the wsgi server allows persist connections hence even after
    the response is sent to the client, it doesn't close the client socket
    connection.
    Because of this problem, the green thread is not released back to the pool.
    
    In order to close the client socket connection explicitly after the
    response is sent and read successfully by the client, you simply have to
    set keepalive to False when you create a wsgi server.
    
    Add a parameter to take advantage of the new(ish) eventlet socket timeout
    behaviour. Allows closing idle client connections after a period of
    time, eg:
    
    $ time nc localhost 8776
    real    1m0.063s
    
    Setting 'client_socket_timeout = 0' means do not timeout.
    
    DocImpact:
    Added wsgi_keep_alive option (default=True).
    Added client_socket_timeout option (default=900).
    
    SecurityImpact
    
    Closes-Bug: #1361360
    Change-Id: I3a361d6590d1800b85791f23ac1cdfd79815341b




From gerrit2 at review.openstack.org  Fri Oct 24 15:59:23 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 24 Oct 2014 15:59:23 +0000
Subject: [Openstack-security] [openstack/glance] SecurityImpact review
 request change I93aaca24935a4f3096210233097dd6b8c5440176
Message-ID: <E1XhhGt-0006Tl-Vz@review.openstack.org>


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

Log:
commit b48d2bff84389fdd988807f5f1505dff94d300e4
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Tue Oct 21 04:39:59 2014 -0700

    Eventlet green threads not released back to pool
    
    Presently, the wsgi server allows persist connections hence even after
    the response is sent to the client, it doesn't close the client socket
    connection.
    Because of this problem, the green thread is not released back to the pool.
    
    In order to close the client socket connection explicitly after the
    response is sent and read successfully by the client, you simply have to
    set keepalive to False when you create a wsgi server.
    
    DocImpact:
    Added wsgi_keep_alive option (default=True).
    
    SecurityImpact
    
    Closes-Bug: #1361360
    Change-Id: I93aaca24935a4f3096210233097dd6b8c5440176




From gerrit2 at review.openstack.org  Fri Oct 24 16:18:39 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 24 Oct 2014 16:18:39 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I399b812f6d452226fd306c423de8dcea8520d2aa
Message-ID: <E1XhhZX-0008Da-P5@review.openstack.org>


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

Log:
commit 0dd4197277276cd2366374416a36101326a53893
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Tue Oct 21 01:37:42 2014 -0700

    Eventlet green threads not released back to pool
    
    Presently, the wsgi server allows persist connections hence even after
    the response is sent to the client, it doesn't close the client socket
    connection.
    Because of this problem, the green thread is not released back to the pool.
    
    In order to close the client socket connection explicitly after the
    response is sent and read successfully by the client, you simply have to
    set keepalive to False when you create a wsgi server.
    
    Add a parameter to take advantage of the new(ish) eventlet socket timeout
    behaviour. Allows closing idle client connections after a period of
    time, eg:
    
    $ time nc localhost 8776
    real    1m0.063s
    
    Setting 'client_socket_timeout = 0' means do not timeout.
    
    DocImpact:
    Added wsgi_keep_alive option (default=True).
    Added client_socket_timeout option (default=900).
    
    SecurityImpact
    
    Closes-Bug: #1361360
    Change-Id: I399b812f6d452226fd306c423de8dcea8520d2aa




From gerrit2 at review.openstack.org  Fri Oct 24 16:38:04 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 24 Oct 2014 16:38:04 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change Ic57b2aceb136e8626388cfe4df72b2f47cb0661c
Message-ID: <E1XhhsK-0001ck-FX@review.openstack.org>


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

Log:
commit 2f24cebaf05dfbc126aecf2c658274f580e8c1d1
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Tue Oct 21 02:31:15 2014 -0700

    Eventlet green threads not released back to pool
    
    Presently, the wsgi server allows persist connections hence even after
    the response is sent to the client, it doesn't close the client socket
    connection.
    Because of this problem, the green thread is not released back to the pool.
    
    In order to close the client socket connection explicitly after the
    response is sent and read successfully by the client, you simply have to
    set keepalive to False when you create a wsgi server.
    
    DocImpact:
    Added wsgi_keep_alive option (default=True).
    
    SecurityImpact
    
    Closes-Bug: #1361360
    Change-Id: Ic57b2aceb136e8626388cfe4df72b2f47cb0661c




From gerrit2 at review.openstack.org  Fri Oct 24 17:39:23 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 24 Oct 2014 17:39:23 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7
Message-ID: <E1Xhipf-0006Pm-P2@review.openstack.org>


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

Log:
commit 24d16026af6e4a9caaa3e852c009130d41dde94d
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Tue Oct 21 04:10:57 2014 -0700

    Eventlet green threads not released back to pool
    
    Presently, the wsgi server allows persist connections hence even after
    the response is sent to the client, it doesn't close the client socket
    connection.
    Because of this problem, the green thread is not released back to the pool.
    
    In order to close the client socket connection explicitly after the
    response is sent and read successfully by the client, you simply have to
    set keepalive to False when you create a wsgi server.
    
    Add a parameter to take advantage of the new(ish) eventlet socket timeout
    behaviour. Allows closing idle client connections after a period of
    time, eg:
    
    $ time nc localhost 8776
    real    1m0.063s
    
    Setting 'client_socket_timeout = 0' means do not timeout.
    
    DocImpact:
    Added wsgi_keep_alive option (default=True).
    Added client_socket_timeout option (default=900).
    
    SecurityImpact
    
    Closes-Bug: #1361360
    Change-Id: I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7




From 1334926 at bugs.launchpad.net  Fri Oct 24 18:07:51 2014
From: 1334926 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 24 Oct 2014 18:07:51 -0000
Subject: [Openstack-security] [Bug 1334926] Fix proposed to neutron
	(feature/lbaasv2)
References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com>
Message-ID: <20141024180751.3288.41786.malone@wampee.canonical.com>

Fix proposed to branch: feature/lbaasv2
Review: https://review.openstack.org/130864

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

Title:
  floatingip still working once connected even after it is disociated

Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in neutron icehouse series:
  Fix Released
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  After we create an SSH connection to a VM via its floating ip, even
  though we have removed the floating ip association, we can still
  access the VM via that connection. Namely, SSH is not disconnected
  when the floating ip is not valid

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



From morgan.fainberg at gmail.com  Fri Oct 24 18:43:57 2014
From: morgan.fainberg at gmail.com (Morgan Fainberg)
Date: Fri, 24 Oct 2014 18:43:57 -0000
Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not
 released back to the pool leading to choking of new requests
References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com>
Message-ID: <20141024184359.3158.75755.malone@wampee.canonical.com>

It is recommended Keystone is deployed under mod_wsgi, not eventlet,
this still does affect Keystone's eventlet deployment model.

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

** Also affects: keystone/juno
   Importance: Undecided
       Status: New

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

** Changed in: keystone/icehouse
       Status: New => Confirmed

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

** Changed in: keystone/juno
       Status: New => Confirmed

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

Title:
  Eventlet green threads not released back to the pool leading to
  choking of new requests

Status in Cinder:
  In Progress
Status in Cinder icehouse series:
  New
Status in OpenStack Image Registry and Delivery Service (Glance):
  In Progress
Status in Glance icehouse series:
  New
Status in OpenStack Identity (Keystone):
  In Progress
Status in Keystone icehouse series:
  Confirmed
Status in Keystone juno series:
  Confirmed
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in neutron icehouse series:
  New
Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Compute (nova) icehouse series:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Currently reproduced  on Juno milestone 2. but this issue should be
  reproducible in all releases since its inception.

  It is possible to choke OpenStack API controller services using
  wsgi+eventlet library by simply not closing the client socket
  connection. Whenever a request is received by any OpenStack API
  service for example nova api service, eventlet library creates a green
  thread from the pool and starts processing the request. Even after the
  response is sent to the caller, the green thread is not returned back
  to the pool until the client socket connection is closed. This way,
  any malicious user can send many API requests to the API controller
  node and determine the wsgi pool size configured for the given service
  and then send those many requests to the service and after receiving
  the response, wait there infinitely doing nothing leading to
  disrupting services for other tenants. Even when service providers
  have enabled rate limiting feature, it is possible to choke the API
  services with a group (many tenants) attack.

  Following program illustrates choking of nova-api services (but this
  problem is omnipresent in all other OpenStack API Services using
  wsgi+eventlet)

  Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py.
  After you run the below program, you should try to invoke API
  ============================================================================================
  import time
  import requests
  from multiprocessing import Process

  def request(number):
     #Port is important here
     path = 'http://127.0.0.1:8774/servers'
      try:
          response = requests.get(path)
          print "RESPONSE %s-%d" % (response.status_code, number)
          #during this sleep time, check if the client socket connection is released or not on the API controller node.
          time.sleep(1000)
          print “Thread %d complete" % number
      except requests.exceptions.RequestException as ex:
          print “Exception occurred %d-%s" % (number, str(ex))

  if __name__ == '__main__':
      processes = []
      for number in range(40):
          p = Process(target=request, args=(number,))
          p.start()
          processes.append(p)
      for p in processes:
          p.join()

  ================================================================================================

  Presently, the wsgi server allows persist connections if you configure keepalive to True which is default.
  In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server.

  Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter.
  For example.
  Keep-Alive: timeout=10, max=5

  Note: After we have disabled keepalive in all the OpenStack API
  service using wsgi library, then it might impact all existing
  applications built with the assumptions that OpenStack API services
  uses persistent connections. They might need to modify their
  applications if reconnection logic is not in place and also they might
  experience the performance has slowed down as it will need to
  reestablish the http connection for every request.

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



From morgan.fainberg at gmail.com  Fri Oct 24 18:50:13 2014
From: morgan.fainberg at gmail.com (Morgan Fainberg)
Date: Fri, 24 Oct 2014 18:50:13 -0000
Subject: [Openstack-security] [Bug 1381365] Re: SSL Version and cipher
	selection not possible
References: <20141015072233.17942.25827.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141024185015.7907.70830.launchpad@chaenomeles.canonical.com>

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

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

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

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

Title:
  SSL Version and cipher selection not possible

Status in Cinder:
  New
Status in OpenStack Image Registry and Delivery Service (Glance):
  New
Status in OpenStack Identity (Keystone):
  Confirmed
Status in OpenStack Compute (Nova):
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  We configure keystone to use SSL always. Due to the poodle issue, I was trying to configure keystone to disable SSLv3 completely. 
  http://googleonlinesecurity.blogspot.fi/2014/10/this-poodle-bites-exploiting-ssl-30.html
  https://www.openssl.org/~bodo/ssl-poodle.pdf

  It seems that keystone has no support for configring SSL versions, nor
  ciphers.

  If I'm not mistaken the relevant code is in the start function in
  common/environment/eventlet_server.py

  It calls 
  eventlet.wrap_ssl
  but with no SSL version nor cipher options. Since the interface is identical, I assume it uses ssl.wrap_socket. The default here seems to be  PROTOCOL_SSLv23 (SSL2 disabled), which would make this vulnerable to the poodle issue.

  SSL conifgs should probably be possible to be set in the config file
  (with sane defaults), so that current and newly detected weak ciphers
  can be disabled without code changes.

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



From abhishek.kekane at nttdata.com  Fri Oct 24 18:50:41 2014
From: abhishek.kekane at nttdata.com (Abhishek Kekane)
Date: Fri, 24 Oct 2014 18:50:41 -0000
Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not
 released back to the pool leading to choking of new requests
References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com>
Message-ID: <20141024185045.8191.28179.launchpad@chaenomeles.canonical.com>

** Changed in: keystone/juno
     Assignee: (unassigned) => Abhishek Kekane (abhishek-kekane)

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

Title:
  Eventlet green threads not released back to the pool leading to
  choking of new requests

Status in Cinder:
  In Progress
Status in Cinder icehouse series:
  New
Status in OpenStack Image Registry and Delivery Service (Glance):
  In Progress
Status in Glance icehouse series:
  New
Status in OpenStack Identity (Keystone):
  In Progress
Status in Keystone icehouse series:
  Confirmed
Status in Keystone juno series:
  Confirmed
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in neutron icehouse series:
  New
Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Compute (nova) icehouse series:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Currently reproduced  on Juno milestone 2. but this issue should be
  reproducible in all releases since its inception.

  It is possible to choke OpenStack API controller services using
  wsgi+eventlet library by simply not closing the client socket
  connection. Whenever a request is received by any OpenStack API
  service for example nova api service, eventlet library creates a green
  thread from the pool and starts processing the request. Even after the
  response is sent to the caller, the green thread is not returned back
  to the pool until the client socket connection is closed. This way,
  any malicious user can send many API requests to the API controller
  node and determine the wsgi pool size configured for the given service
  and then send those many requests to the service and after receiving
  the response, wait there infinitely doing nothing leading to
  disrupting services for other tenants. Even when service providers
  have enabled rate limiting feature, it is possible to choke the API
  services with a group (many tenants) attack.

  Following program illustrates choking of nova-api services (but this
  problem is omnipresent in all other OpenStack API Services using
  wsgi+eventlet)

  Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py.
  After you run the below program, you should try to invoke API
  ============================================================================================
  import time
  import requests
  from multiprocessing import Process

  def request(number):
     #Port is important here
     path = 'http://127.0.0.1:8774/servers'
      try:
          response = requests.get(path)
          print "RESPONSE %s-%d" % (response.status_code, number)
          #during this sleep time, check if the client socket connection is released or not on the API controller node.
          time.sleep(1000)
          print “Thread %d complete" % number
      except requests.exceptions.RequestException as ex:
          print “Exception occurred %d-%s" % (number, str(ex))

  if __name__ == '__main__':
      processes = []
      for number in range(40):
          p = Process(target=request, args=(number,))
          p.start()
          processes.append(p)
      for p in processes:
          p.join()

  ================================================================================================

  Presently, the wsgi server allows persist connections if you configure keepalive to True which is default.
  In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server.

  Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter.
  For example.
  Keep-Alive: timeout=10, max=5

  Note: After we have disabled keepalive in all the OpenStack API
  service using wsgi library, then it might impact all existing
  applications built with the assumptions that OpenStack API services
  uses persistent connections. They might need to modify their
  applications if reconnection logic is not in place and also they might
  experience the performance has slowed down as it will need to
  reestablish the http connection for every request.

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



From 1372635 at bugs.launchpad.net  Fri Oct 24 19:55:27 2014
From: 1372635 at bugs.launchpad.net (Xing Yang)
Date: Fri, 24 Oct 2014 19:55:27 -0000
Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC
	VMAX driver
References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com>
Message-ID: <20141024195527.2608.97506.malone@gac.canonical.com>

Opend a bug with Ubuntu: https://bugs.launchpad.net/ubuntu/+bug/1385469

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

Title:
  MITM vulnerability with EMC VMAX driver

Status in Cinder:
  Triaged
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The EMC VMAX driver in Juno appears to blindly trust whatever
  certificate it gets back from the device without any validation (it
  does not specify the ca_certs parameter, etc. on
  WBEMConnection.__init__). This would leave it open to a MITM attack.

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



From gerrit2 at review.openstack.org  Fri Oct 24 20:01:14 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 24 Oct 2014 20:01:14 +0000
Subject: [Openstack-security] [openstack/neutron] SecurityImpact review
 request change I3a361d6590d1800b85791f23ac1cdfd79815341b
Message-ID: <E1Xhl2w-0000Tl-7z@review.openstack.org>


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

Log:
commit f4bd0dbf4cbea6960fba2295c0514b867c8b3287
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Tue Oct 21 04:15:15 2014 -0700

    Eventlet green threads not released back to pool
    
    Presently, the wsgi server allows persist connections hence even after
    the response is sent to the client, it doesn't close the client socket
    connection.
    Because of this problem, the green thread is not released back to the pool.
    
    In order to close the client socket connection explicitly after the
    response is sent and read successfully by the client, you simply have to
    set keepalive to False when you create a wsgi server.
    
    Add a parameter to take advantage of the new(ish) eventlet socket timeout
    behaviour. Allows closing idle client connections after a period of
    time, eg:
    
    $ time nc localhost 8776
    real    1m0.063s
    
    Setting 'client_socket_timeout = 0' means do not timeout.
    
    DocImpact:
    Added wsgi_keep_alive option (default=True).
    Added client_socket_timeout option (default=900).
    
    SecurityImpact
    
    Closes-Bug: #1361360
    Change-Id: I3a361d6590d1800b85791f23ac1cdfd79815341b




From gerrit2 at review.openstack.org  Fri Oct 24 21:47:16 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 24 Oct 2014 21:47:16 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change Ic57b2aceb136e8626388cfe4df72b2f47cb0661c
Message-ID: <E1XhmhY-0006nz-4e@review.openstack.org>


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

Log:
commit fc87da7eeb3451e139ee71b31095d0b9093332ce
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Tue Oct 21 02:31:15 2014 -0700

    Eventlet green threads not released back to pool
    
    Presently, the wsgi server allows persist connections hence even after
    the response is sent to the client, it doesn't close the client socket
    connection.
    Because of this problem, the green thread is not released back to the pool.
    
    In order to close the client socket connection explicitly after the
    response is sent and read successfully by the client, you simply have to
    set keepalive to False when you create a wsgi server.
    
    DocImpact:
    Added wsgi_keep_alive option (default=True).
    In order to maintain the backward compatibility, setting wsgi_keep_alive
    as True by default. Recommended is set it to False.
    
    SecurityImpact
    
    Closes-Bug: #1361360
    Change-Id: Ic57b2aceb136e8626388cfe4df72b2f47cb0661c




From 1372635 at bugs.launchpad.net  Sat Oct 25 05:02:27 2014
From: 1372635 at bugs.launchpad.net (OpenStack Infra)
Date: Sat, 25 Oct 2014 05:02:27 -0000
Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC
	VMAX driver
References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com>
Message-ID: <20141025050227.3324.68802.malone@wampee.canonical.com>

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

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

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

Title:
  MITM vulnerability with EMC VMAX driver

Status in Cinder:
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The EMC VMAX driver in Juno appears to blindly trust whatever
  certificate it gets back from the device without any validation (it
  does not specify the ca_certs parameter, etc. on
  WBEMConnection.__init__). This would leave it open to a MITM attack.

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



From gerrit2 at review.openstack.org  Sat Oct 25 06:29:26 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Sat, 25 Oct 2014 06:29:26 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7
Message-ID: <E1Xhuqs-00052t-UK@review.openstack.org>


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

Log:
commit 2e6cddfe2133cb7067ee879472f5ad9f92480308
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Tue Oct 21 04:10:57 2014 -0700

    Eventlet green threads not released back to pool
    
    Presently, the wsgi server allows persist connections hence even after
    the response is sent to the client, it doesn't close the client socket
    connection.
    Because of this problem, the green thread is not released back to the pool.
    
    In order to close the client socket connection explicitly after the
    response is sent and read successfully by the client, you simply have to
    set keepalive to False when you create a wsgi server.
    
    Add a parameter to take advantage of the new(ish) eventlet socket timeout
    behaviour. Allows closing idle client connections after a period of
    time, eg:
    
    $ time nc localhost 8776
    real    1m0.063s
    
    Setting 'client_socket_timeout = 0' means do not timeout.
    
    DocImpact:
    Added wsgi_keep_alive option (default=True).
    Added client_socket_timeout option (default=900).
    
    SecurityImpact
    
    Closes-Bug: #1361360
    Change-Id: I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7




From thingee at gmail.com  Sun Oct 26 22:42:05 2014
From: thingee at gmail.com (Mike Perez)
Date: Sun, 26 Oct 2014 22:42:05 -0000
Subject: [Openstack-security] [Bug 1372643] Re: MITM vulnerability with XIV
	driver
References: <20140922204545.32411.9337.malonedeb@gac.canonical.com>
Message-ID: <20141026224209.3586.56555.launchpad@wampee.canonical.com>

** Changed in: cinder
       Status: Triaged => Invalid

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

Title:
  MITM vulnerability with XIV driver

Status in Cinder:
  Invalid
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The XIV driver in Juno appears to blindly trust whatever certificate
  it gets back from the device without any validation. This would leave
  it open to a MITM attack.

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



From farazhyder55 at gmail.com  Mon Oct 27 05:43:20 2014
From: farazhyder55 at gmail.com (Muhammad Faraz Hyder)
Date: Mon, 27 Oct 2014 10:43:20 +0500
Subject: [Openstack-security] Help regarding Chain of Trust implementation
	in Openstack cloud.
Message-ID: <CAF47eer-=6hO=_-9Kz0c+skcXfExyeefdjsmy0eXkDp6y5WZ4w@mail.gmail.com>

Hi,

I need help regarding the implementation of Trust in openstack cloud. I
have gone through the TPM based implementation and Open attestation
provided by Intel.

But, what i am trying to implement is some non-vendor /non- hardware
dependent solution.

Is PKI could be good idea for the implementation of Chain of Trust?. Please
guide me in this regard, as I am still unable to come up with right idea
for the implementation.


Regards,
Faraz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141027/5c16454a/attachment.html>

From robert.clark at hp.com  Mon Oct 27 09:11:37 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Mon, 27 Oct 2014 09:11:37 +0000
Subject: [Openstack-security] Help regarding Chain of Trust
 implementation	in Openstack cloud.
In-Reply-To: <CAF47eer-=6hO=_-9Kz0c+skcXfExyeefdjsmy0eXkDp6y5WZ4w@mail.gmail.com>
References: <CAF47eer-=6hO=_-9Kz0c+skcXfExyeefdjsmy0eXkDp6y5WZ4w@mail.gmail.com>
Message-ID: <A0C170085C37664D93EE1604364858A112503BB9@G4W3300.americas.hpqcorp.net>

Hi Faraz,

 

We can likely help you more if you provide a little bit more background.

 

Have you taken a look at the OpenStack Security Guide http://docs.openstack.org/sec/ ? That touches on a number of related topics, we’ve also got several people in the group who are very familiar with trusted computing who I’m sure will reply to this thread.

 

-Rob

 

From: Muhammad Faraz Hyder [mailto:farazhyder55 at gmail.com] 
Sent: 27 October 2014 05:43
To: openstack-security at lists.openstack.org
Subject: [Openstack-security] Help regarding Chain of Trust implementation in Openstack cloud.

 

Hi, 

 

I need help regarding the implementation of Trust in openstack cloud. I have gone through the TPM based implementation and Open attestation provided by Intel. 

 

But, what i am trying to implement is some non-vendor /non- hardware dependent solution.

 

Is PKI could be good idea for the implementation of Chain of Trust?. Please guide me in this regard, as I am still unable to come up with right idea for the implementation.  

 

 

Regards, 

Faraz 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141027/f475a20e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6187 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141027/f475a20e/attachment.bin>

From anish2good at yahoo.co.in  Mon Oct 27 09:47:58 2014
From: anish2good at yahoo.co.in (Anish)
Date: Mon, 27 Oct 2014 17:47:58 +0800
Subject: [Openstack-security] Help regarding Chain of Trust
	implementation	in Openstack cloud.
In-Reply-To: <A0C170085C37664D93EE1604364858A112503BB9@G4W3300.americas.hpqcorp.net>
References: <CAF47eer-=6hO=_-9Kz0c+skcXfExyeefdjsmy0eXkDp6y5WZ4w@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A112503BB9@G4W3300.americas.hpqcorp.net>
Message-ID: <1414403278.82495.YahooMailNeo@web193303.mail.sg3.yahoo.com>

Hyder,
ps[Tell us the Use case what exactly are you trying to solve]

Otherwise, in order to build chain of trust, you can use cryptography concept of building a rootCA, and creating chain of certificate
This is part of PKI infrastructure,where digital certificates are verified using a chain of trust
--
Anish



On Monday, 27 October 2014 2:42 PM, "Clark, Robert Graham" <robert.clark at hp.com> wrote:
 


Hi Faraz,
 
We can likely help you more if you provide a little bit more background.
 
Have you taken a look at the OpenStack Security Guide http://docs.openstack.org/sec/ ? That touches on a number of related topics, we’ve also got several people in the group who are very familiar with trusted computing who I’m sure will reply to this thread.
 
-Rob
 
From:Muhammad Faraz Hyder [mailto:farazhyder55 at gmail.com] 
Sent: 27 October 2014 05:43
To: openstack-security at lists.openstack.org
Subject: [Openstack-security] Help regarding Chain of Trust implementation in Openstack cloud.
 
Hi, 
 
I need help regarding the implementation of Trust in openstack cloud. I have gone through the TPM based implementation and Open attestation provided by Intel. 
 
But, what i am trying to implement is some non-vendor /non- hardware dependent solution.
 
Is PKI could be good idea for the implementation of Chain of Trust?. Please guide me in this regard, as I am still unable to come up with right idea for the implementation.  
 
 
Regards, 
Faraz 

_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141027/232f64e8/attachment.html>

From farazhyder55 at gmail.com  Mon Oct 27 14:48:35 2014
From: farazhyder55 at gmail.com (Muhammad Faraz Hyder)
Date: Mon, 27 Oct 2014 19:48:35 +0500
Subject: [Openstack-security] Help regarding Chain of Trust
 implementation in Openstack cloud.
In-Reply-To: <1414403278.82495.YahooMailNeo@web193303.mail.sg3.yahoo.com>
References: <CAF47eer-=6hO=_-9Kz0c+skcXfExyeefdjsmy0eXkDp6y5WZ4w@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A112503BB9@G4W3300.americas.hpqcorp.net>
 <1414403278.82495.YahooMailNeo@web193303.mail.sg3.yahoo.com>
Message-ID: <CAF47eeoZOdnYyXYgiTT=vHubmSkGCsrwsqLk-dm=HLyreUoHLw@mail.gmail.com>

Thanks Robert and Anish.,

Actually I am doing my masters in Computer Engineering. My research topic
is related to trust establishment in cloud computing. I have deployed the
Openstack cloud. Now I have to work on the trust. I have gone through
different trust models.  In most papers that I have read, people build the
trust using TPM hardware chip.

Now, I have to build some sort of trust at different layers of cloud. Idea
in my mind was that we can use cryptography and PKI  etc for establishing
trust. Or I can go with some sort of auditing and logging , so that user
can have to certain extend more visibility of their data, this might also
provide trust. and also I can go with some mechanism for providing the
verification of cloud images that cloud customers uses, so that cloud
images are not tempered by cloud service provider.


Regards,
Faraz

On Mon, Oct 27, 2014 at 2:47 PM, Anish <anish2good at yahoo.co.in> wrote:

> Hyder,
> ps[Tell us the Use case what exactly are you trying to solve]
>
> Otherwise, in order to build chain of trust, you can use cryptography
> concept of building a rootCA, and creating chain of certificate
> This is part of PKI infrastructure,where digital certificates are verified
> using a chain of trust
> --
> Anish
>
>
>
>   On Monday, 27 October 2014 2:42 PM, "Clark, Robert Graham" <
> robert.clark at hp.com> wrote:
>
>
> Hi Faraz,
>
> We can likely help you more if you provide a little bit more background.
>
> Have you taken a look at the OpenStack Security Guide
> http://docs.openstack.org/sec/ ? That touches on a number of related
> topics, we’ve also got several people in the group who are very familiar
> with trusted computing who I’m sure will reply to this thread.
>
> -Rob
>
> *From:* Muhammad Faraz Hyder [mailto:farazhyder55 at gmail.com]
> *Sent:* 27 October 2014 05:43
> *To:* openstack-security at lists.openstack.org
> *Subject:* [Openstack-security] Help regarding Chain of Trust
> implementation in Openstack cloud.
>
> Hi,
>
> I need help regarding the implementation of Trust in openstack cloud. I
> have gone through the TPM based implementation and Open attestation
> provided by Intel.
>
> But, what i am trying to implement is some non-vendor /non- hardware
> dependent solution.
>
> Is PKI could be good idea for the implementation of Chain of Trust?.
> Please guide me in this regard, as I am still unable to come up with right
> idea for the implementation.
>
>
> Regards,
> Faraz
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141027/bd828a29/attachment.html>

From anish2good at yahoo.co.in  Mon Oct 27 15:16:37 2014
From: anish2good at yahoo.co.in (Anish)
Date: Mon, 27 Oct 2014 23:16:37 +0800
Subject: [Openstack-security] Help regarding Chain of Trust
	implementation in Openstack cloud.
In-Reply-To: <CAF47eeoZOdnYyXYgiTT=vHubmSkGCsrwsqLk-dm=HLyreUoHLw@mail.gmail.com>
References: <CAF47eer-=6hO=_-9Kz0c+skcXfExyeefdjsmy0eXkDp6y5WZ4w@mail.gmail.com>	<A0C170085C37664D93EE1604364858A112503BB9@G4W3300.americas.hpqcorp.net>	<1414403278.82495.YahooMailNeo@web193303.mail.sg3.yahoo.com>
 <CAF47eeoZOdnYyXYgiTT=vHubmSkGCsrwsqLk-dm=HLyreUoHLw@mail.gmail.com>
Message-ID: <1414422997.15889.YahooMailNeo@web193302.mail.sg3.yahoo.com>

Hyder,

Few questions
	* Who is the User is the device/storage or end user?
	* What is the Service ?
	* What are you trying to change, that doesn't provided by the Opestack framework
	* Cloud Images ? are you specific about the Glance ?
	* Did you try to explore the keystone, RBAC feature
	* are you trying to create trust model like AAA

--
Anish
 


On Monday, 27 October 2014 8:18 PM, Muhammad Faraz Hyder <farazhyder55 at gmail.com> wrote:
 


Thanks Robert and Anish., 

Actually I am doing my masters in Computer Engineering. My research topic is related to trust establishment in cloud computing. I have deployed the Openstack cloud. Now I have to work on the trust. I have gone through different trust models.  In most papers that I have read, people build the trust using TPM hardware chip. 

Now, I have to build some sort of trust at different layers of cloud. Idea in my mind was that we can use cryptography and PKI  etc for establishing trust. Or I can go with some sort of auditing and logging , so that user can have to certain extend more visibility of their data, this might also provide trust. and also I can go with some mechanism for providing the verification of cloud images that cloud customers uses, so that cloud images are not tempered by cloud service provider. 
 

Regards, 
Faraz 


On Mon, Oct 27, 2014 at 2:47 PM, Anish <anish2good at yahoo.co.in> wrote:

Hyder,
>ps[Tell us the Use case what exactly are you trying to solve]
>
>
>Otherwise, in order to build chain of trust, you can use cryptography concept of building a rootCA, and creating chain of certificate
>This is part of PKI infrastructure,where digital certificates are verified using a chain of trust
>--
>Anish
>
>
>
>
>
>On Monday, 27 October 2014 2:42 PM, "Clark, Robert Graham" <robert.clark at hp.com> wrote:
> 
>
>
>Hi Faraz,
> 
>We can likely help you more if you provide a little bit more background.
> 
>Have you taken a look at the OpenStack Security Guide http://docs.openstack.org/sec/ ? That touches on a number of related topics, we’ve also got several people in the group who are very familiar with trusted computing who I’m sure will reply to this thread.
> 
>-Rob
> 
>From:Muhammad Faraz Hyder [mailto:farazhyder55 at gmail.com] 
>Sent: 27 October 2014 05:43
>To: openstack-security at lists.openstack.org
>Subject: [Openstack-security] Help regarding Chain of Trust implementation in Openstack cloud.
> 
>Hi, 
> 
>I need help regarding the implementation of Trust in openstack cloud. I have gone through the TPM based implementation and Open attestation provided by Intel. 
> 
>But, what i am trying to implement is some non-vendor /non- hardware dependent solution.
> 
>Is PKI could be good idea for the implementation of Chain of Trust?. Please guide me in this regard, as I am still unable to come up with right idea for the implementation.  
> 
> 
>Regards, 
>Faraz 
>
>_______________________________________________
>Openstack-security mailing list
>Openstack-security at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141027/a6fff041/attachment.html>

From bdpayne at acm.org  Mon Oct 27 19:06:59 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Mon, 27 Oct 2014 12:06:59 -0700
Subject: [Openstack-security] OSSG Lead Election Results
Message-ID: <CAFpPvXBmHntgiXvv-jqVU3XyD_y1un24Ydp2txJ7h6HDKhm3aQ@mail.gmail.com>

Please join me in congratulating Rob Clark for being elected to another
term as OSSG Lead. Thanks to everyone that voted.

Cheers,
-bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141027/4097c368/attachment.html>

From matt at nycresistor.com  Mon Oct 27 19:13:51 2014
From: matt at nycresistor.com (matt)
Date: Mon, 27 Oct 2014 15:13:51 -0400
Subject: [Openstack-security] OSSG Lead Election Results
In-Reply-To: <CAFpPvXBmHntgiXvv-jqVU3XyD_y1un24Ydp2txJ7h6HDKhm3aQ@mail.gmail.com>
References: <CAFpPvXBmHntgiXvv-jqVU3XyD_y1un24Ydp2txJ7h6HDKhm3aQ@mail.gmail.com>
Message-ID: <CAP_sDUFpH6CPijBJp4H6PGHYv18nRAO263h-962_GwE4O07zMw@mail.gmail.com>

rob clark is good people.  much love.

On Mon, Oct 27, 2014 at 3:06 PM, Bryan D. Payne <bdpayne at acm.org> wrote:

> Please join me in congratulating Rob Clark for being elected to another
> term as OSSG Lead. Thanks to everyone that voted.
>
> Cheers,
> -bryan
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141027/c26c3bd4/attachment.html>

From travis.mcpeak at hp.com  Mon Oct 27 19:17:07 2014
From: travis.mcpeak at hp.com (McPeak, Travis)
Date: Mon, 27 Oct 2014 19:17:07 +0000
Subject: [Openstack-security] OSSG Lead Election Results
Message-ID: <D073E7E5.E3D%travis.mcpeak@hp.com>

Congrats Rob! Very well deserved. Now on to fix the things.

On 10/27/14, 12:07 PM, "openstack-security-request at lists.openstack.org"
<openstack-security-request at lists.openstack.org> wrote:

>Please join me in congratulating Rob Clark for being elected to another
>term as OSSG Lead. Thanks to everyone that voted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2751 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141027/ec1e9289/attachment.bin>

From cody.bunch at rackspace.com  Mon Oct 27 19:22:49 2014
From: cody.bunch at rackspace.com (Cody Bunch)
Date: Mon, 27 Oct 2014 19:22:49 +0000
Subject: [Openstack-security] OSSG Lead Election Results
In-Reply-To: <CAP_sDUFpH6CPijBJp4H6PGHYv18nRAO263h-962_GwE4O07zMw@mail.gmail.com>
References: <CAFpPvXBmHntgiXvv-jqVU3XyD_y1un24Ydp2txJ7h6HDKhm3aQ@mail.gmail.com>,
 <CAP_sDUFpH6CPijBJp4H6PGHYv18nRAO263h-962_GwE4O07zMw@mail.gmail.com>
Message-ID: <327FAB32C28C564DAA23CE6D03789DBCC93976E5@ORD1EXD01.RACKSPACE.CORP>

Congrats sir!
________________________________
From: matt [matt at nycresistor.com]
Sent: Monday, October 27, 2014 2:13 PM
To: Bryan D. Payne
Cc: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] OSSG Lead Election Results

rob clark is good people.  much love.

On Mon, Oct 27, 2014 at 3:06 PM, Bryan D. Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>> wrote:
Please join me in congratulating Rob Clark for being elected to another term as OSSG Lead. Thanks to everyone that voted.

Cheers,
-bryan

_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141027/8b403d3b/attachment.html>

From michael.xin at RACKSPACE.COM  Mon Oct 27 19:30:54 2014
From: michael.xin at RACKSPACE.COM (Michael Xin)
Date: Mon, 27 Oct 2014 19:30:54 +0000
Subject: [Openstack-security] OSSG Lead Election Results
In-Reply-To: <327FAB32C28C564DAA23CE6D03789DBCC93976E5@ORD1EXD01.RACKSPACE.CORP>
References: <CAFpPvXBmHntgiXvv-jqVU3XyD_y1un24Ydp2txJ7h6HDKhm3aQ@mail.gmail.com>
 <CAP_sDUFpH6CPijBJp4H6PGHYv18nRAO263h-962_GwE4O07zMw@mail.gmail.com>
 <327FAB32C28C564DAA23CE6D03789DBCC93976E5@ORD1EXD01.RACKSPACE.CORP>
Message-ID: <D0740790.370CE%michael.xin@rackspace.com>

Rob:
Congratulations!

Thanks and have a great day.

Yours,
Michael

-----------------------------------------------------------------------------
Michael Xin | Manager, Security Engineering - US
Product Security  |Rackspace Hosting
Office #: 501-7341   or  210-312-7341
Mobile #: 210-284-8674
5000 Walzem Road, San Antonio, Tx 78218
----------------------------------------------------------------------------
Experience fanatical support


From: Cody Bunch <cody.bunch at rackspace.com<mailto:cody.bunch at rackspace.com>>
Date: Monday, October 27, 2014 at 2:22 PM
To: matt <matt at nycresistor.com<mailto:matt at nycresistor.com>>, "Bryan D. Payne" <bdpayne at acm.org<mailto:bdpayne at acm.org>>
Cc: "openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>" <openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>>
Subject: Re: [Openstack-security] OSSG Lead Election Results

Congrats sir!
________________________________
From: matt [matt at nycresistor.com<mailto:matt at nycresistor.com>]
Sent: Monday, October 27, 2014 2:13 PM
To: Bryan D. Payne
Cc: openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>
Subject: Re: [Openstack-security] OSSG Lead Election Results

rob clark is good people.  much love.

On Mon, Oct 27, 2014 at 3:06 PM, Bryan D. Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>> wrote:
Please join me in congratulating Rob Clark for being elected to another term as OSSG Lead. Thanks to everyone that voted.

Cheers,
-bryan

_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141027/bf24ff59/attachment.html>

From msm at redhat.com  Mon Oct 27 22:30:44 2014
From: msm at redhat.com (Michael McCune)
Date: Mon, 27 Oct 2014 18:30:44 -0400 (EDT)
Subject: [Openstack-security] Seeking assistance with topic review for
	Sahara security session
In-Reply-To: <313117790.717223.1414447783697.JavaMail.zimbra@redhat.com>
Message-ID: <1526173722.720040.1414449044585.JavaMail.zimbra@redhat.com>

hi OSSG,

I talked with some of you at the last OSSG meeting about assistance in getting the Sahara project more in-line with best OpenStack security practices and specifically about our security related session at the design summit.

I'm writing today to followup on that conversation with a link to the etherpad I have started for topics[1], and to ask if there are other areas we should be looking at?

Also, I am interesting in learning more about the various vectors we should be studying from the Sahara perspective to help move towards a more secure system. I have a moderate knowledge of general computer security and I am working through the OpenStack security guide. Ultimately what I would love to do is assist the OSSG team with a security audit and/or high-level threat analysis for Sahara.

I welcome comments/criticism on the topics in the etherpad, and I would love to hear more thoughts on areas that we might investigate.

regards,
mike

[1]: https://etherpad.openstack.org/p/kilo-summit-sahara-security-session



From anish2good at yahoo.co.in  Tue Oct 28 04:05:00 2014
From: anish2good at yahoo.co.in (Anish)
Date: Tue, 28 Oct 2014 12:05:00 +0800
Subject: [Openstack-security] OSSG Lead Election Results
In-Reply-To: <D0740790.370CE%michael.xin@rackspace.com>
References: <CAFpPvXBmHntgiXvv-jqVU3XyD_y1un24Ydp2txJ7h6HDKhm3aQ@mail.gmail.com>
 <CAP_sDUFpH6CPijBJp4H6PGHYv18nRAO263h-962_GwE4O07zMw@mail.gmail.com>
 <327FAB32C28C564DAA23CE6D03789DBCC93976E5@ORD1EXD01.RACKSPACE.CORP>
 <D0740790.370CE%michael.xin@rackspace.com>
Message-ID: <1414469100.41471.YahooMailNeo@web193306.mail.sg3.yahoo.com>

Congrats Rob Clark, 

With regards
Anish Nath

 

 


On Tuesday, 28 October 2014 1:01 AM, Michael Xin <michael.xin at RACKSPACE.COM> wrote:
 


Rob:
Congratulations!

Thanks and have a great day. 

Yours,
Michael 

-----------------------------------------------------------------------------
Michael Xin | Manager, Security Engineering - US 
Product Security  |Rackspace Hosting
Office #: 501-7341   or  210-312-7341
Mobile #: 210-284-8674 
5000 Walzem Road, San Antonio, Tx 78218
----------------------------------------------------------------------------
Experience fanatical support


From: Cody Bunch <cody.bunch at rackspace.com>
Date: Monday, October 27, 2014 at 2:22 PM
To: matt <matt at nycresistor.com>, "Bryan D. Payne" <bdpayne at acm.org>
Cc: "openstack-security at lists.openstack.org" <openstack-security at lists.openstack.org>
Subject: Re: [Openstack-security] OSSG Lead Election Results


 
Congrats sir!


________________________________
 
From: matt [matt at nycresistor.com]
Sent: Monday, October 27, 2014 2:13 PM
To: Bryan D. Payne
Cc: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] OSSG Lead Election Results


rob clark is good people.  much love.



On Mon, Oct 27, 2014 at 3:06 PM, Bryan D. Payne <bdpayne at acm.org> wrote:

Please join me in congratulating Rob Clark for being elected to another term as OSSG Lead. Thanks to everyone that voted. 
>
>
>Cheers,
>-bryan
>_______________________________________________
>Openstack-security mailing list
>Openstack-security at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>


_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141028/71455ea9/attachment.html>

From shardy at redhat.com  Tue Oct 28 09:15:36 2014
From: shardy at redhat.com (Steven Hardy)
Date: Tue, 28 Oct 2014 09:15:36 -0000
Subject: [Openstack-security] [Bug 1384626] Re: SSL certification
 verification failed when Heat calls Glanceclient with ca cert
References: <20141023090711.3131.60470.malonedeb@wampee.canonical.com>
Message-ID: <20141028091536.3464.66538.launchpad@soybean.canonical.com>

** Also affects: heat/juno
   Importance: Undecided
       Status: New

** Changed in: heat/juno
   Importance: Undecided => High

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

Title:
  SSL certification verification failed when Heat calls Glanceclient
  with ca cert

Status in Orchestration API (Heat):
  Fix Committed
Status in heat juno series:
  New

Bug description:
  Glance server is configured Https.

  Configured Heat with heat.conf 
  [clients_glance]
  ca_file=<ca file path>
  insecure=<false>

  When trying to create stack, heat will raise exception during heat to load image data.
  [Errno 1] _ssl.c:492: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

  The root cause is that: ca_file as below is a wrong argument to
  initialize the glance client,  it should be cacert which is supported
  arguments by glanceclient.

  class GlanceClientPlugin(client_plugin.ClientPlugin):

      exceptions_module = exc

      def _create(self):

          con = self.context
          endpoint_type = self._get_client_option('glance', 'endpoint_type')
          endpoint = self.url_for(service_type='image',
                                  endpoint_type=endpoint_type)
          args = {
              'auth_url': con.auth_url,
              'service_type': 'image',
              'project_id': con.tenant,
              'token': self.auth_token,
              'endpoint_type': endpoint_type,
              'ca_file': self._get_client_option('glance', 'ca_file'),
              'cert_file': self._get_client_option('glance', 'cert_file'),
              'key_file': self._get_client_option('glance', 'key_file'),
              'insecure': self._get_client_option('glance', 'insecure')

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



From robert.clark at hp.com  Tue Oct 28 17:28:58 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Tue, 28 Oct 2014 17:28:58 +0000
Subject: [Openstack-security] OSSG Lead Election Results
In-Reply-To: <1414469100.41471.YahooMailNeo@web193306.mail.sg3.yahoo.com>
References: <CAFpPvXBmHntgiXvv-jqVU3XyD_y1un24Ydp2txJ7h6HDKhm3aQ@mail.gmail.com>
 <CAP_sDUFpH6CPijBJp4H6PGHYv18nRAO263h-962_GwE4O07zMw@mail.gmail.com>
 <327FAB32C28C564DAA23CE6D03789DBCC93976E5@ORD1EXD01.RACKSPACE.CORP>
 <D0740790.370CE%michael.xin@rackspace.com>
 <1414469100.41471.YahooMailNeo@web193306.mail.sg3.yahoo.com>
Message-ID: <A0C170085C37664D93EE1604364858A112522D36@G4W3300.americas.hpqcorp.net>

[Continuing top posting]

 

Hi All,

 

Thank you for your kind words, I’m looking forward to what the next 6 months will bring!

 

With any luck I’ll see most of you at the summit next week.

 

Kind Regards

-Rob

 

From: Anish [mailto:anish2good at yahoo.co.in] 
Sent: 28 October 2014 04:05
To: Michael Xin; Cody Bunch; matt; Bryan D. Payne
Cc: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] OSSG Lead Election Results

 

Congrats Rob Clark, 

 

With regards

Anish Nath


 


 

 

On Tuesday, 28 October 2014 1:01 AM, Michael Xin <michael.xin at RACKSPACE.COM <mailto:michael.xin at RACKSPACE.COM> > wrote:

 

Rob:

Congratulations!

 

Thanks and have a great day. 

 

Yours,

Michael 

 

-----------------------------------------------------------------------------

Michael Xin | Manager, Security Engineering - US 

Product Security  |Rackspace Hosting

Office #: 501-7341   or  210-312-7341

Mobile #: 210-284-8674 

5000 Walzem Road, San Antonio, Tx 78218

----------------------------------------------------------------------------

Experience fanatical support

 

 

From: Cody Bunch <cody.bunch at rackspace.com <mailto:cody.bunch at rackspace.com> >
Date: Monday, October 27, 2014 at 2:22 PM
To: matt <matt at nycresistor.com <mailto:matt at nycresistor.com> >, "Bryan D. Payne" <bdpayne at acm.org <mailto:bdpayne at acm.org> >
Cc: "openstack-security at lists.openstack.org <mailto:openstack-security at lists.openstack.org> " <openstack-security at lists.openstack.org <mailto:openstack-security at lists.openstack.org> >
Subject: Re: [Openstack-security] OSSG Lead Election Results

 

Congrats sir!

  _____  

From: matt [matt at nycresistor.com <mailto:matt at nycresistor.com> ]
Sent: Monday, October 27, 2014 2:13 PM
To: Bryan D. Payne
Cc: openstack-security at lists.openstack.org <mailto:openstack-security at lists.openstack.org> 
Subject: Re: [Openstack-security] OSSG Lead Election Results

rob clark is good people.  much love.

 

On Mon, Oct 27, 2014 at 3:06 PM, Bryan D. Payne <bdpayne at acm.org <mailto:bdpayne at acm.org> > wrote:

Please join me in congratulating Rob Clark for being elected to another term as OSSG Lead. Thanks to everyone that voted. 

 

Cheers,

-bryan


_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org <mailto:Openstack-security at lists.openstack.org> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

 

 

_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org <mailto:Openstack-security at lists.openstack.org> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141028/4ffa9a2a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6187 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141028/4ffa9a2a/attachment.bin>

From sriram at sriramhere.com  Tue Oct 28 19:04:26 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Tue, 28 Oct 2014 12:04:26 -0700
Subject: [Openstack-security] OSSG Lead Election Results
In-Reply-To: <A0C170085C37664D93EE1604364858A112522D36@G4W3300.americas.hpqcorp.net>
References: <CAFpPvXBmHntgiXvv-jqVU3XyD_y1un24Ydp2txJ7h6HDKhm3aQ@mail.gmail.com>
 <CAP_sDUFpH6CPijBJp4H6PGHYv18nRAO263h-962_GwE4O07zMw@mail.gmail.com>
 <327FAB32C28C564DAA23CE6D03789DBCC93976E5@ORD1EXD01.RACKSPACE.CORP>
 <D0740790.370CE%michael.xin@rackspace.com>
 <1414469100.41471.YahooMailNeo@web193306.mail.sg3.yahoo.com>
 <A0C170085C37664D93EE1604364858A112522D36@G4W3300.americas.hpqcorp.net>
Message-ID: <CAP6wb7+s_T9AOdh_QEKHG2qt6H-+fJ2ctAt3gF+_6-YhwzyKeA@mail.gmail.com>

Congrats Rob!

Are we doing our meetup lunch this time too? I am going to be in, would
love to join. Who else?

thanks,
-Sriram

On Tue, Oct 28, 2014 at 10:28 AM, Clark, Robert Graham <robert.clark at hp.com>
wrote:

> [Continuing top posting]
>
>
>
> Hi All,
>
>
>
> Thank you for your kind words, I’m looking forward to what the next 6
> months will bring!
>
>
>
> With any luck I’ll see most of you at the summit next week.
>
>
>
> Kind Regards
>
> -Rob
>
>
>
> *From:* Anish [mailto:anish2good at yahoo.co.in]
> *Sent:* 28 October 2014 04:05
> *To:* Michael Xin; Cody Bunch; matt; Bryan D. Payne
>
> *Cc:* openstack-security at lists.openstack.org
> *Subject:* Re: [Openstack-security] OSSG Lead Election Results
>
>
>
> Congrats Rob Clark,
>
>
>
> With regards
>
> Anish Nath
>
>
>
>
>
>
>
>
>
> On Tuesday, 28 October 2014 1:01 AM, Michael Xin <
> michael.xin at RACKSPACE.COM> wrote:
>
>
>
> Rob:
>
> Congratulations!
>
>
>
> Thanks and have a great day.
>
>
>
> Yours,
>
> Michael
>
>
>
>
> -----------------------------------------------------------------------------
>
> Michael Xin | Manager, Security Engineering - US
>
> Product Security  |Rackspace Hosting
>
> Office #: 501-7341   or  210-312-7341
>
> Mobile #: 210-284-8674
>
> 5000 Walzem Road, San Antonio, Tx 78218
>
>
> ----------------------------------------------------------------------------
>
> Experience fanatical support
>
>
>
>
>
> *From: *Cody Bunch <cody.bunch at rackspace.com>
> *Date: *Monday, October 27, 2014 at 2:22 PM
> *To: *matt <matt at nycresistor.com>, "Bryan D. Payne" <bdpayne at acm.org>
> *Cc: *"openstack-security at lists.openstack.org" <
> openstack-security at lists.openstack.org>
> *Subject: *Re: [Openstack-security] OSSG Lead Election Results
>
>
>
> Congrats sir!
> ------------------------------
>
> *From:* matt [matt at nycresistor.com]
> *Sent:* Monday, October 27, 2014 2:13 PM
> *To:* Bryan D. Payne
> *Cc:* openstack-security at lists.openstack.org
> *Subject:* Re: [Openstack-security] OSSG Lead Election Results
>
> rob clark is good people.  much love.
>
>
>
> On Mon, Oct 27, 2014 at 3:06 PM, Bryan D. Payne <bdpayne at acm.org> wrote:
>
> Please join me in congratulating Rob Clark for being elected to another
> term as OSSG Lead. Thanks to everyone that voted.
>
>
>
> Cheers,
>
> -bryan
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>


-- 
Thanks,
-Sriram
425-610-8465
www.sriramhere.com | www.clouddon.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141028/cc621b06/attachment.html>

From robert.clark at hp.com  Tue Oct 28 19:05:27 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Tue, 28 Oct 2014 19:05:27 +0000
Subject: [Openstack-security] OSSG Lead Election Results
In-Reply-To: <CAP6wb7+s_T9AOdh_QEKHG2qt6H-+fJ2ctAt3gF+_6-YhwzyKeA@mail.gmail.com>
References: <CAFpPvXBmHntgiXvv-jqVU3XyD_y1un24Ydp2txJ7h6HDKhm3aQ@mail.gmail.com>
 <CAP_sDUFpH6CPijBJp4H6PGHYv18nRAO263h-962_GwE4O07zMw@mail.gmail.com>
 <327FAB32C28C564DAA23CE6D03789DBCC93976E5@ORD1EXD01.RACKSPACE.CORP>
 <D0740790.370CE%michael.xin@rackspace.com>
 <1414469100.41471.YahooMailNeo@web193306.mail.sg3.yahoo.com>
 <A0C170085C37664D93EE1604364858A112522D36@G4W3300.americas.hpqcorp.net>
 <CAP6wb7+s_T9AOdh_QEKHG2qt6H-+fJ2ctAt3gF+_6-YhwzyKeA@mail.gmail.com>
Message-ID: <A0C170085C37664D93EE1604364858A112522F09@G4W3300.americas.hpqcorp.net>

Yes we are, no idea where yet. I think Tuesday lunchtime may make sense?

 

-Rob

 

From: Sriram Subramanian [mailto:sriram at sriramhere.com] 
Sent: 28 October 2014 19:04
To: Clark, Robert Graham
Cc: Anish; Michael Xin; Cody Bunch; matt; Bryan D. Payne; openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] OSSG Lead Election Results

 

Congrats Rob!

 

Are we doing our meetup lunch this time too? I am going to be in, would love to join. Who else?

 

thanks,

-Sriram

 

On Tue, Oct 28, 2014 at 10:28 AM, Clark, Robert Graham <robert.clark at hp.com <mailto:robert.clark at hp.com> > wrote:

[Continuing top posting]

 

Hi All,

 

Thank you for your kind words, I’m looking forward to what the next 6 months will bring!

 

With any luck I’ll see most of you at the summit next week.

 

Kind Regards

-Rob

 

From: Anish [mailto:anish2good at yahoo.co.in <mailto:anish2good at yahoo.co.in> ] 
Sent: 28 October 2014 04:05
To: Michael Xin; Cody Bunch; matt; Bryan D. Payne


Cc: openstack-security at lists.openstack.org <mailto:openstack-security at lists.openstack.org> 
Subject: Re: [Openstack-security] OSSG Lead Election Results

 

Congrats Rob Clark, 

 

With regards

Anish Nath


 


 

 

On Tuesday, 28 October 2014 1:01 AM, Michael Xin <michael.xin at RACKSPACE.COM <mailto:michael.xin at RACKSPACE.COM> > wrote:

 

Rob:

Congratulations!

 

Thanks and have a great day. 

 

Yours,

Michael 

 

-----------------------------------------------------------------------------

Michael Xin | Manager, Security Engineering - US 

Product Security  |Rackspace Hosting

Office #: 501-7341   or  210-312-7341 <tel:210-312-7341> 

Mobile #: 210-284-8674 <tel:210-284-8674>  

5000 Walzem Road, San Antonio, Tx 78218

----------------------------------------------------------------------------

Experience fanatical support

 

 

From: Cody Bunch <cody.bunch at rackspace.com <mailto:cody.bunch at rackspace.com> >
Date: Monday, October 27, 2014 at 2:22 PM
To: matt <matt at nycresistor.com <mailto:matt at nycresistor.com> >, "Bryan D. Payne" <bdpayne at acm.org <mailto:bdpayne at acm.org> >
Cc: "openstack-security at lists.openstack.org <mailto:openstack-security at lists.openstack.org> " <openstack-security at lists.openstack.org <mailto:openstack-security at lists.openstack.org> >
Subject: Re: [Openstack-security] OSSG Lead Election Results

 

Congrats sir!


  _____  


From: matt [matt at nycresistor.com <mailto:matt at nycresistor.com> ]
Sent: Monday, October 27, 2014 2:13 PM
To: Bryan D. Payne
Cc: openstack-security at lists.openstack.org <mailto:openstack-security at lists.openstack.org> 
Subject: Re: [Openstack-security] OSSG Lead Election Results

rob clark is good people.  much love.

 

On Mon, Oct 27, 2014 at 3:06 PM, Bryan D. Payne <bdpayne at acm.org <mailto:bdpayne at acm.org> > wrote:

Please join me in congratulating Rob Clark for being elected to another term as OSSG Lead. Thanks to everyone that voted. 

 

Cheers,

-bryan


_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org <mailto:Openstack-security at lists.openstack.org> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

 

 

_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org <mailto:Openstack-security at lists.openstack.org> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

 


_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org <mailto:Openstack-security at lists.openstack.org> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security





 

-- 

Thanks,

-Sriram 

425-610-8465

www.sriramhere.com <http://www.sriramhere.com>  | www.clouddon.com <http://www.clouddon.com> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141028/88808f7f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6187 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141028/88808f7f/attachment.bin>

From Randy_Perryman at Dell.com  Tue Oct 28 19:30:08 2014
From: Randy_Perryman at Dell.com (Randy_Perryman at Dell.com)
Date: Tue, 28 Oct 2014 14:30:08 -0500
Subject: [Openstack-security] OSSG Lead Election Results
In-Reply-To: <A0C170085C37664D93EE1604364858A112522F09@G4W3300.americas.hpqcorp.net>
References: <CAFpPvXBmHntgiXvv-jqVU3XyD_y1un24Ydp2txJ7h6HDKhm3aQ@mail.gmail.com>
 <CAP_sDUFpH6CPijBJp4H6PGHYv18nRAO263h-962_GwE4O07zMw@mail.gmail.com>
 <327FAB32C28C564DAA23CE6D03789DBCC93976E5@ORD1EXD01.RACKSPACE.CORP>
 <D0740790.370CE%michael.xin@rackspace.com>
 <1414469100.41471.YahooMailNeo@web193306.mail.sg3.yahoo.com>
 <A0C170085C37664D93EE1604364858A112522D36@G4W3300.americas.hpqcorp.net>
 <CAP6wb7+s_T9AOdh_QEKHG2qt6H-+fJ2ctAt3gF+_6-YhwzyKeA@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A112522F09@G4W3300.americas.hpqcorp.net>
Message-ID: <FC6A4A6096337446A48E483EA34F2050271AA4117E@AUSX7MCPC102.AMER.DELL.COM>


just say when/where
From: Clark, Robert Graham [mailto:robert.clark at hp.com]
Sent: Tuesday, October 28, 2014 3:05 PM
To: Sriram Subramanian
Cc: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] OSSG Lead Election Results

Yes we are, no idea where yet. I think Tuesday lunchtime may make sense?

-Rob

From: Sriram Subramanian [mailto:sriram at sriramhere.com]
Sent: 28 October 2014 19:04
To: Clark, Robert Graham
Cc: Anish; Michael Xin; Cody Bunch; matt; Bryan D. Payne; openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>
Subject: Re: [Openstack-security] OSSG Lead Election Results

Congrats Rob!

Are we doing our meetup lunch this time too? I am going to be in, would love to join. Who else?

thanks,
-Sriram

On Tue, Oct 28, 2014 at 10:28 AM, Clark, Robert Graham <robert.clark at hp.com<mailto:robert.clark at hp.com>> wrote:
[Continuing top posting]

Hi All,

Thank you for your kind words, I’m looking forward to what the next 6 months will bring!

With any luck I’ll see most of you at the summit next week.

Kind Regards
-Rob

From: Anish [mailto:anish2good at yahoo.co.in<mailto:anish2good at yahoo.co.in>]
Sent: 28 October 2014 04:05
To: Michael Xin; Cody Bunch; matt; Bryan D. Payne

Cc: openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>
Subject: Re: [Openstack-security] OSSG Lead Election Results

Congrats Rob Clark,

With regards
Anish Nath





On Tuesday, 28 October 2014 1:01 AM, Michael Xin <michael.xin at RACKSPACE.COM<mailto:michael.xin at RACKSPACE.COM>> wrote:

Rob:
Congratulations!

Thanks and have a great day.

Yours,
Michael

-----------------------------------------------------------------------------
Michael Xin | Manager, Security Engineering - US
Product Security  |Rackspace Hosting
Office #: 501-7341   or  210-312-7341<tel:210-312-7341>
Mobile #: 210-284-8674<tel:210-284-8674>
5000 Walzem Road, San Antonio, Tx 78218
----------------------------------------------------------------------------
Experience fanatical support


From: Cody Bunch <cody.bunch at rackspace.com<mailto:cody.bunch at rackspace.com>>
Date: Monday, October 27, 2014 at 2:22 PM
To: matt <matt at nycresistor.com<mailto:matt at nycresistor.com>>, "Bryan D. Payne" <bdpayne at acm.org<mailto:bdpayne at acm.org>>
Cc: "openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>" <openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>>
Subject: Re: [Openstack-security] OSSG Lead Election Results

Congrats sir!
________________________________
From: matt [matt at nycresistor.com<mailto:matt at nycresistor.com>]
Sent: Monday, October 27, 2014 2:13 PM
To: Bryan D. Payne
Cc: openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>
Subject: Re: [Openstack-security] OSSG Lead Election Results
rob clark is good people.  much love.

On Mon, Oct 27, 2014 at 3:06 PM, Bryan D. Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>> wrote:
Please join me in congratulating Rob Clark for being elected to another term as OSSG Lead. Thanks to everyone that voted.

Cheers,
-bryan

_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security


_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security


_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security



--
Thanks,
-Sriram
425-610-8465
www.sriramhere.com<http://www.sriramhere.com> | www.clouddon.com<http://www.clouddon.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141028/30a9449d/attachment.html>

From thingee at gmail.com  Wed Oct 29 15:53:01 2014
From: thingee at gmail.com (Mike Perez)
Date: Wed, 29 Oct 2014 15:53:01 -0000
Subject: [Openstack-security] [Bug 1372643] Re: MITM vulnerability with XIV
	driver
References: <20140922204545.32411.9337.malonedeb@gac.canonical.com>
Message-ID: <20141029155304.25770.41158.launchpad@chaenomeles.canonical.com>

** Changed in: cinder
    Milestone: kilo-1 => None

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

Title:
  MITM vulnerability with XIV driver

Status in Cinder:
  Invalid
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The XIV driver in Juno appears to blindly trust whatever certificate
  it gets back from the device without any validation. This would leave
  it open to a MITM attack.

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



From sriram at sriramhere.com  Wed Oct 29 16:47:11 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Wed, 29 Oct 2014 09:47:11 -0700
Subject: [Openstack-security] OSSG Lead Election Results
In-Reply-To: <FC6A4A6096337446A48E483EA34F2050271AA4117E@AUSX7MCPC102.AMER.DELL.COM>
References: <CAFpPvXBmHntgiXvv-jqVU3XyD_y1un24Ydp2txJ7h6HDKhm3aQ@mail.gmail.com>
 <CAP_sDUFpH6CPijBJp4H6PGHYv18nRAO263h-962_GwE4O07zMw@mail.gmail.com>
 <327FAB32C28C564DAA23CE6D03789DBCC93976E5@ORD1EXD01.RACKSPACE.CORP>
 <D0740790.370CE%michael.xin@rackspace.com>
 <1414469100.41471.YahooMailNeo@web193306.mail.sg3.yahoo.com>
 <A0C170085C37664D93EE1604364858A112522D36@G4W3300.americas.hpqcorp.net>
 <CAP6wb7+s_T9AOdh_QEKHG2qt6H-+fJ2ctAt3gF+_6-YhwzyKeA@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A112522F09@G4W3300.americas.hpqcorp.net>
 <FC6A4A6096337446A48E483EA34F2050271AA4117E@AUSX7MCPC102.AMER.DELL.COM>
Message-ID: <CAP6wb7J7_yQrYObVYPScxM8dt2W30-ZKcH2=NsSxLs5=QcDR4g@mail.gmail.com>

+1 for Tuesday.

On Tue, Oct 28, 2014 at 12:30 PM, <Randy_Perryman at dell.com> wrote:

>
>
> just say when/where
>
> *From:* Clark, Robert Graham [mailto:robert.clark at hp.com]
> *Sent:* Tuesday, October 28, 2014 3:05 PM
> *To:* Sriram Subramanian
>
> *Cc:* openstack-security at lists.openstack.org
> *Subject:* Re: [Openstack-security] OSSG Lead Election Results
>
>
>
> Yes we are, no idea where yet. I think Tuesday lunchtime may make sense?
>
>
>
> -Rob
>
>
>
> *From:* Sriram Subramanian [mailto:sriram at sriramhere.com
> <sriram at sriramhere.com>]
> *Sent:* 28 October 2014 19:04
> *To:* Clark, Robert Graham
> *Cc:* Anish; Michael Xin; Cody Bunch; matt; Bryan D. Payne;
> openstack-security at lists.openstack.org
> *Subject:* Re: [Openstack-security] OSSG Lead Election Results
>
>
>
> Congrats Rob!
>
>
>
> Are we doing our meetup lunch this time too? I am going to be in, would
> love to join. Who else?
>
>
>
> thanks,
>
> -Sriram
>
>
>
> On Tue, Oct 28, 2014 at 10:28 AM, Clark, Robert Graham <
> robert.clark at hp.com> wrote:
>
> [Continuing top posting]
>
>
>
> Hi All,
>
>
>
> Thank you for your kind words, I’m looking forward to what the next 6
> months will bring!
>
>
>
> With any luck I’ll see most of you at the summit next week.
>
>
>
> Kind Regards
>
> -Rob
>
>
>
> *From:* Anish [mailto:anish2good at yahoo.co.in]
> *Sent:* 28 October 2014 04:05
> *To:* Michael Xin; Cody Bunch; matt; Bryan D. Payne
>
>
> *Cc:* openstack-security at lists.openstack.org
> *Subject:* Re: [Openstack-security] OSSG Lead Election Results
>
>
>
> Congrats Rob Clark,
>
>
>
> With regards
>
> Anish Nath
>
>
>
>
>
>
>
>
>
> On Tuesday, 28 October 2014 1:01 AM, Michael Xin <
> michael.xin at RACKSPACE.COM> wrote:
>
>
>
> Rob:
>
> Congratulations!
>
>
>
> Thanks and have a great day.
>
>
>
> Yours,
>
> Michael
>
>
>
>
> -----------------------------------------------------------------------------
>
> Michael Xin | Manager, Security Engineering - US
>
> Product Security  |Rackspace Hosting
>
> Office #: 501-7341   or  210-312-7341
>
> Mobile #: 210-284-8674
>
> 5000 Walzem Road, San Antonio, Tx 78218
>
>
> ----------------------------------------------------------------------------
>
> Experience fanatical support
>
>
>
>
>
> *From: *Cody Bunch <cody.bunch at rackspace.com>
> *Date: *Monday, October 27, 2014 at 2:22 PM
> *To: *matt <matt at nycresistor.com>, "Bryan D. Payne" <bdpayne at acm.org>
> *Cc: *"openstack-security at lists.openstack.org" <
> openstack-security at lists.openstack.org>
> *Subject: *Re: [Openstack-security] OSSG Lead Election Results
>
>
>
> Congrats sir!
> ------------------------------
>
> *From:* matt [matt at nycresistor.com]
> *Sent:* Monday, October 27, 2014 2:13 PM
> *To:* Bryan D. Payne
> *Cc:* openstack-security at lists.openstack.org
> *Subject:* Re: [Openstack-security] OSSG Lead Election Results
>
> rob clark is good people.  much love.
>
>
>
> On Mon, Oct 27, 2014 at 3:06 PM, Bryan D. Payne <bdpayne at acm.org> wrote:
>
> Please join me in congratulating Rob Clark for being elected to another
> term as OSSG Lead. Thanks to everyone that voted.
>
>
>
> Cheers,
>
> -bryan
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
>
>
>
> --
>
> Thanks,
>
> -Sriram
>
> 425-610-8465
>
> www.sriramhere.com | www.clouddon.com
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>


-- 
Thanks,
-Sriram
425-610-8465
www.sriramhere.com | www.clouddon.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20141029/3c0df09d/attachment.html>

From gerrit2 at review.openstack.org  Thu Oct 30 01:12:53 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 30 Oct 2014 01:12:53 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie19d093d0494443ce4cd880ae1f92dffd5c361ef
Message-ID: <E1XjeIH-0002eB-On@review.openstack.org>


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

Log:
commit a6848b4667ee4f2ee1e2b6642a7ba36aabefdbd0
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Aug 27 17:53:41 2014 -0500

    token signing support alternative message digest
    
    The functions for creating signed tokens in common.cms always used
    sha256 for the message digest. This might be inadequate in the future
    so the digest algorithm shouldn't be hard-coded. A parameter is added
    to allow choosing a different digest algorithm.
    
    SecurityImpact
    
    Change-Id: Ie19d093d0494443ce4cd880ae1f92dffd5c361ef
    Related-Bug: #1362343




From gerrit2 at review.openstack.org  Thu Oct 30 09:14:41 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 30 Oct 2014 09:14:41 +0000
Subject: [Openstack-security] [openstack/glance] SecurityImpact review
 request change I93aaca24935a4f3096210233097dd6b8c5440176
Message-ID: <E1XjloX-0002kl-1H@review.openstack.org>


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

Log:
commit 1d604a5948ceeed6ce7ff6d2b8dfa186ef80dde6
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Tue Oct 21 04:39:59 2014 -0700

    Eventlet green threads not released back to pool
    
    Presently, the wsgi server allows persist connections. Hence even after
    the response is sent to the client, it doesn't close the client socket
    connection. Because of this problem, the green thread is not released
    back to the pool.
    
    In order to close the client socket connection explicitly after the
    response is sent and read successfully by the client, you simply have to
    set keepalive to False when you create a wsgi server.
    
    DocImpact:
    Added wsgi_keep_alive option (default=True).
    
    SecurityImpact
    
    Closes-Bug: #1361360
    Change-Id: I93aaca24935a4f3096210233097dd6b8c5440176




From 1321080 at bugs.launchpad.net  Thu Oct 30 09:27:17 2014
From: 1321080 at bugs.launchpad.net (Launchpad Bug Tracker)
Date: Thu, 30 Oct 2014 09:27:17 -0000
Subject: [Openstack-security] [Bug 1321080] Re: [OSSA 2014-021] auth token
 is exposed in meter http.request (CVE-2014-4615)
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20141030092718.21374.40605.launchpad@ackee.canonical.com>

** Branch linked: lp:~ubuntu-branches/ubuntu/trusty/ceilometer/trusty-
security

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

Title:
  [OSSA 2014-021] auth token is exposed in meter http.request
  (CVE-2014-4615)

Status in OpenStack Telemetry (Ceilometer):
  Invalid
Status in Ceilometer havana series:
  Fix Released
Status in Ceilometer icehouse series:
  Fix Committed
Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in neutron icehouse series:
  Fix Released
Status in The Oslo library incubator:
  Fix Released
Status in oslo-incubator havana series:
  Fix Committed
Status in oslo-incubator icehouse series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Released
Status in pyCADF:
  Fix Released

Bug description:
  auth token is exposed in meter http.request

  # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd'
  -H 'Content-Type: application/json' -H 'Accept: application/json' -H
  'User-Agent: python-ceilometerclient'
  http://0.0.0.0:8777/v2/meters/http.request

  -----------
  snip..
  {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0",
  snip...

  auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478".
  But it is exposed in  "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478"

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



From gerrit2 at review.openstack.org  Thu Oct 30 10:12:21 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 30 Oct 2014 10:12:21 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change Ic57b2aceb136e8626388cfe4df72b2f47cb0661c
Message-ID: <E1XjmiL-0007Of-TG@review.openstack.org>


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

Log:
commit b57c024bfb5f542e0412f268038f38bf52e06456
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Tue Oct 21 02:31:15 2014 -0700

    Eventlet green threads not released back to pool
    
    Presently, the wsgi server allows persist connections hence even after
    the response is sent to the client, it doesn't close the client socket
    connection.
    Because of this problem, the green thread is not released back to the pool.
    
    In order to close the client socket connection explicitly after the
    response is sent and read successfully by the client, you simply have to
    set keepalive to False when you create a wsgi server.
    
    DocImpact:
    Added wsgi_keep_alive option (default=True).
    In order to maintain the backward compatibility, setting wsgi_keep_alive
    as True by default. Recommended is set it to False.
    
    Conflicts:
            cinder/wsgi.py
            etc/cinder/cinder.conf.sample
    
    SecurityImpact
    
    Closes-Bug: #1361360
    Change-Id: Ic57b2aceb136e8626388cfe4df72b2f47cb0661c
    (cherry picked from commit fc87da7eeb3451e139ee71b31095d0b9093332ce)




From gerrit2 at review.openstack.org  Thu Oct 30 10:54:21 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 30 Oct 2014 10:54:21 +0000
Subject: [Openstack-security] [openstack/neutron] SecurityImpact review
 request change I3a361d6590d1800b85791f23ac1cdfd79815341b
Message-ID: <E1XjnMz-0001m3-6w@review.openstack.org>


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

Log:
commit cd311e78c89b4a0cb39e926a29736f75f40d3d6e
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Tue Oct 21 04:15:15 2014 -0700

    Eventlet green threads not released back to pool
    
    Presently, the wsgi server allows persist connections. Hence even after
    the response is sent to the client, it doesn't close the client socket
    connection. Because of this problem, the green thread is not released
    back to the pool.
    
    In order to close the client socket connection explicitly after the
    response is sent and read successfully by the client, you simply have to
    set keepalive to False when you create a wsgi server.
    
    Added a parameter to take advantage of the new(ish) eventlet socket timeout
    behaviour. Allows closing idle client connections after a period of time, eg:
    
    $ time nc localhost 8776
    real    1m0.063s
    
    Setting 'client_socket_timeout = 0' means do not timeout.
    
    DocImpact:
    Added wsgi_keep_alive option (default=True).
    Added client_socket_timeout option (default=900).
    
    SecurityImpact
    
    Closes-Bug: #1361360
    Change-Id: I3a361d6590d1800b85791f23ac1cdfd79815341b




From gerrit2 at review.openstack.org  Thu Oct 30 12:28:59 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 30 Oct 2014 12:28:59 +0000
Subject: [Openstack-security] [openstack/neutron] SecurityImpact review
 request change I3a361d6590d1800b85791f23ac1cdfd79815341b
Message-ID: <E1XjoqZ-0008Tg-2I@review.openstack.org>


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

Log:
commit 91f27fecf84bd95b41a1e2c15448a02cc23f4dc5
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Tue Oct 21 04:15:15 2014 -0700

    Eventlet green threads not released back to pool
    
    Presently, the wsgi server allows persist connections. Hence even after
    the response is sent to the client, it doesn't close the client socket
    connection. Because of this problem, the green thread is not released
    back to the pool.
    
    In order to close the client socket connection explicitly after the
    response is sent and read successfully by the client, you simply have to
    set keepalive to False when you create a wsgi server.
    
    Added a parameter to take advantage of the new(ish) eventlet socket timeout
    behaviour. Allows closing idle client connections after a period of time, eg:
    
    $ time nc localhost 8776
    real    1m0.063s
    
    Setting 'client_socket_timeout = 0' means do not timeout.
    
    DocImpact:
    Added wsgi_keep_alive option (default=True).
    Added client_socket_timeout option (default=900).
    
    SecurityImpact
    
    Closes-Bug: #1361360
    Change-Id: I3a361d6590d1800b85791f23ac1cdfd79815341b




From 1334926 at bugs.launchpad.net  Thu Oct 30 17:38:38 2014
From: 1334926 at bugs.launchpad.net (Alan Pevec)
Date: Thu, 30 Oct 2014 17:38:38 -0000
Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working
 once connected even after it is disociated
References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com>
Message-ID: <20141030173839.22686.67631.launchpad@wampee.canonical.com>

** Tags removed: in-stable-icehouse

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

Title:
  floatingip still working once connected even after it is disociated

Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in neutron icehouse series:
  Fix Released
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  After we create an SSH connection to a VM via its floating ip, even
  though we have removed the floating ip association, we can still
  access the VM via that connection. Namely, SSH is not disconnected
  when the floating ip is not valid

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



From 1252519 at bugs.launchpad.net  Fri Oct 31 04:12:08 2014
From: 1252519 at bugs.launchpad.net (chrone)
Date: Fri, 31 Oct 2014 04:12:08 -0000
Subject: [Openstack-security] [Bug 1252519] Re: Live migration failed
 because of file permission changed
References: <20131119003108.27374.76789.malonedeb@gac.canonical.com>
Message-ID: <20141031041208.9327.21035.malone@chaenomeles.canonical.com>

I still got this following error when trying to launch an instance under GlusterFS shared storage on latest updated Ubuntu 14.04.1 LTS by changing the user and group and dynamic_ownership as suggested from the above:

"libvirtError: internal error: process exited while connecting to
monitor: qemu-system-x86_64: -chardev
file,id=charserial0,path=/var/lib/nova/instances/3ce9acb6-fcfd-4042
-93ee-372fe2221f4d/console.log: Could not open
'/var/lib/nova/instances/3ce9acb6-fcfd-4042-93ee-
372fe2221f4d/console.log': Permission denied"

"libvirtError: internal error: process exited while connecting to monitor: Could not access KVM kernel module: Permission denied
2014-10-31 04:03:36.246 5008 TRACE nova.compute.manager [instance: 76c0f9bf-d438-4f19-841a-0cc1a8cc3013] failed to initialize KVM: Permission denied"

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

Title:
  Live migration failed because of file permission changed

Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  Openstack : Havana
  OS : CentOS 6.4
  Shared storage with GlusterFS :  /var/lib/nova/instances mounted on glusterfs shared

  
  Instance start up fine on node01.  When live migration happen, it moved to node02 but failed with the following error

  2013-11-18 16:27:37.813 9837 ERROR nova.openstack.common.periodic_task [-] Error during ComputeManager.update_available_resource: Unexpected error while running command.
  Command: env LC_ALL=C LANG=C qemu-img info /var/lib/nova/instances/aa1deb40-ae1d-45e4-a37e-7b0607df372f/disk
  Exit code: 1
  Stdout: ''
  Stderr: "qemu-img: Could not open '/var/lib/nova/instances/aa1deb40-ae1d-45e4-a37e-7b0607df372f/disk'\n"
  2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task Traceback (most recent call last):
  2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task   File "/usr/lib/python2.6/site-packages/nova/openstack/common/periodic_task.py", line 180, in run_periodic_tasks
  2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task     task(self, context)


  The problem is with the file ownership of "console.log" and "disk".
  Those file should be owned by user "qemu" and group "qemu" but after
  the migration, both files are owned by root

  
  drwxr-xr-x 2 nova nova       53 Nov 18 13:40 .
  drwxr-xr-x 6 nova nova      110 Nov 18 13:43 ..
  -rw-rw---- 1 root root     1546 Nov 18 13:43 console.log
  -rw-r--r-- 1 root root 12058624 Nov 18 13:42 disk
  -rw-r--r-- 1 nova nova     1569 Nov 18 13:42 libvirt.xml

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



From mriedem at us.ibm.com  Fri Oct 31 15:28:06 2014
From: mriedem at us.ibm.com (Matt Riedemann)
Date: Fri, 31 Oct 2014 15:28:06 -0000
Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC
	VMAX driver
References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com>
Message-ID: <20141031152806.24858.92733.malone@gac.canonical.com>

Why hasn't anyone reported a bug against pywbem yet?

http://sourceforge.net/p/pywbem/bugs/?source=navbar

Why are we even supporting this library, it's not even global-
requirements:

https://github.com/openstack/requirements/blob/master/global-
requirements.txt

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

Title:
  MITM vulnerability with EMC VMAX driver

Status in Cinder:
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The EMC VMAX driver in Juno appears to blindly trust whatever
  certificate it gets back from the device without any validation (it
  does not specify the ca_certs parameter, etc. on
  WBEMConnection.__init__). This would leave it open to a MITM attack.

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



From edmondsw at us.ibm.com  Fri Oct 31 15:30:40 2014
From: edmondsw at us.ibm.com (Matthew Edmonds)
Date: Fri, 31 Oct 2014 15:30:40 -0000
Subject: [Openstack-security] [Bug 1376915] Re: Access to sensitive audit
 data is not properly restricted
References: <20141002203501.17647.70947.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141031153042.25341.23207.launchpad@gac.canonical.com>

** Summary changed:

- Ceilometer policy file settings ignored
+ Access to sensitive audit data is not properly restricted

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

Title:
  Access to sensitive audit data is not properly restricted

Status in OpenStack Telemetry (Ceilometer):
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Configuring the ceilometer policy.json file to restrict certain
  actions has no effect whatsoever. This allows all users access to
  sensitive information, such as audit data stored in the http.request
  meter.

  E.g. policy.json file:

  {
      "adm":  "role:admin",

      "default": "!",

      "meter:get_all": "rule:adm",
      "meters:get_all": "rule:adm"
  }

  With the above policy, tokens for users without the admin role are
  still able to access meters, and any token still works for alarms
  despite the default supposedly being to disallow for everyone.

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



From edmondsw at us.ibm.com  Fri Oct 31 15:57:41 2014
From: edmondsw at us.ibm.com (Matthew Edmonds)
Date: Fri, 31 Oct 2014 15:57:41 -0000
Subject: [Openstack-security] [Bug 1376915] Re: Access to sensitive audit
 data is not properly restricted
References: <20141002203501.17647.70947.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141031155741.24885.9192.launchpad@gac.canonical.com>

** Description changed:

- Configuring the ceilometer policy.json file to restrict certain actions
- has no effect whatsoever. This allows all users access to sensitive
- information, such as audit data stored in the http.request meter.
+ Audit data stored in http.request and http.response meters is not being
+ adequately protected. Admins are allowed to access audit data for all
+ projects rather than just their own. Non-admins are allowed to access
+ audit data for all users within their project rather than just
+ themselves. A non-admin user should not be able to see what other users
+ are doing, and being an admin in project A does not make you an admin in
+ project B.
  
- E.g. policy.json file:
+ The following blueprints acknowledge the lack of this support. To quote
+ one: "as ceilometer collects more and more different types of data...
+ some of the data collected may be 'privileged' data that only admins
+ should have access to regardless of membership to a tenant (ie. audit
+ data should only be visible to admins)". That day has come, and the
+ implementation of these blueprints is still missing. At this point there
+ is a security hole here (data exposure) which needs to be plugged
+ immediately, either with the implementation of one of these blueprints
+ (which should probably be merged together) or by a less flexible but
+ more easily implemented stopgap measure. Given time constraints and the
+ urgency of closing this hole, I propose the latter, though the
+ blueprints will obviously still be necessary for a more robust and
+ complete solution.
  
- {
-     "adm":  "role:admin",
- 
-     "default": "!",
- 
-     "meter:get_all": "rule:adm",
-     "meters:get_all": "rule:adm"
- }
- 
- With the above policy, tokens for users without the admin role are still
- able to access meters, and any token still works for alarms despite the
- default supposedly being to disallow for everyone.
+ https://blueprints.launchpad.net/ceilometer/+spec/advanced-policy-rule
+ and https://blueprints.launchpad.net/ceilometer/+spec/admin-only-api-
+ access and https://blueprints.launchpad.net/ceilometer/+spec/ready-
+ ceilometer-rbac-keystone-v3

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

Title:
  Access to sensitive audit data is not properly restricted

Status in OpenStack Telemetry (Ceilometer):
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Audit data stored in http.request and http.response meters is not
  being adequately protected. Admins are allowed to access audit data
  for all projects rather than just their own. Non-admins are allowed to
  access audit data for all users within their project rather than just
  themselves. A non-admin user should not be able to see what other
  users are doing, and being an admin in project A does not make you an
  admin in project B.

  The following blueprints acknowledge the lack of this support. To
  quote one: "as ceilometer collects more and more different types of
  data... some of the data collected may be 'privileged' data that only
  admins should have access to regardless of membership to a tenant (ie.
  audit data should only be visible to admins)". That day has come, and
  the implementation of these blueprints is still missing. At this point
  there is a security hole here (data exposure) which needs to be
  plugged immediately, either with the implementation of one of these
  blueprints (which should probably be merged together) or by a less
  flexible but more easily implemented stopgap measure. Given time
  constraints and the urgency of closing this hole, I propose the
  latter, though the blueprints will obviously still be necessary for a
  more robust and complete solution.

  https://blueprints.launchpad.net/ceilometer/+spec/advanced-policy-rule
  and https://blueprints.launchpad.net/ceilometer/+spec/admin-only-api-
  access and https://blueprints.launchpad.net/ceilometer/+spec/ready-
  ceilometer-rbac-keystone-v3

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



From 1384626 at bugs.launchpad.net  Thu Oct 23 11:59:44 2014
From: 1384626 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 23 Oct 2014 11:59:44 -0000
Subject: [Openstack-security] [Bug 1384626] Re: SSL certification
 verification failed when Heat calls Glanceclient with ca cert
References: <20141023090711.3131.60470.malonedeb@wampee.canonical.com>
Message-ID: <20141023115944.8259.12791.malone@chaenomeles.canonical.com>

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

** Changed in: heat
       Status: New => In Progress

** Changed in: heat
     Assignee: (unassigned) => zhu zhu  (zhuzhubj)

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

Title:
  SSL certification verification failed when Heat calls Glanceclient
  with ca cert

Status in Orchestration API (Heat):
  In Progress

Bug description:
  Glance server is configured Https.

  Configured Heat with heat.conf 
  [clients_glance]
  ca_file=<ca file path>
  insecure=<false>

  When trying to create stack, heat will raise exception during heat to load image data.
  [Errno 1] _ssl.c:492: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

  The root cause is that: ca_file as below is a wrong argument to
  initialize the glance client,  it should be cacert which is supported
  arguments by glanceclient.

  class GlanceClientPlugin(client_plugin.ClientPlugin):

      exceptions_module = exc

      def _create(self):

          con = self.context
          endpoint_type = self._get_client_option('glance', 'endpoint_type')
          endpoint = self.url_for(service_type='image',
                                  endpoint_type=endpoint_type)
          args = {
              'auth_url': con.auth_url,
              'service_type': 'image',
              'project_id': con.tenant,
              'token': self.auth_token,
              'endpoint_type': endpoint_type,
              'ca_file': self._get_client_option('glance', 'ca_file'),
              'cert_file': self._get_client_option('glance', 'cert_file'),
              'key_file': self._get_client_option('glance', 'key_file'),
              'insecure': self._get_client_option('glance', 'insecure')

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



From 1384626 at bugs.launchpad.net  Fri Oct 24 01:07:54 2014
From: 1384626 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 24 Oct 2014 01:07:54 -0000
Subject: [Openstack-security] [Bug 1384626] Re: SSL certification
 verification failed when Heat calls Glanceclient with ca cert
References: <20141023090711.3131.60470.malonedeb@wampee.canonical.com>
Message-ID: <20141024010754.2703.73176.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/130512
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=fa7fd9d9882baf028efe0807840a4a8180cc9b9c
Submitter: Jenkins
Branch:    master

commit fa7fd9d9882baf028efe0807840a4a8180cc9b9c
Author: ZHU ZHU <zhuzhubj at cn.ibm.com>
Date:   Thu Oct 23 06:45:38 2014 -0500

    Correct CA cert argument for glanceclient
    
    Heat need to pass the CA cert to glanceclient to load image data
    during stack creation when glance api is configured with SSL.
    Currently the client is passing the wrong cert key to glanceclient.
    The key should be 'cacert' instead of 'ca_file'.
    
    Change-Id: Ie542dda1354776e62507240c917c1cffbc222f17
    Closes-Bug: #1384626


** Changed in: heat
       Status: In Progress => Fix Committed

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

Title:
  SSL certification verification failed when Heat calls Glanceclient
  with ca cert

Status in Orchestration API (Heat):
  Fix Committed

Bug description:
  Glance server is configured Https.

  Configured Heat with heat.conf 
  [clients_glance]
  ca_file=<ca file path>
  insecure=<false>

  When trying to create stack, heat will raise exception during heat to load image data.
  [Errno 1] _ssl.c:492: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

  The root cause is that: ca_file as below is a wrong argument to
  initialize the glance client,  it should be cacert which is supported
  arguments by glanceclient.

  class GlanceClientPlugin(client_plugin.ClientPlugin):

      exceptions_module = exc

      def _create(self):

          con = self.context
          endpoint_type = self._get_client_option('glance', 'endpoint_type')
          endpoint = self.url_for(service_type='image',
                                  endpoint_type=endpoint_type)
          args = {
              'auth_url': con.auth_url,
              'service_type': 'image',
              'project_id': con.tenant,
              'token': self.auth_token,
              'endpoint_type': endpoint_type,
              'ca_file': self._get_client_option('glance', 'ca_file'),
              'cert_file': self._get_client_option('glance', 'cert_file'),
              'key_file': self._get_client_option('glance', 'key_file'),
              'insecure': self._get_client_option('glance', 'insecure')

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



From 1384626 at bugs.launchpad.net  Fri Oct 24 01:37:55 2014
From: 1384626 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 24 Oct 2014 01:37:55 -0000
Subject: [Openstack-security] [Bug 1384626] Fix proposed to heat
	(stable/juno)
References: <20141023090711.3131.60470.malonedeb@wampee.canonical.com>
Message-ID: <20141024013755.2769.2832.malone@gac.canonical.com>

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/130668

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

Title:
  SSL certification verification failed when Heat calls Glanceclient
  with ca cert

Status in Orchestration API (Heat):
  Fix Committed

Bug description:
  Glance server is configured Https.

  Configured Heat with heat.conf 
  [clients_glance]
  ca_file=<ca file path>
  insecure=<false>

  When trying to create stack, heat will raise exception during heat to load image data.
  [Errno 1] _ssl.c:492: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

  The root cause is that: ca_file as below is a wrong argument to
  initialize the glance client,  it should be cacert which is supported
  arguments by glanceclient.

  class GlanceClientPlugin(client_plugin.ClientPlugin):

      exceptions_module = exc

      def _create(self):

          con = self.context
          endpoint_type = self._get_client_option('glance', 'endpoint_type')
          endpoint = self.url_for(service_type='image',
                                  endpoint_type=endpoint_type)
          args = {
              'auth_url': con.auth_url,
              'service_type': 'image',
              'project_id': con.tenant,
              'token': self.auth_token,
              'endpoint_type': endpoint_type,
              'ca_file': self._get_client_option('glance', 'ca_file'),
              'cert_file': self._get_client_option('glance', 'cert_file'),
              'key_file': self._get_client_option('glance', 'key_file'),
              'insecure': self._get_client_option('glance', 'insecure')

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



From 1361360 at bugs.launchpad.net  Fri Oct 24 14:30:23 2014
From: 1361360 at bugs.launchpad.net (John Griffith)
Date: Fri, 24 Oct 2014 14:30:23 -0000
Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not
 released back to the pool leading to choking of new requests
References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com>
Message-ID: <20141024143027.3479.37952.launchpad@wampee.canonical.com>

** Changed in: cinder
   Importance: Undecided => High

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

Title:
  Eventlet green threads not released back to the pool leading to
  choking of new requests

Status in Cinder:
  In Progress
Status in Cinder icehouse series:
  New
Status in OpenStack Image Registry and Delivery Service (Glance):
  In Progress
Status in Glance icehouse series:
  New
Status in OpenStack Identity (Keystone):
  In Progress
Status in Keystone icehouse series:
  New
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in neutron icehouse series:
  New
Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Compute (nova) icehouse series:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Currently reproduced  on Juno milestone 2. but this issue should be
  reproducible in all releases since its inception.

  It is possible to choke OpenStack API controller services using
  wsgi+eventlet library by simply not closing the client socket
  connection. Whenever a request is received by any OpenStack API
  service for example nova api service, eventlet library creates a green
  thread from the pool and starts processing the request. Even after the
  response is sent to the caller, the green thread is not returned back
  to the pool until the client socket connection is closed. This way,
  any malicious user can send many API requests to the API controller
  node and determine the wsgi pool size configured for the given service
  and then send those many requests to the service and after receiving
  the response, wait there infinitely doing nothing leading to
  disrupting services for other tenants. Even when service providers
  have enabled rate limiting feature, it is possible to choke the API
  services with a group (many tenants) attack.

  Following program illustrates choking of nova-api services (but this
  problem is omnipresent in all other OpenStack API Services using
  wsgi+eventlet)

  Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py.
  After you run the below program, you should try to invoke API
  ============================================================================================
  import time
  import requests
  from multiprocessing import Process

  def request(number):
     #Port is important here
     path = 'http://127.0.0.1:8774/servers'
      try:
          response = requests.get(path)
          print "RESPONSE %s-%d" % (response.status_code, number)
          #during this sleep time, check if the client socket connection is released or not on the API controller node.
          time.sleep(1000)
          print “Thread %d complete" % number
      except requests.exceptions.RequestException as ex:
          print “Exception occurred %d-%s" % (number, str(ex))

  if __name__ == '__main__':
      processes = []
      for number in range(40):
          p = Process(target=request, args=(number,))
          p.start()
          processes.append(p)
      for p in processes:
          p.join()

  ================================================================================================

  Presently, the wsgi server allows persist connections if you configure keepalive to True which is default.
  In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server.

  Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter.
  For example.
  Keep-Alive: timeout=10, max=5

  Note: After we have disabled keepalive in all the OpenStack API
  service using wsgi library, then it might impact all existing
  applications built with the assumptions that OpenStack API services
  uses persistent connections. They might need to modify their
  applications if reconnection logic is not in place and also they might
  experience the performance has slowed down as it will need to
  reestablish the http connection for every request.

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



From 1361360 at bugs.launchpad.net  Fri Oct 24 15:17:48 2014
From: 1361360 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 24 Oct 2014 15:17:48 -0000
Subject: [Openstack-security] [Bug 1361360] Fix proposed to cinder (master)
References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com>
Message-ID: <20141024151748.3724.4429.malone@wampee.canonical.com>

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

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

Title:
  Eventlet green threads not released back to the pool leading to
  choking of new requests

Status in Cinder:
  In Progress
Status in Cinder icehouse series:
  New
Status in OpenStack Image Registry and Delivery Service (Glance):
  In Progress
Status in Glance icehouse series:
  New
Status in OpenStack Identity (Keystone):
  In Progress
Status in Keystone icehouse series:
  New
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in neutron icehouse series:
  New
Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Compute (nova) icehouse series:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Currently reproduced  on Juno milestone 2. but this issue should be
  reproducible in all releases since its inception.

  It is possible to choke OpenStack API controller services using
  wsgi+eventlet library by simply not closing the client socket
  connection. Whenever a request is received by any OpenStack API
  service for example nova api service, eventlet library creates a green
  thread from the pool and starts processing the request. Even after the
  response is sent to the caller, the green thread is not returned back
  to the pool until the client socket connection is closed. This way,
  any malicious user can send many API requests to the API controller
  node and determine the wsgi pool size configured for the given service
  and then send those many requests to the service and after receiving
  the response, wait there infinitely doing nothing leading to
  disrupting services for other tenants. Even when service providers
  have enabled rate limiting feature, it is possible to choke the API
  services with a group (many tenants) attack.

  Following program illustrates choking of nova-api services (but this
  problem is omnipresent in all other OpenStack API Services using
  wsgi+eventlet)

  Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py.
  After you run the below program, you should try to invoke API
  ============================================================================================
  import time
  import requests
  from multiprocessing import Process

  def request(number):
     #Port is important here
     path = 'http://127.0.0.1:8774/servers'
      try:
          response = requests.get(path)
          print "RESPONSE %s-%d" % (response.status_code, number)
          #during this sleep time, check if the client socket connection is released or not on the API controller node.
          time.sleep(1000)
          print “Thread %d complete" % number
      except requests.exceptions.RequestException as ex:
          print “Exception occurred %d-%s" % (number, str(ex))

  if __name__ == '__main__':
      processes = []
      for number in range(40):
          p = Process(target=request, args=(number,))
          p.start()
          processes.append(p)
      for p in processes:
          p.join()

  ================================================================================================

  Presently, the wsgi server allows persist connections if you configure keepalive to True which is default.
  In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server.

  Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter.
  For example.
  Keep-Alive: timeout=10, max=5

  Note: After we have disabled keepalive in all the OpenStack API
  service using wsgi library, then it might impact all existing
  applications built with the assumptions that OpenStack API services
  uses persistent connections. They might need to modify their
  applications if reconnection logic is not in place and also they might
  experience the performance has slowed down as it will need to
  reestablish the http connection for every request.

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



From 1361360 at bugs.launchpad.net  Fri Oct 24 15:24:32 2014
From: 1361360 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 24 Oct 2014 15:24:32 -0000
Subject: [Openstack-security] [Bug 1361360] Fix proposed to keystone (master)
References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com>
Message-ID: <20141024152432.3158.92611.malone@wampee.canonical.com>

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

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

Title:
  Eventlet green threads not released back to the pool leading to
  choking of new requests

Status in Cinder:
  In Progress
Status in Cinder icehouse series:
  New
Status in OpenStack Image Registry and Delivery Service (Glance):
  In Progress
Status in Glance icehouse series:
  New
Status in OpenStack Identity (Keystone):
  In Progress
Status in Keystone icehouse series:
  New
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in neutron icehouse series:
  New
Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Compute (nova) icehouse series:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Currently reproduced  on Juno milestone 2. but this issue should be
  reproducible in all releases since its inception.

  It is possible to choke OpenStack API controller services using
  wsgi+eventlet library by simply not closing the client socket
  connection. Whenever a request is received by any OpenStack API
  service for example nova api service, eventlet library creates a green
  thread from the pool and starts processing the request. Even after the
  response is sent to the caller, the green thread is not returned back
  to the pool until the client socket connection is closed. This way,
  any malicious user can send many API requests to the API controller
  node and determine the wsgi pool size configured for the given service
  and then send those many requests to the service and after receiving
  the response, wait there infinitely doing nothing leading to
  disrupting services for other tenants. Even when service providers
  have enabled rate limiting feature, it is possible to choke the API
  services with a group (many tenants) attack.

  Following program illustrates choking of nova-api services (but this
  problem is omnipresent in all other OpenStack API Services using
  wsgi+eventlet)

  Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py.
  After you run the below program, you should try to invoke API
  ============================================================================================
  import time
  import requests
  from multiprocessing import Process

  def request(number):
     #Port is important here
     path = 'http://127.0.0.1:8774/servers'
      try:
          response = requests.get(path)
          print "RESPONSE %s-%d" % (response.status_code, number)
          #during this sleep time, check if the client socket connection is released or not on the API controller node.
          time.sleep(1000)
          print “Thread %d complete" % number
      except requests.exceptions.RequestException as ex:
          print “Exception occurred %d-%s" % (number, str(ex))

  if __name__ == '__main__':
      processes = []
      for number in range(40):
          p = Process(target=request, args=(number,))
          p.start()
          processes.append(p)
      for p in processes:
          p.join()

  ================================================================================================

  Presently, the wsgi server allows persist connections if you configure keepalive to True which is default.
  In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server.

  Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter.
  For example.
  Keep-Alive: timeout=10, max=5

  Note: After we have disabled keepalive in all the OpenStack API
  service using wsgi library, then it might impact all existing
  applications built with the assumptions that OpenStack API services
  uses persistent connections. They might need to modify their
  applications if reconnection logic is not in place and also they might
  experience the performance has slowed down as it will need to
  reestablish the http connection for every request.

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



From 1361360 at bugs.launchpad.net  Fri Oct 24 15:48:37 2014
From: 1361360 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 24 Oct 2014 15:48:37 -0000
Subject: [Openstack-security] [Bug 1361360] Fix proposed to neutron (master)
References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com>
Message-ID: <20141024154837.4183.65264.malone@soybean.canonical.com>

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

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

Title:
  Eventlet green threads not released back to the pool leading to
  choking of new requests

Status in Cinder:
  In Progress
Status in Cinder icehouse series:
  New
Status in OpenStack Image Registry and Delivery Service (Glance):
  In Progress
Status in Glance icehouse series:
  New
Status in OpenStack Identity (Keystone):
  In Progress
Status in Keystone icehouse series:
  New
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in neutron icehouse series:
  New
Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Compute (nova) icehouse series:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Currently reproduced  on Juno milestone 2. but this issue should be
  reproducible in all releases since its inception.

  It is possible to choke OpenStack API controller services using
  wsgi+eventlet library by simply not closing the client socket
  connection. Whenever a request is received by any OpenStack API
  service for example nova api service, eventlet library creates a green
  thread from the pool and starts processing the request. Even after the
  response is sent to the caller, the green thread is not returned back
  to the pool until the client socket connection is closed. This way,
  any malicious user can send many API requests to the API controller
  node and determine the wsgi pool size configured for the given service
  and then send those many requests to the service and after receiving
  the response, wait there infinitely doing nothing leading to
  disrupting services for other tenants. Even when service providers
  have enabled rate limiting feature, it is possible to choke the API
  services with a group (many tenants) attack.

  Following program illustrates choking of nova-api services (but this
  problem is omnipresent in all other OpenStack API Services using
  wsgi+eventlet)

  Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py.
  After you run the below program, you should try to invoke API
  ============================================================================================
  import time
  import requests
  from multiprocessing import Process

  def request(number):
     #Port is important here
     path = 'http://127.0.0.1:8774/servers'
      try:
          response = requests.get(path)
          print "RESPONSE %s-%d" % (response.status_code, number)
          #during this sleep time, check if the client socket connection is released or not on the API controller node.
          time.sleep(1000)
          print “Thread %d complete" % number
      except requests.exceptions.RequestException as ex:
          print “Exception occurred %d-%s" % (number, str(ex))

  if __name__ == '__main__':
      processes = []
      for number in range(40):
          p = Process(target=request, args=(number,))
          p.start()
          processes.append(p)
      for p in processes:
          p.join()

  ================================================================================================

  Presently, the wsgi server allows persist connections if you configure keepalive to True which is default.
  In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server.

  Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter.
  For example.
  Keep-Alive: timeout=10, max=5

  Note: After we have disabled keepalive in all the OpenStack API
  service using wsgi library, then it might impact all existing
  applications built with the assumptions that OpenStack API services
  uses persistent connections. They might need to modify their
  applications if reconnection logic is not in place and also they might
  experience the performance has slowed down as it will need to
  reestablish the http connection for every request.

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



From 1361360 at bugs.launchpad.net  Fri Oct 24 15:59:20 2014
From: 1361360 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 24 Oct 2014 15:59:20 -0000
Subject: [Openstack-security] [Bug 1361360] Fix proposed to glance (master)
References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com>
Message-ID: <20141024155920.2670.7603.malone@gac.canonical.com>

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

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

Title:
  Eventlet green threads not released back to the pool leading to
  choking of new requests

Status in Cinder:
  In Progress
Status in Cinder icehouse series:
  New
Status in OpenStack Image Registry and Delivery Service (Glance):
  In Progress
Status in Glance icehouse series:
  New
Status in OpenStack Identity (Keystone):
  In Progress
Status in Keystone icehouse series:
  New
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in neutron icehouse series:
  New
Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Compute (nova) icehouse series:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Currently reproduced  on Juno milestone 2. but this issue should be
  reproducible in all releases since its inception.

  It is possible to choke OpenStack API controller services using
  wsgi+eventlet library by simply not closing the client socket
  connection. Whenever a request is received by any OpenStack API
  service for example nova api service, eventlet library creates a green
  thread from the pool and starts processing the request. Even after the
  response is sent to the caller, the green thread is not returned back
  to the pool until the client socket connection is closed. This way,
  any malicious user can send many API requests to the API controller
  node and determine the wsgi pool size configured for the given service
  and then send those many requests to the service and after receiving
  the response, wait there infinitely doing nothing leading to
  disrupting services for other tenants. Even when service providers
  have enabled rate limiting feature, it is possible to choke the API
  services with a group (many tenants) attack.

  Following program illustrates choking of nova-api services (but this
  problem is omnipresent in all other OpenStack API Services using
  wsgi+eventlet)

  Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py.
  After you run the below program, you should try to invoke API
  ============================================================================================
  import time
  import requests
  from multiprocessing import Process

  def request(number):
     #Port is important here
     path = 'http://127.0.0.1:8774/servers'
      try:
          response = requests.get(path)
          print "RESPONSE %s-%d" % (response.status_code, number)
          #during this sleep time, check if the client socket connection is released or not on the API controller node.
          time.sleep(1000)
          print “Thread %d complete" % number
      except requests.exceptions.RequestException as ex:
          print “Exception occurred %d-%s" % (number, str(ex))

  if __name__ == '__main__':
      processes = []
      for number in range(40):
          p = Process(target=request, args=(number,))
          p.start()
          processes.append(p)
      for p in processes:
          p.join()

  ================================================================================================

  Presently, the wsgi server allows persist connections if you configure keepalive to True which is default.
  In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server.

  Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter.
  For example.
  Keep-Alive: timeout=10, max=5

  Note: After we have disabled keepalive in all the OpenStack API
  service using wsgi library, then it might impact all existing
  applications built with the assumptions that OpenStack API services
  uses persistent connections. They might need to modify their
  applications if reconnection logic is not in place and also they might
  experience the performance has slowed down as it will need to
  reestablish the http connection for every request.

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



From 1361360 at bugs.launchpad.net  Fri Oct 24 16:18:35 2014
From: 1361360 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 24 Oct 2014 16:18:35 -0000
Subject: [Openstack-security] [Bug 1361360] Fix proposed to nova (master)
References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com>
Message-ID: <20141024161835.2112.51937.malone@gac.canonical.com>

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

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

Title:
  Eventlet green threads not released back to the pool leading to
  choking of new requests

Status in Cinder:
  In Progress
Status in Cinder icehouse series:
  New
Status in OpenStack Image Registry and Delivery Service (Glance):
  In Progress
Status in Glance icehouse series:
  New
Status in OpenStack Identity (Keystone):
  In Progress
Status in Keystone icehouse series:
  New
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in neutron icehouse series:
  New
Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Compute (nova) icehouse series:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Currently reproduced  on Juno milestone 2. but this issue should be
  reproducible in all releases since its inception.

  It is possible to choke OpenStack API controller services using
  wsgi+eventlet library by simply not closing the client socket
  connection. Whenever a request is received by any OpenStack API
  service for example nova api service, eventlet library creates a green
  thread from the pool and starts processing the request. Even after the
  response is sent to the caller, the green thread is not returned back
  to the pool until the client socket connection is closed. This way,
  any malicious user can send many API requests to the API controller
  node and determine the wsgi pool size configured for the given service
  and then send those many requests to the service and after receiving
  the response, wait there infinitely doing nothing leading to
  disrupting services for other tenants. Even when service providers
  have enabled rate limiting feature, it is possible to choke the API
  services with a group (many tenants) attack.

  Following program illustrates choking of nova-api services (but this
  problem is omnipresent in all other OpenStack API Services using
  wsgi+eventlet)

  Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py.
  After you run the below program, you should try to invoke API
  ============================================================================================
  import time
  import requests
  from multiprocessing import Process

  def request(number):
     #Port is important here
     path = 'http://127.0.0.1:8774/servers'
      try:
          response = requests.get(path)
          print "RESPONSE %s-%d" % (response.status_code, number)
          #during this sleep time, check if the client socket connection is released or not on the API controller node.
          time.sleep(1000)
          print “Thread %d complete" % number
      except requests.exceptions.RequestException as ex:
          print “Exception occurred %d-%s" % (number, str(ex))

  if __name__ == '__main__':
      processes = []
      for number in range(40):
          p = Process(target=request, args=(number,))
          p.start()
          processes.append(p)
      for p in processes:
          p.join()

  ================================================================================================

  Presently, the wsgi server allows persist connections if you configure keepalive to True which is default.
  In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server.

  Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter.
  For example.
  Keep-Alive: timeout=10, max=5

  Note: After we have disabled keepalive in all the OpenStack API
  service using wsgi library, then it might impact all existing
  applications built with the assumptions that OpenStack API services
  uses persistent connections. They might need to modify their
  applications if reconnection logic is not in place and also they might
  experience the performance has slowed down as it will need to
  reestablish the http connection for every request.

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



From 1376915 at bugs.launchpad.net  Fri Oct 24 16:49:10 2014
From: 1376915 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 24 Oct 2014 16:49:10 -0000
Subject: [Openstack-security] [Bug 1376915] Related fix proposed to
	ceilometer (master)
References: <20141002203501.17647.70947.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141024164910.7752.54151.malone@chaenomeles.canonical.com>

Related fix proposed to branch: master
Review: https://review.openstack.org/130854

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

Title:
  Ceilometer policy file settings ignored

Status in OpenStack Telemetry (Ceilometer):
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Configuring the ceilometer policy.json file to restrict certain
  actions has no effect whatsoever. This allows all users access to
  sensitive information, such as audit data stored in the http.request
  meter.

  E.g. policy.json file:

  {
      "adm":  "role:admin",

      "default": "!",

      "meter:get_all": "rule:adm",
      "meters:get_all": "rule:adm"
  }

  With the above policy, tokens for users without the admin role are
  still able to access meters, and any token still works for alarms
  despite the default supposedly being to disallow for everyone.

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



From 1334926 at bugs.launchpad.net  Fri Oct 24 22:24:54 2014
From: 1334926 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 24 Oct 2014 22:24:54 -0000
Subject: [Openstack-security] [Bug 1334926] Fix merged to neutron
	(feature/lbaasv2)
References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com>
Message-ID: <20141024222454.3257.57678.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/130864
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=c089154a94e5872efc95eab33d3d0c9de8619fe4
Submitter: Jenkins
Branch:    feature/lbaasv2

commit 62588957fbeccfb4f80eaa72bef2b86b6f08dcf8
Author: Kevin Benton <blak111 at gmail.com>
Date:   Wed Oct 22 13:04:03 2014 -0700

    Big Switch: Switch to TLSv1 in server manager
    
    Switch to TLSv1 for the connections to the backend
    controllers. The default SSLv3 is no longer considered
    secure.
    
    TLSv1 was chosen over .1 or .2 because the .1 and .2 weren't
    added until python 2.7.9 so TLSv1 is the only compatible option
    for py26.
    
    Closes-Bug: #1384487
    Change-Id: I68bd72fc4d90a102003d9ce48c47a4a6a3dd6e03

commit 17204e8f02fdad046dabdb8b31397289d72c877b
Author: OpenStack Proposal Bot <openstack-infra at lists.openstack.org>
Date:   Wed Oct 22 06:20:15 2014 +0000

    Imported Translations from Transifex
    
    For more information about this automatic import see:
    https://wiki.openstack.org/wiki/Translations/Infrastructure
    
    Change-Id: I58db0476c810aa901463b07c42182eef0adb5114

commit d712663b99520e6d26269b0ca193527603178742
Author: Carl Baldwin <carl.baldwin at hp.com>
Date:   Mon Oct 20 21:48:42 2014 +0000

    Move disabling of metadata and ipv6_ra to _destroy_router_namespace
    
    I noticed that disable_ipv6_ra is called from the wrong place and that
    in some cases it was called with a bogus router_id because the code
    made an incorrect assumption about the context.  In other case, it was
    never called because _destroy_router_namespace was being called
    directly.  This patch moves the disabling of metadata and ipv6_ra in
    to _destroy_router_namespace to ensure they get called correctly and
    avoid duplication.
    
    Change-Id: Ia76a5ff4200df072b60481f2ee49286b78ece6c4
    Closes-Bug: #1383495

commit f82a5117f6f484a649eadff4b0e6be9a5a4d18bb
Author: OpenStack Proposal Bot <openstack-infra at lists.openstack.org>
Date:   Tue Oct 21 12:11:19 2014 +0000

    Updated from global requirements
    
    Change-Id: Idcbd730f5c781d21ea75e7bfb15959c8f517980f

commit be6bd82d43fbcb8d1512d8eb5b7a106332364c31
Author: Angus Lees <gus at inodes.org>
Date:   Mon Aug 25 12:14:29 2014 +1000

    Remove duplicate import of constants module
    
    .. and enable corresponding pylint check now the only offending instance
    is fixed.
    
    Change-Id: I35a12ace46c872446b8c87d0aacce45e94d71bae

commit 9902400039018d77aa3034147cfb24ca4b2353f6
Author: rajeev <rajeev.grover at hp.com>
Date:   Mon Oct 13 16:25:36 2014 -0400

    Fix race condition on processing DVR floating IPs
    
    Fip namespace and agent gateway port can be shared by multiple dvr routers.
    This change uses a set as the control variable for these shared resources
    and ensures that Test and Set operation on the control variable are
    performed atomically so that race conditions do not occur among
    multiple threads processing floating IPs.
    Limitation: The scope of this change is limited to addressing the race
    condition described in the bug report. It may not address other issues
    such as pre-existing issue with handling of DVR floatingips on agent
    restart.
    
    closes-bug: #1381238
    
    Change-Id: I6dc2b7bad6e8ddbaa86c1f7a1e2028aeacc3afef

commit ab0992cf5303752f054ad4d47f0a949aadbea83a
Author: Bradley Jones <jones.bradley at me.com>
Date:   Mon Oct 20 12:34:55 2014 +0100

    Ensure ofagent unit tests handles random hashseeds
    
    Several tests in test_ofa_neutron_agent.py and test_ofa_flows.py fail when
    running the unit tests with hashseed 2701526934.
    
    This patch fixes the failing unit tests by specifying that assert_has_calls does
    not need to assert any order.
    
    Change-Id: I48d6601130f7de1f6eeb7333a17eddd82e7acbdf
    Partial-Bug: 1348818

commit ccd650732729451aa8e5ce3401f9570c70c4f066
Author: Sylvain Afchain <sylvain.afchain at enovance.com>
Date:   Fri Sep 26 13:49:43 2014 +0000

    Moves the HA resource creations outside of transaction
    
    Currently the HA resources are created in the
    _create_router_db which includes calls to
    the plugin and generates RPC calls. Even if the
    resource creations are outside of any transaction
    from the _create_router_db point of view, this
    method is  called in a transaction from the
    create_router method.
    This patch moves the resource creations to the
    create_router method outside the transaction.
    The failures are handled as previously with
    a try/expect.
    
    Change-Id: If8fcfd012f8e992175e49bbefb2ae667881a620a
    Closes-bug: #1374461

commit 5e4b600528a2b58cbb38d6b8d55b316602d4d015
Author: Peng Xiao <penxiao at cisco.com>
Date:   Mon Oct 20 14:16:36 2014 +0800

    Modify docstring on send_delete_port_request in N1kv plugin
    
    N1kv plugin: Modify docstring on _send_delete_port_request method
    
    Change-Id: I64d34878ffd8f6db703e4c1d9849032fef9bae96
    Closes-Bug: #1381277

commit 9334d1c98c3abdadc12222acb3f6f4527c940895
Author: Weidong Shao <weidong.shao at huawei.com>
Date:   Thu Aug 21 20:10:47 2014 +0000

    Empty files should not contain copyright or license
    
    Per instruction from
    http://docs.openstack.org/developer/hacking/#openstack-licensing
    
    Enable hacking check H104 in this CL.
    
    Change-Id: I435b9d91877499ebe1e33435f06794164a0ecc34
    Partial-Bug: #1262424

commit fd11b4264da0cef395788b0e0ee12c86cb65ec41
Author: Angus Lees <gus at inodes.org>
Date:   Mon Oct 20 11:19:02 2014 +1100

    Remove superfluous except/re-raise
    
    This exception code catches all exceptions, and then always raises them
    again.
    
    More interestingly, it uses excutils.save_and_reraise_exception
    incorrectly (outside a `with` statement), which triggers the pylint test
    designed to catch exactly this.
    
    Change-Id: Iab9d69944cbae5257682ac65ff2b8fba3ef7017e

commit db5e370b0d68c3e71626c99941fe487059b3cf88
Author: Romil Gupta <romilg at hp.com>
Date:   Mon Jun 30 05:35:08 2014 -0700

    Schema enhancement to support MultiSegment Network
    
    Description:
    Currently, there is nothing in the schema that ensures segments
    for a network are returned in the same order they were specified
    when the network was created, or even in a deterministic order.
    
    Solution:
    We need to add another field named 'segment_index' in
    'ml2_network_segment' table containing a numeric position index.
    With segment_index field we can retrieve the segments in the
    order in which user created.
    
    This patch set also fixes ML2 invalid unit test case in
    test_create_network_multiprovider().
    
    Closes-Bug: #1224978
    Closes-Bug: #1377346
    
    Change-Id: I560c34c6fe1c5425469ccdf9b8b4905c123d496d

commit bc4d1054c3d5125103e16cf85ef02f97987994fd
Author: armando-migliaccio <armamig at gmail.com>
Date:   Tue Oct 14 23:25:58 2014 -0700

    Remove redundant initialization and check from DVR RPC mixin
    
    The initialization, as well as the recurrent checks on whether the agent
    is able to handle DVR requests, are not necessary; this is because the
    dvr_agent is going to be set at the time the L2 agent starts receiving
    RPC messages.
    
    Change-Id: I9caad965d0ff507e2ed93d6432997ad86139ac04

commit 04df85b6e5a098f8f55bb82f04d9769763beb487
Author: Kevin Benton <blak111 at gmail.com>
Date:   Wed Sep 24 05:23:32 2014 -0700

    Improve performance of security group DB query
    
    The _select_ips_for_remote_group method was joining the
    IP allocation, port, allowed address pair, and security group tables
    together in a single query. Additionally, it was loading all of
    the port columns and using none of them. This resulted in a
    very expensive query with no benefit.
    
    This patch eliminates the unnecessary use of the port table by joining
    the IP allocation table directly to the security groups and allowed
    address pairs tables. In local testing of the method, this sped it up
    by an order of magnitude.
    
    Closes-Bug: #1373851
    Change-Id: I12899413004838d2d22b691f1e2f3b18f7ec2c27

commit 8d430a7f2e903dda06d8d75d6abcd63423c4c0a1
Author: Kevin Benton <blak111 at gmail.com>
Date:   Thu Oct 16 21:27:47 2014 -0700

    Optimize query in _select_dhcp_ips_for_network_ids
    
    Only query the DB for relevant columns instead of
    all of the port columns.
    
    Partial-Bug: #1373851
    Change-Id: I32cd4a0bc6799ce77cea13188676308e3e641d19

commit d739790ba8dcdf3180e8d6d09423937aaf802a7c
Author: Ihar Hrachyshka <ihrachys at redhat.com>
Date:   Tue Oct 14 15:05:20 2014 +0200

    Updated cache module and its dependencies
    
    This is to avoid cache module dependency on timeutils that are now moved
    to oslo.utils.
    
    The following changes are included:
    
     * neutron/openstack/common/cache/_backends/memory.py
      6ff6b4b Switch oslo-incubator to use oslo.utils and remove old modules
      2bedce3 Fix MemoryBackend not purging item from _keys_expired on delete
    
     * neutron/openstack/common/cache/backends.py
      39625e1 Set pbr 'warnerrors' option for doc build
    
     * neutron/openstack/common/cache/cache.py
      9c683be fix small typo
    
     * neutron/openstack/common/lockutils.py
      5d40e14 Remove code that moved to oslo.i18n
      7209975 Always log the releasing, even under failure
      bbb266c Clarify logging in lockutils
      942e1aa Use file locks by default again
      ac995be Fix E126 pep8 errors
      15b8352 Remove oslo.log from lockutils
    
    Change-Id: I02cb4b2bc4b7bcba948e67cffdb8bd0219c89a29

commit 623a30baadf24bdf672711096b1b87b60c70b038
Author: Ihar Hrachyshka <ihrachys at redhat.com>
Date:   Tue Oct 14 14:36:06 2014 +0200

    Updated service.py and its dependencies
    
    This is to avoid service module dependency on importutils that are now
    moved to oslo.utils.
    
    The following changes are included:
    
     * neutron/openstack/common/eventlet_backdoor.py
      5d40e14 Remove code that moved to oslo.i18n
      90ae24b Remove redundant default=None for config options
      fcf517d Update oslo log messages with translation domains
    
     * neutron/openstack/common/loopingcall.py
      5d40e14 Remove code that moved to oslo.i18n
      e377393 Changes calcuation of variable delay
      ab5d5f1 Use timestamp in loopingcall
      bc48099 Log the function name of looping call
      fb4e863 Remove deprecated LoopingCall
      fcf517d Update oslo log messages with translation domains
    
     * neutron/openstack/common/service.py
      5d40e14 Remove code that moved to oslo.i18n
      6ede600 rpc, notifier: remove deprecated modules
    
     * neutron/openstack/common/systemd.py
      17c4e21 Fix docstring indentation in systemd
    
     * neutron/openstack/common/threadgroup.py
      5a1a016 Make stop_timers() method public
      fdc8883 Add graceful stop function to ThreadGroup.stop
      2d06d6c Simple typo correction
      4d18b57 threadgroup: use threading rather than greenthread
    
    Change-Id: I4887545f861a93223e2c7cbcdd39efe991bff547

commit c1bc6ffad8b93490df36a049bf7be0d6da0ce2b0
Author: Ihar Hrachyshka <ihrachys at redhat.com>
Date:   Tue Oct 14 14:22:09 2014 +0200

    Updated fileutils and its dependencies
    
    This is to avoid fileutils dependency on excutils that are now moved to
    oslo.utils.
    
    The following changes are included:
    
    * neutron/openstack/common/__init__.py
      6b048e7 Let oslotest manage the six.move setting for mox
    
     * neutron/openstack/common/_i18n.py
      9ce1d96 Fix i18n import
      5d40e14 Remove code that moved to oslo.i18n
    
     * neutron/openstack/common/fileutils.py
      6ff6b4b Switch oslo-incubator to use oslo.utils and remove old modules
      2b966f9 Fix deletion of cached file for policy enforcer
      9c88dc3 file_open: fixed docstring to refer to open() instead of file()
      6c7407b fileutils: port to Python 3
      fcf517d Update oslo log messages with translation domains
    
     * neutron/openstack/common/log.py
      6c706c5 Delete graduated serialization files
      5d40e14 Remove code that moved to oslo.i18n
      6ff6b4b Switch oslo-incubator to use oslo.utils and remove old modules
      aa74411 log: add missing space in error message
      037dee0 Set stevedore log level to WARN by default
      37c0091 Add unicode coercion of logged messages to ContextFormatter
      6614413 Correct coercion of logged message to unicode
      1188d88 Except socket.error if syslog isn't running
      ac995be Fix E126 pep8 errors
      631f880 Set keystonemiddleware and routes.middleware to log on WARN level
      726d00a Adjust oslo logging to provide adapter is enabled for
      433fa0b Make logging_context_format_string optional in log.set_defaults
      ac92c06 Add default log level for websocket
      5fd77eb Ability to customize default_log_levels for each project
      4d9328c Python 3: enable tests/unit/test_log.py
      cb5a804 Move `mask_password` to strutils
    
    Note: cb5a804 is partially included; that's ok because we don't use the
    moved function in Neutron.
    
    Change-Id: I3bfcaff2620b368d807e9468bb7abc01d6471661

commit c97069dc9a73344ebdc7b686133269850a81b3b2
Author: Abhishek Raut <abhraut at cisco.com>
Date:   Tue Oct 7 17:06:10 2014 -0700

    Cisco N1kv: Fix update network profile for add tenants
    
    This patch makes sure that while updating network profile to add new
    tenants, it does not delete the older profile bindings and maintains
    them, while adds only the new tenant ids to the bindings.
    
    Change-Id: I862eb1c400e022334a2f6a4078425448bb144843
    Closes-bug: #1379609

commit 60dd689183469d2958d6dcb60d93a8d94ef694d1
Author: Kevin Benton <blak111 at gmail.com>
Date:   Thu Oct 16 21:24:07 2014 -0700

    DB: Only ask for MAC instead of entire port
    
    Optimize a query in _get_lla_gateway_ip_for_subnet
    to only grab the column used instead of every column
    in the port table.
    
    Partial-Bug: #1373851
    Change-Id: I5257e1e22645f3df9a77c0967b09a0ad0cf8b251

commit 6acadab5eb8b7b627e097a638d8486bef59a7f30
Author: Kevin Benton <blak111 at gmail.com>
Date:   Thu Oct 16 21:21:15 2014 -0700

    Only fetch port_id from SG binding table
    
    Change a query to only retrieve the port_id instead of
    every column from the row of security group binding info.
    
    Partial-Bug: #1373851
    Change-Id: I0fba9c9623898ee52590207ebbb728503bb59a5b

commit fd37ce7d943ab1c2dbc1cf3b6f0187c227f658ad
Author: Han Zhou <zhouhan at gmail.com>
Date:   Thu Oct 16 10:43:12 2014 +0000

    nsx plugin: keep old priority when reconnecting bad connection
    
    Change-Id: Id05012ec04d23a5eec8441fc85f87611e08271fd
    Closes-Bug: #1381094

commit ffcb30c4fbee334f9903d2719418bc6aa9d7721c
Author: Isaku Yamahata <isaku.yamahata at intel.com>
Date:   Thu Oct 16 15:31:03 2014 +0900

    l3_agent: avoid name conflict with context
    
    module name, context, conflicts with argument name in many place in
    l3_agent. In order to avoid such conflict, import context as n_context
    following Neutron practice.
    
    Change-Id: Ic3754818f84064d2c8da04914826fc912437b2f0
    Closes-Bug: #1381900

commit 7ea605df3ac71dc568194bcd5eaf1c115008e1ee
Author: Numan Siddique <numan.siddique at enovance.com>
Date:   Sat Oct 11 17:38:05 2014 +0530

    Fix KeyError in dhcp_rpc when plugin.port_update raise exception
    
    KeyError exception is seen because of following reasons
    
    * DhcpRpcCallback._port_action() is called by two functions
       -  DhcpRpcCallback.create_dchp_port()
       -  DhcpRpcCallback.update_dhcp_port()
    
    * When create_dhcp_port() function calls _port_action(), the
      function argument 'port' will have the body as
      {'port': {'network_id': foo_network_id, 'fixed_ips': [..] ...}
    
    * When update_dhcp_port() function calls _port_action(), the
      function argument 'port' will have the body as
      {'id': port_id, 'port': {{'port': {'network_id': foo_network_id,
    			            'fixed_ips': [..] ...}}
    
    * If an exception occurs when _port_action() calls plugin.create_port(),
      network id is accessed as
      net_id = port['port']['network_id']
    
    * If an exception occurs when _port_action() calls plugin.update_port(),
      network id is accessed as
      net_id = port['port']['network_id']
      which is causing the KeyError. network_id should have been accessed as
      net_id = port['port']['port']['network_id']
    
    This patch fixes the issue by making the _port_action() take the
    same port body. update_dhcp_port() insteading of passing the port_id
    and port information in a single argument, it now adds port_id
    in the port body itself.
    
    Change-Id: I70b92fa20b421b05ca2053a9a57f62db726f7625
    Closes-bug: #1378508

commit acfcb523b15fbd9ccc509e4366e4a141a66d4783
Author: Eugene Nikanorov <enikanorov at mirantis.com>
Date:   Sun Sep 28 21:56:00 2014 +0400

    Refactor _make_subnet_dict to avoid issuing unnecessary queries
    
    Use joined loads for attributes dns_nameservers and host_routes.
    
    As a result, particular scenarios like restarting DHCP agent
    could benefit from improved server-side performance.
    
    Change-Id: I6470356b601e2fcf74c7e0a6df438cef7099e9fe
    Closes-Bug: #1374044

commit 105dba9addfdffecea41cce58f3646d2f2a6a6cc
Author: YAMAMOTO Takashi <yamamoto at valinux.co.jp>
Date:   Thu Oct 9 09:04:34 2014 +0900

    openvswitch: Remove no longer used options
    
    They are remainders of the recently removed monolithic OVS plugin.
    Note: This change does not touch options used by OVS agent.
    
    Partial-Bug: #1323729
    Change-Id: I6dd04c5c506ff5f97f10ebab03943cd508fbfe60

commit 06fc675928408e462f01178e0158a72f8518188a
Author: Paul Michali <pcm at cisco.com>
Date:   Tue Oct 14 18:18:15 2014 -0400

    VPNaaS Cisco unit test clean-up
    
    Removed unused args to mock side-effect function and duplicate
    constant.
    
    Change-Id: I5409ce86ccaab86213d65f757f19c1bdf9a66929
    Closes-Bug: #1381221

commit 4c2b42e21744be56cbf32aeac6f4b4f1c87de24e
Author: Kevin Benton <blak111 at gmail.com>
Date:   Sat Oct 11 03:42:47 2014 -0700

    Call DVR VMARP notify outside of transaction
    
    The dvr vmarp table update notification was being called inside
    of the delete_port transaction in ML2, which can cause a yield
    and lead to the glorious mysql/eventlet deadlock.
    
    This patch moves it outside the transaction and adjusts it to
    use an existing port dictionary rather than re-looking it up since
    the port is now gone from the DB by the time it is called.
    
    Closes-Bug: #1377241
    Change-Id: I0b4dac61e49b2a926353f8478e421cd1a70be038

commit b4f025be065ea97710604f2f5e67fb4d9a28c16f
Author: Mark McClain <mmcclain at yahoo-inc.com>
Date:   Wed Jun 11 20:44:43 2014 -0400

    remove E251 exemption from pep8 check
    
    This change removes the exemption for E251 by addressing unexpected spaces
    around keyword/parameter equals
    
    Change-Id: Iff17477e37bef2a97fc58a538d08bcfc35c67751
    Partial-Bug: 1329017

commit 3cd2163d5105faad389bee5175ef446f0bb90289
Author: Vivekanandan Narasimhan <vivekanandan.narasimhan at hp.com>
Date:   Tue Sep 23 02:25:16 2014 -0700

    Race for l2pop when ports go up/down on same host
    
    With l2pop enabled, race exists in delete_port_postcommit
    when both create/update_port and delete_port deal with
    different ports on the same host, where such ports are
    either the first (or) last on same network for that host.
    This race happens outside the DB locking zones in
    the respective methods of ML2 plugin.
    
    To fix this, we have moved determination of
    fdb_entries back to delete_port_postcommit and removed
    delete_port_precommit altogether from l2pop mechanism
    driver.  In order to accomodate dvr interfaces, we
    are storing and re-using the mechanism-driver context
    which hold dvr-port-binding information while
    invoking delete_port_postcommit.  We loop through
    dvr interface bindings invoking delete_port_postcommit
    similar to delete_port_precommit.
    
    Closes-Bug: #1372438
    Change-Id: If0502f57382441fdb4510c81a89794f57a38e696

commit 79f1e8a9c1f308586077483d849e66dcdc83144f
Author: Kevin Benton <blak111 at gmail.com>
Date:   Mon Sep 29 19:33:06 2014 -0700

    Catch exceptions in router rescheduler
    
    Catch and log exceptions in router rescheduling loop
    rather than just dying which would stop all future
    router rescheduling attempts.
    
    This prevents transient DB connectivity issues from
    permanently breaking the rescheduler until the process
    restarts.
    
    Closes-Bug: #1375597
    Change-Id: I2ab37847074fa6bbdd2b13fd03b8742996dcfc78

commit 50d06130e1ff2a2cfb62510b52efe1537c1068b6
Author: Kevin Benton <blak111 at gmail.com>
Date:   Mon Oct 13 23:40:36 2014 -0700

    Minor: remove unnecessary intermediate variable
    
    Removes an unnecessary intermediary variable and an
    unnecessary list extend operation that implied previous
    list members where there weren't any. There should be no
    functional change. This just improves readability slightly.
    
    Change-Id: Ice412c29be083d82e055cc0bc45ed8b97c7628d0

commit a1fac106479f9c3c5559f8b2cfbc01fe12d3a575
Author: Elena Ezhova <eezhova at mirantis.com>
Date:   Tue Oct 14 10:12:59 2014 +0400

    Handle unused set_context in L3NatTestCaseMixin.floatingip_with_assoc
    
    set_context which is passed to floatingip_with_assoc method
    is not passed further to self._make_floatingip.
    
    Change-Id: Iecf2ad88e4bad5b1f8fd60668401863bdeecce8f
    Closes-Bug: #1378756

commit 3ba06618f79fed899188aac87a8694b3344ee995
Author: Xu Han Peng <xuhanp at cn.ibm.com>
Date:   Fri Jun 20 14:59:53 2014 +0800

    Use EUI64 for IPv6 SLAAC when subnet is specified
    
    This commit uses EUI64 for SLAAC and stateless IPv6 address
    when subnet id in fixed_ip is specified.
    
    After this patch, all the ports created on a subnet which has
    ipv6_address_mod=slaac or ipv6_address_mod=dhcpv6-stateless
    will use EUI64 as the address.
    This patch also checks if fixed IP address is specified
    for a IPv6 subnet with address mode slaac or dhcpv6-stateless
    during creating or updating a port. If yes, raise InvalidInput
    error to stop the port creation or update.
    
    Remove unit test test_generated_duplicate_ip_ipv6 because
    fixed_ip should not be specified for a slaac subnet.
    
    Change-Id: Ie481cfb2f4313baf44bf1a838ebda374a5c74c6a
    Closes-Bug: 1330826

commit 5fd628f123e6af1aa96b81f713867edcc67194d7
Author: Sukhdev <sukhdev at aristanetworks.com>
Date:   Wed Sep 24 15:57:15 2014 -0700

    Arista L3 Ops is success if it is successful on one peer
    
    This fix checks to see if Arista HW is
    configured in MLAG (redundant) mode. If yes,
    as long as operation is successful on one of the
    paired switches, consider it successful.
    
    Closes-bug: 1373652
    
    Change-Id: If929d3fcc109b81f4cf071380a1645d403feb363

commit 65b57625c24d86ce632d475e2ba743069ae1d797
Author: rossella <rsblendido at suse.com>
Date:   Tue Sep 23 16:09:09 2014 +0000

    Add unique constraints in IPAvailabilityRange
    
    first_ip, allocation_pool_id and last_ip, allocation_pool_id
    should be unique in the table.
    These constraints are essential to detect concurrent modifications
    of the IpAvailabilityRange table if the SELECT ... FOR UPDATE
    lock is removed
    
    Change-Id: Iaf2288c0b6bf27e93c03691073d7f505ef24fdd3
    Closes-bug: #1373015

commit 2c5f99a4b1376a46b8c1e1f4e82a015c2d29aa1f
Author: Andrew Boik <drew.boik at gmail.com>
Date:   Fri Oct 10 13:13:45 2014 -0400

    Update VPN logging to use new i18n functions
    
    For log messages in neutron/services/vpn and neutron/db/vpn, replace
    _() marker functions with log-level-specific marker functions: _LI(),
    _LW(), _LE() from oslo.i18n.
    
    Also, remove _() functions for debug log messages as debug level log
    messages should not be translated.
    
    Change-Id: I07fcf25bb6344c47e74d6ee23f9bc08e4b560679
    Closes-Bug: #1379811

commit e40c2ed58ce998fc5aba83ffae8ebefec9403c3b
Author: Jacek Swiderski <jacek.swiderski at codilime.com>
Date:   Tue Sep 23 14:35:06 2014 +0200

    mock.assert_called_once() is not a valid method
    
    mock.assert_called_once() is a no-op that tests nothing. Instead
    mock.assert_called_once_with() should be used (or use
    assertEqual(1, mock_obj.call_count) if you don't want to check
    parameters).
    
    Borrowed HACKING rule from Davanum Srinivas's nova patch to
    prevent it from appearing again.
    
    Change-Id: Idac1d3c89c07e13c9a209663f4e557fcb7547821
    Closes-Bug: #1365751
    Closes-Bug: #1300265

commit dcfcf31629706758cf7ace61dbf24e59c59f25d5
Author: vikas <vikas.d-m at hp.com>
Date:   Wed Jun 4 02:49:41 2014 -0700

    Check for VPN Objects when deleting interfaces
    
    When we delete Router interfaces/gateway,
    we need to check if any VPN services are
    associated with that router.
    
    Closes-Bug:1261598
    
    Change-Id: I7df2b8b130b47ec070d0b0a36b1a62df40532760

commit 648063881ebfbb54a362ef32d58263fc0f20981c
Author: Angus Lees <gus at inodes.org>
Date:   Thu Aug 28 14:37:34 2014 +1000

    Compare subnet length as well when deleting DHCP entry
    
    When searching for the DHCP subnet entry to delete, the existing code
    compares only the subnet prefix and ignores subnet length.  This could
    delete the wrong entry/entries if nested subnets are present.
    
    Change-Id: Icf079c42adeca14ef84ec57dc45a5930fde8786d
    Closes-Bug: #1362416

commit 542f5cc6277c6d66bb1f603e174f1254e823f2c9
Author: Angus Lees <gus at inodes.org>
Date:   Wed Aug 20 13:38:14 2014 +1000

    Add pylint tox environment and disable all existing warnings
    
    pylintrc update disables all warnings that currently trigger on neutron
    code.  The rough plan is to slowly re-enable warning categories as we
    clean up code in question.
    
    This change also includes a few ultra-trivial syntax cleanups where it
    allowed the check to be immediately enabled for the rest of the
    codebase:
    
    - Added missing trailing newlines in several files
      (db/migration/__init__.py, nuage/{nuagedb,syncmanager,common/config}.py)
    - Renamed self to cls in @classmethods
      (cisco/db/l3/device_handling_db.py)
    - Removed whitespace around '=' in a kwarg
      (cisco/db/l3/device_handling_db.py, cisco/db/n1kv_db_v2.py)
    - Updated deprecated pylint 'disable-msg' directive to newer 'disable'
      (cisco/extensions/qos.py)
    - File-specific disable for too-many-format-args pending further
      investigation of alternatives
      (ml2/drivers/arista/arista_l3_driver.py)
    - Import module rather than object and avoid long line
      (services/l3_router/l3_arista.py)
    
    Change-Id: Ifb0a1a38e33f9073a78658ca578fbd2a42747724

commit 685f6c9a7f4bc3996bf233a51ab3968edff24681
Author: OpenStack Proposal Bot <openstack-infra at lists.openstack.org>
Date:   Sat Oct 11 22:33:01 2014 +0000

    Updated from global requirements
    
    Change-Id: Ib0c8c561427f141583d677e86a76cbfe4e2be606

commit b1ca067cda3556ad2c40dce07a072f2a1044fcc1
Author: Yalei Wang <yalei.wang at intel.com>
Date:   Sun Oct 12 01:03:20 2014 +0800

    update the relative path of api_extensions_path
    
    the previous path 'unit/extensions' could not be found correctly.
    
    Change-Id: Ic8e658e651e99e57d19f6c3390db89650600decd
    Closes-Bug: 1379711

commit 524981cce05a9b365036c0a1e9810036936d3d5b
Author: ZHU ZHU <zhuzhubj at cn.ibm.com>
Date:   Fri Sep 5 03:01:07 2014 -0500

    Reduce security group db calls to neutron server
    
    Within ovs agent daemon loop, prepare_devices_filter will impose heavy workloads
    to neutron server in order to retrieve the security groups message to apply
    firewall rules. If agent is configured to use Noopfirewall driver or security
    groups are disabled, there is no need for loading the rules from server and
    refreshing the firewalls. This will reduce the number of db calls and improve
    performance for neutron server in this case.
    
    Change-Id: Id244aab3cac37fc6ed3dc05cbee91cdf9e34d9cc
    Closes-Bug: #1365806

commit 1423f8cd0f6ca92334660f9588a94bd0a9851b39
Author: armando-migliaccio <armamig at gmail.com>
Date:   Fri Oct 10 15:28:55 2014 -0700

    NSX: drop support to deprecated dist-router extension
    
    The NSX plugin originally implemented its own 'dist-router' extension.
    During the Juno timeframe the DVR extension was introduced and the NSX
    plugin was ported to support both. At the same time 'dist-router' was
    marked for removal in Kilo.
    
    Now that Kilo opened, we can drop the deprecated one.
    
    Change-Id: I7d6d2524ef6d5cb94a9e8514425a1a288eea7210

commit f3dd0e823cbdba1cfaa37433aa56d20edd36f75e
Author: Carl Baldwin <carl.baldwin at hp.com>
Date:   Fri Oct 10 05:12:43 2014 +0000

    Avoid constructing a RouterInfo object to get namespace name
    
    Constructing a RouterInfo object just for a string concatenation is
    inefficient and adds more dependence on the class which needs
    refactoring.
    
    Change-Id: Ibaf369d6ebe9285a0c845802def59bfa26ac0fd5

commit 652052860f0572ce1a3e8db56a58e08aca8d9195
Author: Ihar Hrachyshka <ihrachys at redhat.com>
Date:   Fri Oct 10 20:49:57 2014 +0200

    Drop sslutils and versionutils modules
    
    The modules are not used since when we've switched to oslo.messaging.
    
    Change-Id: Ife4298e0bb29ec15404fafe4b48545bd65e038e3

commit 7484c9ff93d431c3e9c99d46fea579ecb57bb10b
Author: OpenStack Proposal Bot <openstack-infra at lists.openstack.org>
Date:   Fri Oct 10 06:42:51 2014 +0000

    Imported Translations from Transifex
    
    Change-Id: I674acacc96c2396c31658bab48a441dac56988b0

commit afbe668a9c1dd250be9780eb5320652ee6dec21b
Author: Carl Baldwin <carl.baldwin at hp.com>
Date:   Thu Oct 9 20:33:23 2014 +0000

    Remove an argument that is never used
    
    This code was creating a dict with a gw_exists key.  I was curious to
    know who was interested in receiving this information down the line.
    However, no one is ever interested in that key.  It took me some time
    to follow this through wondering what was going on and found only dead
    ends.
    
    Change-Id: I755d9628ab750b950b33f5dcf32ccf2a9b00800e

commit 5e9305a6f934549408a9c18480fc1c000126621e
Author: Carl Baldwin <carl.baldwin at hp.com>
Date:   Thu Oct 2 20:35:21 2014 +0000

    Refactor _process_routers to handle a single router
    
    The method _process_routers no longer handles multiple routers.  The
    only caller of this method would construct a list of exactly one
    router in order to make the call.  This made the for loop unnecessary.
    The method's logic is too heavy for its current purpose.  This commit
    removes much of the weight.
    
    The use of the sets in this method is also no longer necessary.  It
    became clear that all of it boiled down to "if the router is not
    compatible with with this agent but it is known in router_info from
    before then we need to remove it."  This is an exceptional condition
    that shouldn't be handled in this method so I raise an exception and
    handle it in process_router_update where other router removal is
    handled.  Logging was added for this exceptional condition.
    
    The eventlet pool was also obsolete.  It was used to spawn two methods
    and there was a waitall at the end.  The other refactoring made it
    clear that the two spawns were mutually exclusive.  There was only one
    thread spawned for any given invocation of the method and the eventlet
    pool is overkill.
    
    Change-Id: Ibeac591b08565d10b2a9730e25a54f2cd11fc2bc
    Closes-Bug: #1378398

commit 4e8a5b7de71ba6f8c050c424613c025310498940
Author: Mark McClain <mmcclain at yahoo-inc.com>
Date:   Thu Oct 9 13:29:48 2014 +0000

    Add Juno release milestone
    
    Change-Id: Iea584b00329d9474c14847db958f8743d4058525
    Closes-Bug: #1378855

commit 93012915a3445a8ac8a0b30b702df30febbbb728
Author: Mark McClain <mmcclain at yahoo-inc.com>
Date:   Wed Oct 8 18:49:20 2014 +0000

    Add database relationship between router and ports
    
    Add an explicit schema relationship between a router and its ports. This
    change ensures referential integrity among the entities and prevents orphaned
    ports.
    
    Change-Id: I09e8a694cdff7f64a642a39b45cbd12422132806
    Closes-Bug: #1378866

commit 8923c6fae229c8e3dd85972811989698e482d7f6
Author: Carl Baldwin <carl.baldwin at hp.com>
Date:   Thu Oct 2 17:02:59 2014 +0000

    Remove all_routers argument from _process_routers
    
    There is no code left that passes True to this argument.  It is dead
    code and it should be removed.
    
    Change-Id: I55f71a5c0b96e530e45f2a6463978e8611cbc537

commit dd35d64812fd0ad02e7a00432073d141049e7107
Author: Mark McClain <mmcclain at yahoo-inc.com>
Date:   Wed Oct 8 15:38:19 2014 -0400

    update ml2_migration to reflect optional methods
    
    This change conditionally executes the schema methods for versions that
    support them.
    
    Change-Id: I8a51ac04e62dfcfe1e0a2e69a17664d154f0d1d7
    Closes-Bug: #1378732

commit 8a08a3cb47d0dd69d4aa2e8fa661d04054fe95ae
Author: Henry Gessau <gessau at cisco.com>
Date:   Tue Oct 7 20:38:38 2014 -0400

    Disable PUT for IPv6 subnet attributes
    
    In Juno we are not ready for allowing the IPv6 attributes on a subnet
    to be updated after the subnet is created, because:
    - The implementation for supporting updates is incomplete.
    - Perceived lack of usefulness, no good use cases known yet.
    - Allowing updates causes more complexity in the code.
    - Have not tested that radvd, dhcp, etc. behave OK after update.
    
    Therefore, for now, we set 'allow_put' to False for the two IPv6
    attributes, ipv6_ra_mode and ipv6_address_mode. This prevents the
    modes from being updated via the PUT:subnets API.
    
    Closes-bug: #1378952
    
    Change-Id: Id6ce894d223c91421b62f82d266cfc15fa63ed0e

commit 8fac816e407dd87d4c940d2a0c873f78933b8cdc
Author: Bradley Jones <jones.bradley at me.com>
Date:   Tue Aug 5 17:55:44 2014 +0100

    Do not assume order of lvm.tun_ofports set elements
    
    This fixes the test_fdb_add_flows unit test that breaks with a randomized PYTHONHASHSEED
    (see the bug report).
    
    The test assumed that the lvm.tun_ofports set had
    elements in a particular order. Found with PYTHONHASHSEED=2455351445 and
    1595538922.
    
    The fix sorts the actions output string so that it is always sorted when the
    outputs are compared.
    
    Partial-bug: #1348818
    
    Note: There are several other unrelated unit tests that also break with a
    randomized PYTHONHASHSEED, but they are not addressed here. They will be
    addressed in separate patches.
    
    Change-Id: I86b453a93f3ba09212709caf462cf3bfc5b21ee9

commit 67962943969bc737a3f680a0defc2fc9df03c429
Author: Sean M. Collins <sean_collins2 at cable.comcast.com>
Date:   Mon Oct 6 15:47:24 2014 -0400

    Skip IPv6 Tests in the OpenContrail plugin
    
    Similar to the way we are skipping tests in the OneConvergence plugin,
    introduced by Kevin Benton in 9294de441e684a81f6e802ba0564083f1ad319d6.
    
    Change-Id: I1650b0708af73ce63e92c55bc842607bb69efe60

commit c6a095b5a9bb6927b8f8c1380b6b4ccf310ac0ea
Author: OpenStack Proposal Bot <openstack-infra at lists.openstack.org>
Date:   Wed Oct 8 06:10:06 2014 +0000

    Imported Translations from Transifex
    
    Change-Id: If47b1705e22a7c8b6a84991d6ae0e68d419cba26

commit edb26bfcddf9d9a0e95955a6590d11fa7245ea2b
Author: Carl Baldwin <carl.baldwin at hp.com>
Date:   Wed Oct 8 03:22:49 2014 +0000

    Remove two sets that are not referenced
    
    The code no longer references the updated_routers and removed_routers
    sets.  This should have been cleaned up before but was missed.
    
    Change-Id: I0396e13d2f7c3789928e0c6a4c0a071b02d5ff17

commit abe30e973442271b0093eaa61c59d171a68a2028
Author: Assaf Muller <amuller at redhat.com>
Date:   Tue Oct 7 22:45:41 2014 +0300

    Forbid update of HA property of routers
    
    While the HA property is update-able, and resulting router-get
    invocations suggest that the router is HA, the migration
    itself fails on the agent. This is deceiving and confusing
    and should be blocked until the migration itself is fixed
    in a future patch.
    
    Change-Id: I4171ab481e3943e0110bd9a300d965bbebe44871
    Related-Bug: #1365426
    Closes-Bug: #1378525

commit 29250949012e9c0a60b0ddb56ddbf18d7b68106b
Author: Brian Haley <brian.haley at hp.com>
Date:   Fri Oct 3 17:32:01 2014 -0400

    Teach DHCP Agent about DVR router interfaces
    
    When DVR is enabled and enable_isolated_metadata=True,
    the DHCP agent should only inject a metadata host route
    when there is no port with the gateway IP address configured
    on the subnet.  Add a check for DEVICE_OWNER_DVR_INTERFACE
    when we look at each port's device_owner field, otherwise
    it will always add this route to the opts file when DVR
    is enabled.
    
    Change-Id: I3ff3bb85105b8215b36535983016d8c0ff3d8cb7
    Closes-bug: #1377307

commit 076a5f27486319139d3d1dfac592284656ef7eb7
Author: OpenStack Proposal Bot <openstack-infra at lists.openstack.org>
Date:   Tue Oct 7 19:13:11 2014 +0000

    Updated from global requirements
    
    Change-Id: I0e72933320ac6f49b55ef9782c6c19fb7e997bcb

commit 8f05708eb6d6a5a9cae7a7656873e081aad61eca
Author: Miguel Angel Ajo <mangelajo at redhat.com>
Date:   Fri Sep 19 18:59:58 2014 +0200

    Modify the ProcessMonitor class to have one less config parameter
    
    It's a follow up patch, as agreed on the ProcessMonitor review
    patch to coalesce the check_child_processes parameter into
    check_child_process_interval.
    
    When this parameter is set to 0, the feature is disabled.
    
    Change-Id: I2d4d8c6a6b7c17d42d8455c98968f75bcefbb689
    Closes-Bug: 1371705

commit 24e4110eb284078775496501ff81630eb1619c11
Author: Kevin Benton <blak111 at gmail.com>
Date:   Tue Oct 7 04:34:41 2014 -0700

    Big Switch: Don't clear hash before sync
    
    This patch removes the step of clearing the consistency
    hash from the DB before a topology sync. This will ensure
    that inconsistency will be detected if the topology sync
    fails.
    
    This logic was originally there to make sure the hash header
    was not present on the topology sync call to the backend.
    However, the hash header is ignored by the backend in a sync
    call so it wasn't necessary.
    
    Closes-Bug: #1379510
    Change-Id: I2d58fa2aea3b692834d64192d06ace727c7df8a0

commit d81856cc608660232005b5620f2378249f25e107
Author: Julien Danjou <julien at danjou.info>
Date:   Tue Oct 7 11:16:49 2014 +0200

    Remove sslutils from openstack.common
    
    This module has been imported but is not used. Let's remove it.
    
    Change-Id: I0cafdb7ddc00ce58b0724cee293f5dad6f4a1817

commit dea795263eb2968519d4235a8de98329c329e0e8
Author: John Schwarz <jschwarz at redhat.com>
Date:   Tue Sep 23 15:24:47 2014 +0300

    Divide _cleanup_namespaces for easy extensibility
    
    This division of the function to 2 different functions allows for
    easier overwriting in the l3 test agent used by the HA functional
    tests, and later by the integration tests.
    
    Related-bug: #1374947
    Change-Id: I8f277759747c8a142f5c023aa3511b00a886348c

commit 467bd9476defbb028f0fbfa26f01f76c32b701cd
Author: John Schwarz <jschwarz at redhat.com>
Date:   Tue Sep 23 14:41:54 2014 +0300

    L3 Agent should generate ns_name in a single place
    
    Currently the l3 agent has 2 places where it allows generating ns_name
    of specific router_ids (ie. qrouter-<router_id>): in the RouterInfo's
    constructor, and in _cleanup_namespaces. This patch proposes a
    unification of this creation code with a property which lives in
    RouterInfo's namespace. A simpler fix was also made for snat_ns_name.
    
    This patch also offers a single way to initialize a new RouterInfo.
    
    Related-bug: #1374946
    Related-bug: #1374947
    Change-Id: Ia028236b73a22ff534acee00b46c86b134dc987e

commit ea202faec972d55b169f1c596209b4129aa64caf
Author: Kevin Benton <blak111 at gmail.com>
Date:   Fri May 9 21:54:39 2014 -0700

    Add comments to iptables rules to help debugging
    
    Adds comments to some of the iptables rules generated
    by neutron to assist with debugging.
    
    DocImpact
    
    Partial-Bug: #1265493
    Change-Id: I7d9e37b9a43589dd7b142869b86fa15cb3fb329c

commit 54c0c950b28cb0e9857e84d7a241b7c89ebc5ba5
Author: mathieu-rohon <mathieu.rohon at gmail.com>
Date:   Thu Oct 2 17:25:16 2014 +0200

    nit : missing a "%s" in a log message
    
    Change-Id: I171cc14d7d9b3917dea90cd36dfec7e58afaf626

commit 28660b19f5ef861d7d2ceba04faa7f263bdf8a37
Author: John Schwarz <jschwarz at redhat.com>
Date:   Mon Sep 29 16:28:18 2014 +0300

    L3 agent should always use a unique CONF object
    
    The l3 agent accepts an oslo configuration in its constructor and uses
    it throughout the code, but there are some references to the global
    configuration object held by the oslo library. Since HA functional
    tests need to create two agents, the configuration should be consistent
    throughout the code.
    
    The important difference between the agents is their 'host' value so
    that they create different namespaces, and 'state_path' value so the
    agents get their own filesystem root.
    
    Co-Authored-By: Assaf Muller <amuller at redhat.com>
    Related-bug: #1374946
    Change-Id: I3326889482681dd631ca59271ebd6a5d5129ae70

commit e90d6d6c833db51964037afd1c4aa1f521ee380a
Author: John Schwarz <jschwarz at redhat.com>
Date:   Thu Sep 18 11:24:53 2014 +0300

    Iterate over same port_id if more than one exists
    
    In certain cases where multiple ports can have the same
    external_ids:iface_id property, the ovs agent will arbitrarily choose
    one and ignore the rest. In case the chosen port isn't on the
    integration bridge the ovs agent is managing, an error is returned to
    the calling function. This is faulty since one of the other ports may
    belong to the correct bridge and it should be chosen instead.
    
    This is interesting for future L3 HA integration tests, where 2
    different instances of l3 agents are needed to run on the same machine.
    In this case, both agents will register ports which have the same
    iface_id property, but obviously only one of the ports is relevant for
    each agent.
    
    Closes-bug: #1370914
    Related-bug: #1374947
    Change-Id: I05d70417e0f78ae51a9ce377fc93a3f12046b313

commit 623aa30b33692f8b1d1d12859281d23163829835
Author: Kevin Benton <blak111 at gmail.com>
Date:   Thu Oct 2 01:16:46 2014 -0700

    Fix setup of Neutron core plugin in VPNaaS UT
    
    One of the VPNaaS unit test setup routines creates
    and extension manager but passes it a class but it
    should be passing an instance of that class.
    
    Change-Id: I589cdda0674fdf8fa20d92c2609e1ba6966125d8

commit 205162f58050fcb94db53cd51b674d2093dfe700
Author: Mark McClain <mmcclain at yahoo-inc.com>
Date:   Wed Sep 24 04:00:54 2014 +0000

    remove openvswitch plugin
    
    This changeset removes the openvswitch plugin, but retains the agent for ML2
    The database models were not removed since operators will need to migrate the
    data.
    
    Change-Id: I8b519cb2bbebcbec2c78bb0ec9325716970736cf
    Closes-Bug: 1323729

commit 20dbbab61c1159a3dc6ef838ec65b04f7e9cf560
Author: Miguel Angel Ajo <mangelajo at redhat.com>
Date:   Wed Oct 1 15:16:19 2014 +0200

    Fix pid file location to avoid I->J changes that break metadata
    
    Changes in commit 7f8ae630b87392193974dd9cb198c1165cdec93b moved
    pid files handled by agent/linux/external_process.py from
    $state_path/external/<uuid>.pid  to $state_path/external/<uuid>/pid
    that breaks the neutron-ns-metadata-proxy respawn after upgrades
    becase the l3 or dhcp agent can't find the old pid file so
    they try to start a new neutron-ns-metadata-proxy which won't
    succeed, because the old one is holding the port already.
    
    Closes-Bug: #1376128
    Change-Id: Id166ec8e508aaab8eea35d89d010a5a0b7fdba1f

commit 239b2d94339574f63afe0c6df120bfea2974ef7f
Author: Ed Bak <ed.bak2 at hp.com>
Date:   Mon Sep 29 14:15:52 2014 -0600

    Don't fail when trying to unbind a router
    
    If a router is already unbound from an l3 agent, don't fail.  Log
    the condition and go on.  This is harmless since it can happen
    due to a delete race condition between multiple neutron-server
    processes.  One delete request can determine that it needs to
    unbind the router.  A second process may also determine that it
    needs to unbind the router.  The exception thrown will result
    in a port delete failure and cause nova to mark a deleted instance
    as ERROR.
    
    Change-Id: Ia667ea77a0a483deff8acfdcf90ca84cd3adf44f
    Closes-Bug: 1367892

commit 91683ffeb75fe8899a2925b5490c7c57ffa5f10a
Author: Mark McClain <mmcclain at yahoo-inc.com>
Date:   Wed Sep 24 01:50:06 2014 +0000

    remove linuxbridge plugin
    
    This changeset removes the linuxbridge plugin, but retains the agent for ML2.
    The database models were not removed since operators will need to migrate the
    data.
    
    Additionally, the ml2 migration script was altered to support Juno.  For
    testing, a user must either run the migration against the icehouse
    scheme or run the update, manually change alembic_version to juno and
    then run the migration script.  Once the juno migration is added, this
    manually step will not be required.
    
    Change-Id: I70689b4247947e6dc08e80fd9b31da9dc691d259
    Partial-Bug: 1323729

commit c7baaa068ed1d3c8b02717232edef60ba1b655f6
Author: Kevin Benton <blak111 at gmail.com>
Date:   Wed Jun 18 12:03:01 2014 -0700

    Allow reading a tenant router's external IP
    
    Adds an external IPs field to the external gateway information
    for a router so the external IP address of the router can be
    read by the tenant.
    
    DocImpact
    
    Closes-Bug: #1255142
    Change-Id: If4e77c445e9b855ff77deea6c8df4a0b3cf249d4

commit 8e36ba8d24c198cb5e6c0e4ddc29a08904e3e10c
Author: Samer Deeb <samerd at mellanox.com>
Date:   Wed Oct 1 09:55:21 2014 +0300

    Fix sleep function call
    
    Remove time.sleep method reference in class and use time.sleep directly.
    
    Change-Id: Ib4c02061b29c0d584d603746a78ab50922f781c3
    Closes-Bug: 1375698

commit cf92bbead9b25ee40a3336bd76110b3733a4f7ee
Author: Erik Colnick <erik.colnick at hp.com>
Date:   Wed Jun 18 11:31:52 2014 -0600

    Add admin tenant name to nova notifier
    
    This change introduces the ability to use the nova admin
    tenant name with the nova notifier in place of the nova
    admin tenant id which may not be available when the neutron
    service is being configured as is the case with tripleo
    installations where the neutron service is configured and
    started before the nova admin tenant has been configured in
    keystone and thus does not have a known id.
    
    DocImpact
    Introduces the nova_admin_tenant_name configuration entry as
    an optional configurable value in neutron.conf.  If the
    nova_admin_tenant_name is configured and the nova_admin_tenanat_id
    is not configured, a performance impact may be seen because
    keystone will become involved in communication between neutron
    and nova.
    
    Change-Id: I33701d4dc9bf61595e44a49050c405ebca779091
    Closes-Bug: #1331566

commit 36e8cbb34e78ff367cb501b8c494d9a02228251d
Author: Kevin Benton <blak111 at gmail.com>
Date:   Mon Sep 29 20:21:23 2014 -0700

    ML2: move L3 cleanup out of network transaction
    
    Move _process_l3_delete out of the delete_network
    transaction to eliminate the semaphore deadlock that
    occurs when it tries to delete the ports associated
    with existing floating IPs.
    
    It makes more sense to live outside of the transaction
    anyway because the operations it performs cannot be
    rolled back only in the database if the L3 plugin makes
    external calls for floating IP creation/deletion.
    e.g. if delete_floatingip is successful, it may have
    deleted external resources and restoring the DB records
    would make things inconsistent.
    
    If a failure to delete the network does occur, any cleanup
    done by _process_l3_delete will not be reversed.
    
    Closes-Bug: #1374573
    Change-Id: I3ae7bb269df9b9dcef94f48f13f1bde1e4106a80

commit 7b2ca045e846f0580de3d43ffd4595e66ebd6f4e
Author: Thierry Carrez <thierry at openstack.org>
Date:   Tue Sep 30 16:46:54 2014 +0200

    Open Kilo development
    
    Bump pre-version to 2015.1 to formally open master branch to Kilo
    development.
    
    Change-Id: Ia48ad29dc1b31b1fbcb14dfffad571659ec66700

commit eacd1fc6b2cb3175f603cdd80d7b59dbe9b0719b
Author: Robert Pothier <rpothier at cisco.com>
Date:   Wed Sep 3 11:09:15 2014 -0400

    ML2 Cisco Nexus MD: Fix UT to send one create vlan message
    
    With the commit of https://review.openstack.org/#/c/113009,
    test_nexus_add_trunk needs to have the device_id set to
    a unique value. Combining test_nexus_add_trunk and
    test_nexus_enable_vlan_cmd to reduce duplicate code,
    which fixes the original issue.
    
    Change-Id: I4191a6880ec0f43365aacb638a92a0dd3e1e80aa
    Closes-Bug: 1364976

commit 5247f5cdf15bad4c62bbf854e30716fcf00a1d2a
Author: Ann Kamyshnikova <akamyshnikova at mirantis.com>
Date:   Wed Feb 19 15:39:19 2014 +0400

    Implement ModelsMigrationsSync test from oslo.db
    
    Add tests to verify that database migrations produce
    the same schema as the database models.
    
    Also for MySQL, check that all tables are configured to use InnoDB
    as the storage engine.
    These tests make use of the ModelsMigrationsSync test class from
    oslo.db and the load_tests protocol from Python unittest.
    
    Closes-bug: #1346444
    
    Change-Id: Ic0e7eb37c30cc5e94cbdbddf07a6dc1ebf377c17

commit 302331b2197d7adcc7eb0d501718b7c28311acbc
Author: OpenStack Proposal Bot <openstack-infra at lists.openstack.org>
Date:   Tue Sep 30 06:49:06 2014 +0000

    Imported Translations from Transifex
    
    Change-Id: Ie7ba4679ca128ff636b6bd841072dfd4b7e4236f

commit c048d3fb480cbd9033152c745802691876b7ba0d
Author: John Kasperski <jckasper at us.ibm.com>
Date:   Thu Sep 25 10:38:45 2014 -0500

    Update migration scripts to support DB2
    
    Three of the migration scripts are causing failures with DB2.
    
    - DB2 doesn't support nullable column in primary key
    
    - Hard coded SQL statements which use False/True as Boolean arguments
      are not compatible with DB2. In DB2, Boolean columns are created as
      small integer with a constraint to allow only 0 & 1.
    
    - Hardcoded update rows from other table sql is not compatible with DB2
    
    - Foreign key constraints require additional handling
    
    Co-authored-by: Rahul Priyadarshi <rahul.priyadarshi at in.ibm.com>
    Change-Id: I82e2d1c522b81fed90a1e5cc6f2321f80797cf7b
    Closes-Bug: #1328019

commit 2abb77b4dadd4150f554f134ec99b07c2b28900f
Author: johndavidge <jodavidg at cisco.com>
Date:   Fri Aug 8 04:48:59 2014 -0700

    Do not assume order of report list elements
    
    This fixes the test_report_multiple_services unit test that breaks with a
    randomized PYTHONHASHSEED (see the bug report).
    
    The test assumed that the report list from self.driver.report_status() had
    elements in a particular order. Found with PYTHONHASHSEED=2455351445.
    
    The fix refactors the test case to handle an unsorted report list by
    sorting it before checking equality.
    
    Partial-bug: #1348818
    
    Note: There are several other unrelated unit tests that also break with a
    randomized PYTHONHASHSEED, but they are not addressed here. They will be
    addressed in separate patches.
    
    Change-Id: I542c3818821fa2f6e460fd254a3842530ecea8d9

commit ea3a0a428fac308f9ab65d0beb733de380cace56
Author: Koteswara Rao Kelam <koteswara.kelam at hp.com>
Date:   Fri Sep 26 04:34:11 2014 -0700

    Disallow unsharing used firewall policy
    
    When admin policy p1 is shared and is used by firewall f1 of different tenant,
    then updating p1 with shared=False should not be allowed as it is in use.
    
    Change-Id: I7c753f9d8a25a7edc40233316398475c8ad3efe9
    Closes-bug: #1334994

commit fd50ff4d243fbd4590b24b96039361504b45b49f
Author: OpenStack Proposal Bot <openstack-infra at lists.openstack.org>
Date:   Mon Sep 29 06:04:31 2014 +0000

    Imported Translations from Transifex
    
    Change-Id: I585e3df5504fcc071811e0ec9f925bc493584b2f

commit 9a6c073656a7e0b1a26b2bca0ba381489d04e322
Author: Eugene Nikanorov <enikanorov at mirantis.com>
Date:   Mon Sep 15 22:10:45 2014 +0400

    Add missing methods to NoopFirewallDriver
    
    The fix adds missing methods into generic Firewall class
    and in NoopFirewall driver class.
    
    Change-Id: I6402448075ed414434dc007f5c403fc85b6b1456
    Closes-Bug: #1369685
    Related-Bug: #1365806

commit 0d8911115e1b722da2f1e92f444e53b22223ee32
Author: Eugene Nikanorov <enikanorov at mirantis.com>
Date:   Mon Aug 25 00:59:02 2014 +0400

    Raise exception if ipv6 prefix is inappropriate for address mode
    
    Address prefix to use with slaac and stateless ipv6 address modes
    should be equal to 64 in order to work properly.
    The patch adds corresponding validation and fixes unit tests
    accordingly.
    
    Change-Id: I6c344b21a69f85f2885a72377171f70309b26775
    Closes-Bug: #1357084

commit 78a2ecb9923417f63c17c1e7055200ac97e6e947
Author: Kevin Benton <blak111 at gmail.com>
Date:   Sat Sep 20 00:17:58 2014 -0700

    Fix broken port query in Extraroute test case
    
    One of the queries in an extra route test case tries
    to filter based on the port owner, but the _list_ports
    method it calls doesn't take a device_owner parameter.
    This can cause failures if a DHCP port is created on
    the same subnet.
    
    Change-Id: I0e62027ae4d98944ef91a5d457d43d4224441b2f

commit 45a523681f2136f8fefb6c3da44540decd6a0fda
Author: armando-migliaccio <armamig at gmail.com>
Date:   Mon Sep 15 18:40:08 2014 -0700

    Revert "Cleanup floatingips also on router delete"
    
    This reverts commit c3326996e38cb67f8d4ba3dabd829dc6f327b666.
    
    The patch being reverted here addresses an issue that can no longer be
    reproduced, in that under no circumstances, I can make the FIP lie around
    before deleting a router (which can only be done after all FIP have been
    disassociated or released).
    
    Unless we have more clarity as to what the initial commit was really meant
    to fix, there is a strong case for reverting this patch at this point.
    
    Closes-bug: #1373100
    
    Change-Id: I7e0f80e456ff4d9eb57a1d31c6ffc7cdfca5a163

commit 5be55ac161adfec9085121fe59ea3bf59daa92cf
Author: Michael Smith <michael.smith6 at hp.com>
Date:   Wed Sep 24 10:20:46 2014 -0700

    fix dvr snat bindings for external-gw-clear
    
    When router_gateway_clear happens, the
    schedule_router calls the unbind_snat_servicenode
    in the plugin. This will clear the agent binding
    from the binding table. But the l3-agent was
    expecting the ex_gw_port binding to be present.
    The agent needs to check its cache of the
    router['gw_host_port'] value now.
    
    Change-Id: I051fb97d802b0508b30683a33673b85f5ab24000
    Closes-bug: #1373524

commit 3ca85460a178a18dea60399fd369ed84b17721dc
Author: Elena Ezhova <eezhova at mirantis.com>
Date:   Mon Aug 25 18:44:32 2014 +0400

    Fix quota limit range validator
    
    In Quota model limit is defined with Integer type which in case of
    MySQL and PostgreSQL is always stored in 4 bytes. At the same time,
    the current validator checks that the value does not exceed sys.maxsize
    which depends on whether the system is 32-bit or 64-bit based.
    
    In SQLite Integer can be stored in 1, 2, 3, 4, 6, or 8 bytes depending
    on the magnitude of the value. Nevertheless, assume that it can not
    exceed 4 bytes for consistency.
    
    Limited the upper bound of the validator with 2**31 - 1.
    
    Added a unit test.
    
    Closes-Bug: #1338479
    Change-Id: Icefa2fc228e4255a022d586cab4590607953d1ee

commit 55f6a8ac5d234f004ef06add87d16284e9f048d3
Author: shihanzhang <shihanzhang at huawei.com>
Date:   Mon Sep 22 17:28:06 2014 +0800

    Fix KeyError when getting secgroup info for ports
    
    The patch fixes a regression introduced with secgroup rpc refactor by
    handling the case when security group contains rules for only IPv4 or
    IPv6.
    
    Change-Id: I02b174757bfc796a81cdb482c55ba7f9e954131d
    Closes-bug: #1372337

commit 966645538395079b5337b5ed30d597112279283c
Author: Yong Sheng Gong <gongysh at unitedstack.com>
Date:   Mon Jun 30 15:01:17 2014 +0800

    Deletes floating ip related connection states
    
    When a floating ip is dissociated with a port, the current
    connection with the floating ip is still working. This patch
    will clear the connection state and cut off the connection
    immediately.
    
    Since conntrack -D will return 1, which is not an error code,
    so add extra_ok_codes argument to execute methods.
    
    Change-Id: Ia9bd7ae243a0859dcb97e2fa939f7d16f9c2456c
    Closes-Bug: 1334926

commit 4478eee9e55193746b43ad5158be5fee29aef8a3
Author: Brian Haley <brian.haley at hp.com>
Date:   Wed Sep 17 21:48:53 2014 -0400

    Do not lookup l3-agent for floating IP if host=None, dvr issue
    
    If a floating IP has been associated with a port, but the port
    has not been associated with an instance, attempting to lookup
    the l3-agent hosting it will cause an AgentNotFoundByTypeHost
    exception.  Just skip it and go onto the next one.
    
    Change-Id: If3df9770fa9e2d2eada932ee5f243d3458bf7261
    Closes-Bug: #1370795

commit 411836b5411411a6046043e0264aaa7b6f5760f0
Author: Carl Baldwin <carl.baldwin at hp.com>
Date:   Fri Sep 19 17:37:17 2014 +0000

    Remove RPC notification from transaction in create/update port
    
    Removing notifications to the L3 agent from within the transaction in
    create_port and update_port eliminates many lock wait timeouts in the
    dvr check queue job and in scale testing locally.
    
    Since this patch leaves context unused in _process_port_binding, the
    argument is removed from the method.
    
    Closes-Bug: #1371732
    
    Change-Id: Ibd86611ad3e7eff085d769bdff777a5870f30c58

commit d5b90315d2ff647179fd91512377a7f21a57ef0a
Author: Jacek Swiderski <jacek.swiderski at codilime.com>
Date:   Wed Aug 6 11:23:16 2014 +0200

    Do not assume order of body and tags elements
    
    This fixes the l2gateway unit test that breaks with a randomized PYTHONHASHSEED
    (see the bug report).
    
    The test assumed that the body dict from self._create_expected_req_body
    had elements (including contents of tags list) in a particular order.
    Found with PYTHONHASHSEED=2455351445.
    The fix ensures that body is in predictable order.
    
    Partial-bug: #1348818
    Note: There are several other unrelated unit tests that also break with a
    randomized PYTHONHASHSEED, but they are not addressed here. They will be
    addressed in separate patches.
    
    Change-Id: I423b68aff58486c113d0e5c5f4726f9eabf6920e

commit 739b3cac3210e6a1ce942238ca3efa3ddf49cb4d
Author: Steven Ren <sren at vmware.com>
Date:   Tue Sep 23 02:58:34 2014 -0700

    Remove the translation tag for debug level logs in vmware plugin
    
    There is no need to translate the debug level logs in vmware plugin for neutron.
    
    Closes-bug: #1372862
    
    Change-Id: If07c06cc3a1eb3dd147191bb8ab9198d4198cd69

commit e7f0b56d74fbfbb08a3b7a0d2da4cefb6fe2aa67
Author: Derek Higgins <derekh at redhat.com>
Date:   Fri Sep 12 16:31:44 2014 +0100

    Retry getting the list of service plugins
    
    On systems that start both neutron-server and neutron-l3-agent together,
    there is a chance that the first call to neutron will timeout. Retry upto
    4 more times to avoid the l3 agent exiting on startup.
    
    This should make the l3 agent a little more robust on startup but still
    not ideal, ideally it wouldn't exit and retry periodically.
    
    Change-Id: I2171a164f3f77bccd89895d73c1c8d67f7190488
    Closes-Bug: #1353953
    Closes-Bug: #1368152
    Closes-Bug: #1368795

commit 7af293ea527d5f904afcc2c3596bb151a5c3c017
Author: Ann Kamyshnikova <akamyshnikova at mirantis.com>
Date:   Tue Sep 23 12:15:05 2014 +0400

    Fix entrypoint of OneConvergencePlugin plugin
    
    In setup.cfg entrypoint of OneConvergencePlugin is set incorrectly.
    Used '.' instead of ':'.
    
    Closes-bug: #1372810
    
    Change-Id: Ic1e154cfcf8b13f021b0635238e07a0459a25a9e

commit 74d10939903984d5f06c1749a8707fa3257e44ff
Author: Elena Ezhova <eezhova at mirantis.com>
Date:   Tue Aug 19 15:54:36 2014 +0400

    Forbid regular users to reset admin-only attrs to default values
    
    A regular user can reset an admin-only attribute to its default
    value due to the fact that a corresponding policy rule is
    enforced only in the case when an attribute is present in the
    target AND has a non-default value.
    
    Added a new attribute "attributes_to_update" which contains a list
    of all to-be updated attributes to the body of the target that is
    passed to policy.enforce.
    
    Changed a check for whether an attribute is explicitly set.
    Now, in the case of update, the function should not pay attention
    to a default value of an attribute, but check whether it was
    explicitly marked as being updated.
    
    Added unit-tests.
    
    Closes-Bug: #1357379
    Related-Bug: #1338880
    Change-Id: I6537bb1da5ef0d6899bc71e4e949f2c760c103c2

commit 4418e80c117e896743bdd77fcc499bbd85475dc2
Author: Kevin Benton <blak111 at gmail.com>
Date:   Thu Sep 11 04:26:03 2014 -0700

    Finish small unit test refactor of API v2 tests
    
    Leverage a utility function for all of the tests
    that create something in the API and expect a failure.
    
    Change-Id: Iedb6ba35d637dda5ae9f553d0c7ffcb7c526f3c6

commit 32ea2e349decd750e25cb00a8c907b8f73f795f3
Author: Gary Kotton <gkotton at vmware.com>
Date:   Mon Sep 22 10:03:37 2014 -0700

    Security groups: prevent race for default security group creation
    
    When a VM is booted via the Nova the client connection is created
    with an admin user. This causes problems when creating the neutron
    port. That is, there may be a race for the creation of the default
    security group for the tenant.
    The problem was introduced by commit acf44dba26ca8dca47bfb5fb2916807f9f4e2060
    
    Change-Id: Ie0199c71231a322704f1f49995facde09c92da25
    Closes-bug: #1372570

commit 2f5aca31b508da9c673c0209ad40efc2b5b2d16d
Author: Preeti Mirji <preeti.mirji at hp.com>
Date:   Wed Jul 23 03:22:30 2014 -0700

    Stop admin using other tenants unshared rules
    
    If the firewall rules are not shared and if they belong to different
    tenants, then admin should not be able to create a policy using
    these rules and he should not be able to insert such rules into
    policies. An exception should be raised in such case. Added new
    exception “FirewallRuleConflict” to handle such conditions.
    
    Co-Authored-By: Koteswara Rao Kelam<koteswara.kelam at hp.com>
    Change-Id: I984eb76069bd1493a77bf523bec2bd81abb14abb
    Closes-bug: 1327057

commit c756d3c3ca9e90fab5e1d3ff37af33972747ba70
Author: Kevin L. Mitchell <kevin.mitchell at rackspace.com>
Date:   Mon Sep 22 12:18:11 2014 -0500

    Eliminate OrderedDict from test_api_v2.py
    
    Neutron cannot possibly be passing tests under Python 2.6, as
    neutron/tests/unit/test_api_v2.py is referencing
    collections.OrderedDict, which does not exist in Python 2.6.
    Since there is no reason to use an OrderedDict in this case,
    this replaces it with a simple dict.
    
    Change-Id: I1b9886f508c4c8b96cf50c50f157c1960da433fc
    Closes-Bug: #1372571

commit 086496bfc45e01cd2905a074d526a7d513bf4ec2
Author: Kevin Benton <blak111 at gmail.com>
Date:   Sat Sep 20 10:48:22 2014 -0700

    Mock out all RPC calls with a fixture
    
    Mock out the rpc proxy calls used by various agents to
    prevent unit tests from blocking for 10+ seconds while waiting
    for a timeout. This happened with the OVS agent unit tests
    recently in Change-ID Idd770a85a9eabff112d9613e75d8bb524020234a.
    
    This change results in a reduction from 330.8 seconds to 2.7 seconds
    for the neutron.tests.unit.openvswitch.test_ovs_neutron_agent
    test module.
    
    Closes-Bug: #1372076
    Change-Id: I5e6794dc33c64c8fe309d8e72a8af3385c7d4442

commit 0cc7444f7577e53f14068a2cb35431713d6d21a0
Author: Elena Ezhova <eezhova at mirantis.com>
Date:   Tue Aug 26 19:22:20 2014 +0400

    Add logging for enforced policy rules
    
    There are a lot of policy rules which should not necessarily
    be explicitly specified in policy.json to be checked while enforcement.
    There should be a way for an operator to know which policy rules are
    actually being enforced for each action.
    
    Added a unit test.
    
    Change-Id: I261d3e230eced9ea514b35cc3f5f8be04f84c751
    Closes-Bug: #1356679

commit e266c5cacf8debaf130422c7a88764c70cbef2b5
Author: OpenStack Proposal Bot <openstack-infra at lists.openstack.org>
Date:   Mon Sep 22 06:07:23 2014 +0000

    Imported Translations from Transifex
    
    Change-Id: If3c928da9856fae84b139c78ee04573daf562a95

commit d1f1722e0edb63c73b60c80abafa63749349cd8e
Author: YAMAMOTO Takashi <yamamoto at valinux.co.jp>
Date:   Mon Sep 22 07:39:27 2014 +0900

    ofagent: Drop log level of tenant-triggerable events
    
    To prevent evil tenants from flooding logs.
    
    Closes-Bug: #1372196
    Change-Id: I617e9fedf8a8c5e95c6067b716c83778d4d8cc7e

commit 271a280d0e8f86b96d24970f588184b1cfc34ef8
Author: Divya ChanneGowda <divya.hc at gmail.com>
Date:   Wed Sep 3 14:59:34 2014 -0700

    Use dict_extend_functions to populate provider network attributes
    
    Use dict_extend_functions mechanism to handle populating additional
    provider network attributes into Network model in Nuage plugin.
    
    Change-Id: I72e5afe3d03ae223fcd8e75f1f4f07624c3a7daf
    Closes-Bug: #1362308

commit 9cd96fe116ac1d990410cb1135473bd15c1f7dce
Author: Vivekanandan Narasimhan <vivekanandan.narasimhan at hp.com>
Date:   Wed Sep 3 01:48:39 2014 -0700

    DVR to delete router namespaces for service ports
    
    Earlier merge that enabled LBaaS in DVR with review #114141
    had not covered the removal of DVR router namespace on
    VIP Port deletion in ml2 plugin.
    
    Here we fix the ml2 plugin to attempt namespace removal for
    all dvr serviced ports.
    
    Change-Id: Ie7930ebedb12212886d45294132fefff7296e104
    Closes-Bug: #1364839

commit f92d1300e1aca68b39b927282af038acc68c5013
Author: armando-migliaccio <armamig at gmail.com>
Date:   Thu Sep 18 11:00:12 2014 -0700

    Fix 500 error on retrieving metadata by invalid URI
    
    An invalid URI should return a BadRequest error rather
    than making the metadata proxy bomb out.
    
    Closes-bug: #1371160
    
    Change-Id: Ifb495f9e8929062a0c24d090c3e702109a38803a

commit 2286d220ddb2677c957837381e1827bdfe3b0c8e
Author: Paul Michali <pcm at cisco.com>
Date:   Tue Sep 16 11:22:17 2014 -0400

    Rework and enable VPNaaS UT for Cisco CSR REST
    
    The Cisco CSR REST client library unit tests were developed in
    Icehouse, using the httmock library. However, the community did
    not want to add this library to global requirements, as there was
    a similar httpretty library available (albeit with some short-
    comings). As a result, the test module was renamed with a "no"
    prefix, to prevent inclusion in automated tests.
    
    Since then, a new library, requests-mock, has been added to global
    requirements, to replace httpretty, and is being used on several
    other projects.
    
    This commit reworks the unit test to use requests-mock, instead of
    httmock. The functionality is the same, but the mechanism (a
    fixture with URI registration vs context manager) is different.
    
    This commit provides coverage for the REST client code, by using a
    mock for the Cisco CSR VM. The unit test module can be subclassed,
    and used with a real CSR VM, for 3rd party CI testing, in the
    future.
    
    Change-Id: I55c8a253eb32985bc2016ae748b1ded58d021e1a
    Closes-Bug: 1358470

commit 1d4e13574574472e299296892d7c9e8f706aea67
Author: Chirag Shahani <chirag.shahani at gmail.com>
Date:   Wed Sep 10 15:47:48 2014 -0700

    Fix to delete user and group association in Nuage Plugin
    
    After a router delete operation, the attached zone to that
    router is also deleted. Got rid of code that tried to do
    a get operation on the nuage_zone after router delete
    operation.
    Closes-Bug: #1367864
    
    Change-Id: I01753a472200a961cdcecee703616fd3239abd3c

commit 34cf04a0ea84f4e5b32aa8d45108bd2a38bcff58
Author: Kevin Benton <blak111 at gmail.com>
Date:   Tue Sep 16 17:29:51 2014 -0700

    Delete DB records instead of tables to speedup UT
    
    Now that the schema is fixed for all of the plugins,
    there isn't a need to delete and recreate the entire
    schema for every unit test.
    
    This patch clears the tables at the end of each test
    instead of deleting them. This eliminated overhead seems
    to save 10%+ execution time of the entire set of unit
    tests.
    
    Example of performance gain from tox -epy27 tests.unit.ml2:
    Before: Ran 2495 tests in 284.186s
    After: Ran 2495 tests in 223.299s
    
    Change-Id: Ic5bcbb0cf941e0745890abc776d719e58bb42e35

commit dd5c73450da908d95724e20eb3be09bc936cb551
Author: YAMAMOTO Takashi <yamamoto at valinux.co.jp>
Date:   Fri Aug 15 14:20:00 2014 +0900

    ofagent: Ignore unknown l2pop entry removals
    
    l2pop can send us entry removal without the corresponding addition.
    Gracefully ignore it instead of crashing.
    
    Closes-Bug: #1357198
    Change-Id: I5a0cc44ba62faf15d6fe3730a9532a3826647820

commit 0e4141644df45f25c229c65e66c57132a93b446c
Author: Carl Baldwin <carl.baldwin at hp.com>
Date:   Tue Feb 11 00:58:42 2014 +0000

    Rename workers to api_workers and simplify code
    
    Refactor a few ugly aspects of the multiple API worker patch to make
    way for multiple rpc workers.  This came up as I was trying to add
    multiple RPC workers using similar patterns and remembering that some
    things were left in a rather awkward state.
    
    Change-Id: I549db67af4af6a2df80e12cf233109dda5213c47

commit 4e1c4cbcd71833095534bea9ff7617c582c300d2
Author: Abhishek Raut <abhraut at cisco.com>
Date:   Fri Sep 12 19:56:40 2014 -0700

    Cisco N1kv: Remove vmnetwork delete REST call on last port delete
    
    Remove the vm network delete call to the VSM on final port call and
    ensure that vm network is deleted from the database when the port count
    becomes 0.
    
    Change-Id: I6c08a099adfce2fdba8eefec6aadeb68a780ac37
    Closes-Bug: 1373547

commit da4433e1af75a7ad0a03b3e48e7b12af9a4d0e55
Author: YAMAMOTO Takashi <yamamoto at valinux.co.jp>
Date:   Thu Sep 4 13:06:21 2014 +0900

    ofagent: Fix a possible crash in arp responder
    
    Be careful for exceptions when feeding packet-in data,
    which is generated by tenant VMs and thus can not be trusted,
    to Ryu packet library.
    
    Closes-Bug: #1365255
    Change-Id: Ia8bacfb55def563a1b23a47709ae72bd4fce0fce

commit c5ae5ad2637a561ccbc7484045e99d8140822b8d
Author: Eugene Nikanorov <enikanorov at mirantis.com>
Date:   Fri Sep 12 09:05:39 2014 +0400

    Properly handle empty before/after notifications in l2pop code
    
    Change-Id: I8644bb7cc2afb3b181397a478f96927990c0a4ca
    Closes-Bug: #1367881

commit 5e4c14e850e2757bf74a806aaaab4c053bab741d
Author: Sam Betts <sam at code-smash.net>
Date:   Tue Aug 26 18:35:36 2014 +0100

    Added TAP_DEVICE_PREFIX info to common/constants
    
    Change-Id: Ia84629732490585164237ca4f7d1db90bde9fbf2
    Closes-Bug: 1361573

commit f8e10b5f6a8b5a4d4dac845c316db23d6f67c347
Author: Assaf Muller <amuller at redhat.com>
Date:   Tue Jul 1 16:18:35 2014 +0300

    Pythonified sanity_check.all_tests_passed
    
    Change-Id: I48986344b7af507e2526d4e8bd1b03277f974972

commit 424c7faa75d96950d80f49f20f5414d1a297af72
Author: Ihar Hrachyshka <ihrachys at redhat.com>
Date:   Thu Aug 7 22:27:23 2014 +0200

    Removed kombu from requirements
    
    Since we've replaced oslo-incubator RPC layer with oslo.messaging, we
    don't ship any code that uses kombu.
    
    Change-Id: Ia8a74f1326ecd98c47cbe447f04d475bf61e19d3

commit b4bf668ec40ee6a329740b587fa4a651a6e0dca2
Author: Hareesh Puthalath <hareesh.puthalath at gmail.com>
Date:   Tue Sep 2 06:05:37 2014 +0200

    Supply missing cisco_cfg_agent.ini file
    
    cisco_cfg_agent.ini file was missed in the initial commit and
    caused neutron startup issues. This patch supplies the proper
    ini file and adds it back to neutron setup.cfg.
    Also the introduced config options are put in a specific group
    instead of default as was in the initial commit.
    
    Change-Id: I74b3b77fe6e196524809580f522f91f3b62f5ba7
    Closes-bug: #1351466

commit fbec4d6784100214856b7500ccfb2925d8f6e6dc
Author: Jeremy Stanley <fungi at yuggoth.org>
Date:   Wed Sep 3 19:04:06 2014 +0000

    Work toward Python 3.4 support and testing
    
    Change-Id: Ieae7819e0489ae19b7fcfb63497e06527c918b5c

commit 903e2a8cd1dd9169048d1ad9dd8a566b2ae52395
Author: Cédric Ollivier <ollivier.cedric at gmail.com>
Date:   Thu Aug 21 20:26:10 2014 +0200

    Add unit tests covering single operations to ODL
    
    This commit adds the remaining test cases (create and update
    operations) to fully cover sync_single_resource. It also defines the
    filter_* methods as static or class methods and removes their duplicate
    arguments.
    
    Change-Id: I6b6153ea577bd685576690559b1c389490ee525d
    Closes-Bug: #1325184

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

Title:
  floatingip still working once connected even after it is disociated

Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in neutron icehouse series:
  Fix Released
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  After we create an SSH connection to a VM via its floating ip, even
  though we have removed the floating ip association, we can still
  access the VM via that connection. Namely, SSH is not disconnected
  when the floating ip is not valid

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



From 1361360 at bugs.launchpad.net  Sun Oct 26 16:21:03 2014
From: 1361360 at bugs.launchpad.net (OpenStack Infra)
Date: Sun, 26 Oct 2014 16:21:03 -0000
Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not
 released back to the pool leading to choking of new requests
References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com>
Message-ID: <20141026162103.3530.85038.malone@soybean.canonical.com>

Reviewed:  https://review.openstack.org/130821
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=fc87da7eeb3451e139ee71b31095d0b9093332ce
Submitter: Jenkins
Branch:    master

commit fc87da7eeb3451e139ee71b31095d0b9093332ce
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Tue Oct 21 02:31:15 2014 -0700

    Eventlet green threads not released back to pool
    
    Presently, the wsgi server allows persist connections hence even after
    the response is sent to the client, it doesn't close the client socket
    connection.
    Because of this problem, the green thread is not released back to the pool.
    
    In order to close the client socket connection explicitly after the
    response is sent and read successfully by the client, you simply have to
    set keepalive to False when you create a wsgi server.
    
    DocImpact:
    Added wsgi_keep_alive option (default=True).
    In order to maintain the backward compatibility, setting wsgi_keep_alive
    as True by default. Recommended is set it to False.
    
    SecurityImpact
    
    Closes-Bug: #1361360
    Change-Id: Ic57b2aceb136e8626388cfe4df72b2f47cb0661c


** Changed in: cinder
       Status: In Progress => Fix Committed

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

Title:
  Eventlet green threads not released back to the pool leading to
  choking of new requests

Status in Cinder:
  Fix Committed
Status in Cinder icehouse series:
  New
Status in OpenStack Image Registry and Delivery Service (Glance):
  In Progress
Status in Glance icehouse series:
  New
Status in OpenStack Identity (Keystone):
  In Progress
Status in Keystone icehouse series:
  Confirmed
Status in Keystone juno series:
  Confirmed
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in neutron icehouse series:
  New
Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Compute (nova) icehouse series:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Currently reproduced  on Juno milestone 2. but this issue should be
  reproducible in all releases since its inception.

  It is possible to choke OpenStack API controller services using
  wsgi+eventlet library by simply not closing the client socket
  connection. Whenever a request is received by any OpenStack API
  service for example nova api service, eventlet library creates a green
  thread from the pool and starts processing the request. Even after the
  response is sent to the caller, the green thread is not returned back
  to the pool until the client socket connection is closed. This way,
  any malicious user can send many API requests to the API controller
  node and determine the wsgi pool size configured for the given service
  and then send those many requests to the service and after receiving
  the response, wait there infinitely doing nothing leading to
  disrupting services for other tenants. Even when service providers
  have enabled rate limiting feature, it is possible to choke the API
  services with a group (many tenants) attack.

  Following program illustrates choking of nova-api services (but this
  problem is omnipresent in all other OpenStack API Services using
  wsgi+eventlet)

  Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py.
  After you run the below program, you should try to invoke API
  ============================================================================================
  import time
  import requests
  from multiprocessing import Process

  def request(number):
     #Port is important here
     path = 'http://127.0.0.1:8774/servers'
      try:
          response = requests.get(path)
          print "RESPONSE %s-%d" % (response.status_code, number)
          #during this sleep time, check if the client socket connection is released or not on the API controller node.
          time.sleep(1000)
          print “Thread %d complete" % number
      except requests.exceptions.RequestException as ex:
          print “Exception occurred %d-%s" % (number, str(ex))

  if __name__ == '__main__':
      processes = []
      for number in range(40):
          p = Process(target=request, args=(number,))
          p.start()
          processes.append(p)
      for p in processes:
          p.join()

  ================================================================================================

  Presently, the wsgi server allows persist connections if you configure keepalive to True which is default.
  In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server.

  Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter.
  For example.
  Keep-Alive: timeout=10, max=5

  Note: After we have disabled keepalive in all the OpenStack API
  service using wsgi library, then it might impact all existing
  applications built with the assumptions that OpenStack API services
  uses persistent connections. They might need to modify their
  applications if reconnection logic is not in place and also they might
  experience the performance has slowed down as it will need to
  reestablish the http connection for every request.

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



From 1384626 at bugs.launchpad.net  Tue Oct 28 10:06:13 2014
From: 1384626 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 28 Oct 2014 10:06:13 -0000
Subject: [Openstack-security] [Bug 1384626] Re: SSL certification
 verification failed when Heat calls Glanceclient with ca cert
References: <20141023090711.3131.60470.malonedeb@wampee.canonical.com>
Message-ID: <20141028100613.3751.58496.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/130668
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=840ceddd873ad23cb9fdf171f2ea6574738ac8d3
Submitter: Jenkins
Branch:    stable/juno

commit 840ceddd873ad23cb9fdf171f2ea6574738ac8d3
Author: ZHU ZHU <zhuzhubj at cn.ibm.com>
Date:   Thu Oct 23 06:45:38 2014 -0500

    Correct CA cert argument for glanceclient
    
    Heat need to pass the CA cert to glanceclient to load image data
    during stack creation when glance api is configured with SSL.
    Currently the client is passing the wrong cert key to glanceclient.
    The key should be 'cacert' instead of 'ca_file'.
    
    Change-Id: Ie542dda1354776e62507240c917c1cffbc222f17
    Closes-Bug: #1384626
    (cherry picked from commit fa7fd9d9882baf028efe0807840a4a8180cc9b9c)


** Changed in: heat/juno
       Status: New => Fix Committed

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

Title:
  SSL certification verification failed when Heat calls Glanceclient
  with ca cert

Status in Orchestration API (Heat):
  Fix Committed
Status in heat juno series:
  Fix Committed

Bug description:
  Glance server is configured Https.

  Configured Heat with heat.conf 
  [clients_glance]
  ca_file=<ca file path>
  insecure=<false>

  When trying to create stack, heat will raise exception during heat to load image data.
  [Errno 1] _ssl.c:492: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

  The root cause is that: ca_file as below is a wrong argument to
  initialize the glance client,  it should be cacert which is supported
  arguments by glanceclient.

  class GlanceClientPlugin(client_plugin.ClientPlugin):

      exceptions_module = exc

      def _create(self):

          con = self.context
          endpoint_type = self._get_client_option('glance', 'endpoint_type')
          endpoint = self.url_for(service_type='image',
                                  endpoint_type=endpoint_type)
          args = {
              'auth_url': con.auth_url,
              'service_type': 'image',
              'project_id': con.tenant,
              'token': self.auth_token,
              'endpoint_type': endpoint_type,
              'ca_file': self._get_client_option('glance', 'ca_file'),
              'cert_file': self._get_client_option('glance', 'cert_file'),
              'key_file': self._get_client_option('glance', 'key_file'),
              'insecure': self._get_client_option('glance', 'insecure')

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



From 1370295 at bugs.launchpad.net  Tue Oct 28 13:50:03 2014
From: 1370295 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 28 Oct 2014 13:50:03 -0000
Subject: [Openstack-security] [Bug 1370295] Re: Possible SQL Injection
 vulnerability in hyperv volumeutils2
References: <20140917005121.25418.63480.malonedeb@soybean.canonical.com>
Message-ID: <20141028135003.2244.13100.malone@gac.canonical.com>

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

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

** Changed in: nova
     Assignee: (unassigned) => Sergey Vilgelm (sergey.vilgelm)

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

Title:
  Possible SQL Injection vulnerability in hyperv volumeutils2

Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  This line:
  https://github.com/openstack/nova/blob/master/nova/virt/hyperv/volumeutilsv2.py#L54
  makes a raw SQL query using input from target_address and target_port.
  If an attacker is able to manipulate either of these parameters, they
  can exploit a SQL injection vulnerability.

  If neither of these parameters can be controlled by an attacker, it's
  probably OK to fix this in public.  These should definitely at least
  be strengthened by using prepared statements, or even better, a secure
  SQL library such as sqlalchemy.

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



From 1361360 at bugs.launchpad.net  Thu Oct 30 10:12:18 2014
From: 1361360 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 30 Oct 2014 10:12:18 -0000
Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not
 released back to the pool leading to choking of new requests
References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com>
Message-ID: <20141030101218.24978.75706.malone@gac.canonical.com>

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/131987

** Changed in: keystone/juno
       Status: Confirmed => In Progress

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

Title:
  Eventlet green threads not released back to the pool leading to
  choking of new requests

Status in Cinder:
  Fix Committed
Status in Cinder icehouse series:
  New
Status in OpenStack Image Registry and Delivery Service (Glance):
  In Progress
Status in Glance icehouse series:
  New
Status in OpenStack Identity (Keystone):
  In Progress
Status in Keystone icehouse series:
  Confirmed
Status in Keystone juno series:
  In Progress
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in neutron icehouse series:
  New
Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Compute (nova) icehouse series:
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Currently reproduced  on Juno milestone 2. but this issue should be
  reproducible in all releases since its inception.

  It is possible to choke OpenStack API controller services using
  wsgi+eventlet library by simply not closing the client socket
  connection. Whenever a request is received by any OpenStack API
  service for example nova api service, eventlet library creates a green
  thread from the pool and starts processing the request. Even after the
  response is sent to the caller, the green thread is not returned back
  to the pool until the client socket connection is closed. This way,
  any malicious user can send many API requests to the API controller
  node and determine the wsgi pool size configured for the given service
  and then send those many requests to the service and after receiving
  the response, wait there infinitely doing nothing leading to
  disrupting services for other tenants. Even when service providers
  have enabled rate limiting feature, it is possible to choke the API
  services with a group (many tenants) attack.

  Following program illustrates choking of nova-api services (but this
  problem is omnipresent in all other OpenStack API Services using
  wsgi+eventlet)

  Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py.
  After you run the below program, you should try to invoke API
  ============================================================================================
  import time
  import requests
  from multiprocessing import Process

  def request(number):
     #Port is important here
     path = 'http://127.0.0.1:8774/servers'
      try:
          response = requests.get(path)
          print "RESPONSE %s-%d" % (response.status_code, number)
          #during this sleep time, check if the client socket connection is released or not on the API controller node.
          time.sleep(1000)
          print “Thread %d complete" % number
      except requests.exceptions.RequestException as ex:
          print “Exception occurred %d-%s" % (number, str(ex))

  if __name__ == '__main__':
      processes = []
      for number in range(40):
          p = Process(target=request, args=(number,))
          p.start()
          processes.append(p)
      for p in processes:
          p.join()

  ================================================================================================

  Presently, the wsgi server allows persist connections if you configure keepalive to True which is default.
  In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server.

  Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter.
  For example.
  Keep-Alive: timeout=10, max=5

  Note: After we have disabled keepalive in all the OpenStack API
  service using wsgi library, then it might impact all existing
  applications built with the assumptions that OpenStack API services
  uses persistent connections. They might need to modify their
  applications if reconnection logic is not in place and also they might
  experience the performance has slowed down as it will need to
  reestablish the http connection for every request.

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



From 1376915 at bugs.launchpad.net  Thu Oct 30 19:19:54 2014
From: 1376915 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 30 Oct 2014 19:19:54 -0000
Subject: [Openstack-security] [Bug 1376915] Re: Ceilometer policy file
	settings ignored
References: <20141002203501.17647.70947.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141030191954.6429.72825.malone@soybean.canonical.com>

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

** Changed in: ceilometer
       Status: New => In Progress

** Changed in: ceilometer
     Assignee: (unassigned) => Matthew Edmonds (edmondsw)

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

Title:
  Ceilometer policy file settings ignored

Status in OpenStack Telemetry (Ceilometer):
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Configuring the ceilometer policy.json file to restrict certain
  actions has no effect whatsoever. This allows all users access to
  sensitive information, such as audit data stored in the http.request
  meter.

  E.g. policy.json file:

  {
      "adm":  "role:admin",

      "default": "!",

      "meter:get_all": "rule:adm",
      "meters:get_all": "rule:adm"
  }

  With the above policy, tokens for users without the admin role are
  still able to access meters, and any token still works for alarms
  despite the default supposedly being to disallow for everyone.

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



From 1376915 at bugs.launchpad.net  Thu Oct 30 19:34:12 2014
From: 1376915 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 30 Oct 2014 19:34:12 -0000
Subject: [Openstack-security] [Bug 1376915] Change abandoned on ceilometer
	(master)
References: <20141002203501.17647.70947.malonedeb@chaenomeles.canonical.com>
Message-ID: <20141030193412.22593.22931.malone@wampee.canonical.com>

Change abandoned by Matt Riedemann (mriedem at us.ibm.com) on branch: master
Review: https://review.openstack.org/130854
Reason: Going to abandon for Matthew's more targeted fix:

https://review.openstack.org/#/c/132097/

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

Title:
  Ceilometer policy file settings ignored

Status in OpenStack Telemetry (Ceilometer):
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Configuring the ceilometer policy.json file to restrict certain
  actions has no effect whatsoever. This allows all users access to
  sensitive information, such as audit data stored in the http.request
  meter.

  E.g. policy.json file:

  {
      "adm":  "role:admin",

      "default": "!",

      "meter:get_all": "rule:adm",
      "meters:get_all": "rule:adm"
  }

  With the above policy, tokens for users without the admin role are
  still able to access meters, and any token still works for alarms
  despite the default supposedly being to disallow for everyone.

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