From sriram at sriramhere.com  Thu May  1 23:29:35 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Thu, 1 May 2014 16:29:35 -0700
Subject: [Openstack-security] Summit Syncup
Message-ID: <CAP6wb7JhFLdfrzhK6wKVRaSiU6en29RE38bwe99BOnZ9fDsB-w@mail.gmail.com>

Team,

I am sure this was discussed in the meetup today, but again I missed it.
What are the plans for an OSSG meetup during the summit?

I am arriving on Sunday around 7.30 pm, will be staying at Westin
Peachtree. How about you all? When are we gathering?

-- 
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/20140501/5453c5d5/attachment.html>

From bdpayne at acm.org  Fri May  2 00:25:50 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Thu, 1 May 2014 17:25:50 -0700
Subject: [Openstack-security] OSSG Lunch at Atlanta Summit
Message-ID: <CAFpPvXCEAhHWUD7aEBAS0PGiK1cuJKEtK9_UKPWSpxUKF6ZRpg@mail.gmail.com>

With the summit just around the corner, I wanted to ensure that we set
aside a time for OSSG to meet while in Atlanta.  So, please mark your
calendars:

When: Thursday May 15 @ 12:30p
Location: TBD but near the GWCC, I'll send out an update via email

I realize that there are Keystone sessions on either side of this lunch
slot.  Even so, this appears to be the best option all around.  For people
involved in Keystone, I encourage you to join us for as long as you can!

I know that OSSG has lots to discuss during the week.  This lunch can be a
working lunch, but I hope that it also somewhat social.  Let's try to
coordinate some other meeting times during the week to discuss specific
topics of interest to the OSSG community.  Watch for other emails
coordinating those.

More details on the lunch will be coming over the next week!

Cheers,
-bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140501/8f9af7a5/attachment.html>

From sriram at sriramhere.com  Fri May  2 01:06:03 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Thu, 1 May 2014 18:06:03 -0700
Subject: [Openstack-security] OSSG Lunch at Atlanta Summit
In-Reply-To: <CAFpPvXCEAhHWUD7aEBAS0PGiK1cuJKEtK9_UKPWSpxUKF6ZRpg@mail.gmail.com>
References: <CAFpPvXCEAhHWUD7aEBAS0PGiK1cuJKEtK9_UKPWSpxUKF6ZRpg@mail.gmail.com>
Message-ID: <5362ef85.2815320a.2bf2.100a@mx.google.com>

Super, thanks Bryan. I'm sure we'll meet each other before the lunch, this is awesome!

-----Original Message-----
From: "Bryan D. Payne" <bdpayne at acm.org>
Sent: ‎5/‎1/‎2014 5:28 PM
To: "openstack-security at lists.openstack.org" <openstack-security at lists.openstack.org>
Subject: [Openstack-security] OSSG Lunch at Atlanta Summit

With the summit just around the corner, I wanted to ensure that we set aside a time for OSSG to meet while in Atlanta.  So, please mark your calendars:


When: Thursday May 15 @ 12:30p
Location: TBD but near the GWCC, I'll send out an update via email


I realize that there are Keystone sessions on either side of this lunch slot.  Even so, this appears to be the best option all around.  For people involved in Keystone, I encourage you to join us for as long as you can!


I know that OSSG has lots to discuss during the week.  This lunch can be a working lunch, but I hope that it also somewhat social.  Let's try to coordinate some other meeting times during the week to discuss specific topics of interest to the OSSG community.  Watch for other emails coordinating those.


More details on the lunch will be coming over the next week!


Cheers,
-bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140501/944d0c91/attachment.html>

From robert.clark at hp.com  Fri May  2 08:50:43 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Fri, 2 May 2014 08:50:43 +0000
Subject: [Openstack-security] OSSN-0013 ready for review
Message-ID: <CF891AF2.B2A3%robert.clark@hp.com>

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



From robert.clark at hp.com  Fri May  2 11:08:33 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Fri, 2 May 2014 11:08:33 +0000
Subject: [Openstack-security] Review addition to openstack security guide
Message-ID: <A0C170085C37664D93EE1604364858A1122E996F@G4W3300.americas.hpqcorp.net>

Guys,

Thoughts on this addition to the security guide, see
https://bugs.launchpad.net/openstack-manuals/+bug/1311204

Document
https://docs.google.com/document/d/1wX7f5IW4-yVkaER17AQKXVvO6Q5FKLxMhyTa
pnvk868/edit?usp=sharing



-------------- 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/20140502/9bf098e9/attachment.bin>

From ayoung at redhat.com  Fri May  2 13:27:35 2014
From: ayoung at redhat.com (Adam Young)
Date: Fri, 02 May 2014 09:27:35 -0400
Subject: [Openstack-security] OSSG Lunch at Atlanta Summit
In-Reply-To: <CAFpPvXCEAhHWUD7aEBAS0PGiK1cuJKEtK9_UKPWSpxUKF6ZRpg@mail.gmail.com>
References: <CAFpPvXCEAhHWUD7aEBAS0PGiK1cuJKEtK9_UKPWSpxUKF6ZRpg@mail.gmail.com>
Message-ID: <53639D47.3010906@redhat.com>

On 05/01/2014 08:25 PM, Bryan D. Payne wrote:
> With the summit just around the corner, I wanted to ensure that we set 
> aside a time for OSSG to meet while in Atlanta.  So, please mark your 
> calendars:
>
> When: Thursday May 15 @ 12:30p
> Location: TBD but near the GWCC, I'll send out an update via email
>
> I realize that there are Keystone sessions on either side of this 
> lunch slot.  Even so, this appears to be the best option all around. 
>  For people involved in Keystone, I encourage you to join us for as 
> long as you can!
>
> I know that OSSG has lots to discuss during the week.  This lunch can 
> be a working lunch, but I hope that it also somewhat social.  Let's 
> try to coordinate some other meeting times during the week to discuss 
> specific topics of interest to the OSSG community.  Watch for other 
> emails coordinating those.
>
> More details on the lunch will be coming over the next week!
>
> Cheers,
> -bryan
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
See you then.
It would be awesome if we could get this kind of thing on sched.org as 
well as the sessions.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140502/3e791998/attachment.html>

From gerrit2 at review.openstack.org  Fri May  2 15:50:46 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 02 May 2014 15:50:46 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WgFja-0005my-0l@review.openstack.org>


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

Log:
commit db2467db3abfd5656aad987077d6052aad97985a
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From gerrit2 at review.openstack.org  Fri May  2 22:53:59 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 02 May 2014 22:53:59 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WgML9-0002Ky-7Z@review.openstack.org>


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

Log:
commit cefb8bb6cea42851b3e4500d15763f6b8c068b9c
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From gerrit2 at review.openstack.org  Sun May  4 19:50:01 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Sun, 04 May 2014 19:50:01 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1Wh2QD-0004PC-RA@review.openstack.org>


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

Log:
commit 9f12d1e6bdb453e02696805d84be2076436a5448
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From gerrit2 at review.openstack.org  Sun May  4 19:56:42 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Sun, 04 May 2014 19:56:42 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1Wh2Wg-0004fr-Ci@review.openstack.org>


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

Log:
commit ea1decd193c1b8e66e3d96ffd3b18b01e4721a5a
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From gerrit2 at review.openstack.org  Sun May  4 20:05:23 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Sun, 04 May 2014 20:05:23 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1Wh2f5-00050e-CI@review.openstack.org>


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

Log:
commit 4310ecc4d97eeb4bdb0c90b818e12982d20c3a7c
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From 1174499 at bugs.launchpad.net  Sun May  4 19:56:50 2014
From: 1174499 at bugs.launchpad.net (Openstack Gerrit)
Date: Sun, 04 May 2014 19:56:50 -0000
Subject: [Openstack-security] [Bug 1174499] Related fix proposed to
	python-keystoneclient (master)
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140504195650.3943.51865.malone@soybean.canonical.com>

Related fix proposed to branch: master
Review: https://review.openstack.org/92021

-- 
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 OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (Keystone):
  Fix Committed
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  In Progress

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/horizon/+bug/1174499/+subscriptions



From 1315556 at bugs.launchpad.net  Sat May  3 17:01:19 2014
From: 1315556 at bugs.launchpad.net (Dolph Mathews)
Date: Sat, 03 May 2014 17:01:19 -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: <20140503170120.24956.32614.malone@wampee.canonical.com>

Is this a regression?

** Tags added: havana-backport-potential icehouse-backport-potential

** Tags added: security

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

** Changed in: keystone
   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/1315556

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

Status in OpenStack Identity (Keystone):
  Triaged

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  Mon May  5 07:01:18 2014
From: 1315556 at bugs.launchpad.net (Guang Yee)
Date: Mon, 05 May 2014 07:01:18 -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: <20140505070118.26997.88300.malone@gac.canonical.com>

I don't think we have a test case for this. We check the project's
domain status only if it is specified. For example,

"scope": {
    "project": {
        "name": "projectA",
        "domain": {
            "name": "domainA"
        }
    }
}

However, when project ID is specified, project domain info is absent.
Therefore, backend never check the project domain status.

"scope": {
    "project": {
        "id": "<project_id>"
    }
}

-- 
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):
  Triaged

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  Mon May  5 18:48:31 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 05 May 2014 18:48:31 +0000
Subject: [Openstack-security] [openstack/ironic] SecurityImpact review
 request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e
Message-ID: <E1WhNwF-0001MI-Gg@review.openstack.org>


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

Log:
commit 7fb05fa546c2c51e70d50a54dfc0e1cfe9275d92
Author: Josh Gachnang <josh at pcsforeducation.com>
Date:   Wed Mar 19 16:47:38 2014 -0700

    Adding swift temp url support
    
    This patch will allow properly configured Glance servers to return a temporary
    URL for an object hosted on Swift. It will require Glance to use Swift
    as its backend. A temporary URL will let the agent download an image from
    Glance without requiring an auth_token, which gives access more than just
    Glance. The easiest way to use it is to enable direct_url in Glance, but
    you can set the appropriate config options to avoid needing to enable it.
    
    We/I need to add a note in the docs about Swift being a possible dependency
    for Ironic deploys using IPA, along with how to set the Temp URL key.
    
    Swift perfomance concerns will be addressed in this blueprint:
    https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads
    
    SecurityImpact
    DocImpact
    
    Implements: blueprint swift-temp-urls
    Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e




From malini.k.bhandaru at intel.com  Mon May  5 19:39:51 2014
From: malini.k.bhandaru at intel.com (Bhandaru, Malini K)
Date: Mon, 5 May 2014 19:39:51 +0000
Subject: [Openstack-security] OSSN-0013 ready for review
In-Reply-To: <CF891AF2.B2A3%robert.clark@hp.com>
References: <CF891AF2.B2A3%robert.clark@hp.com>
Message-ID: <EE6FFF4F6C34C84C8C98DD2414EEA47E72310939@fmsmsx117.amr.corp.intel.com>

We have two OSSN-0013s making their way!
Need a better number reservation system. :-)
Malini

-----Original Message-----
From: Clark, Robert Graham [mailto:robert.clark at hp.com] 
Sent: Friday, May 02, 2014 1:51 AM
To: openstack-security at lists.openstack.org
Subject: [Openstack-security] OSSN-0013 ready for review

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

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



From 1174499 at bugs.launchpad.net  Mon May  5 20:20:31 2014
From: 1174499 at bugs.launchpad.net (Openstack Gerrit)
Date: Mon, 05 May 2014 20:20:31 -0000
Subject: [Openstack-security] [Bug 1174499] Related fix merged to
	python-keystoneclient (master)
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140505202032.26769.21989.malone@gac.canonical.com>

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

commit f2adf271e719647b8e3f8bd13dce84a35dfcb932
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Sun May 4 14:52:53 2014 -0500

    Fix client fixtures
    
    Some of the client fixtures used for testing were invalid. v2
    tokens must have 'access'/'token'/'expires', and v3 tokens must
    have 'token'/'expires_at'.
    
    Change-Id: I2614c7deed47c9758c2031418110108308634296
    Related-Bug: #1174499

-- 
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 OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (Keystone):
  Fix Committed
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  In Progress

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/horizon/+bug/1174499/+subscriptions



From nkinder at redhat.com  Mon May  5 19:59:53 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Mon, 05 May 2014 12:59:53 -0700
Subject: [Openstack-security] OSSN-0013 ready for review
In-Reply-To: <EE6FFF4F6C34C84C8C98DD2414EEA47E72310939@fmsmsx117.amr.corp.intel.com>
References: <CF891AF2.B2A3%robert.clark@hp.com>
 <EE6FFF4F6C34C84C8C98DD2414EEA47E72310939@fmsmsx117.amr.corp.intel.com>
Message-ID: <5367EDB9.9060009@redhat.com>



On 05/05/2014 12:39 PM, Bhandaru, Malini K wrote:
> We have two OSSN-0013s making their way!
> Need a better number reservation system. :-)

Let's let Rob take OSSN-0013, and the one you are working on can be
OSSN-0014.

If we want to reserve a number, we could grab it on the OSSN wiki page
ahead of time.  My concern with this is that  someone could grab a
number to start writing a security note, then disappear for some time
(or the issue takes a lot of back and forth to get through review).  In
the meantime, other notes might be written and published.  This will
result in the numbers being out of sequence.  It's not the end of the
world, but it is a bit confusing.  This isn't a theoretical situation
either, as OSSN-0010 was published after OSSN-0011 and OSSN-0012:

    https://wiki.openstack.org/wiki/Security_Notes

The alternative is that we assign the number at publishing time.  This
requires more diligence at patch approval time to ensure that we don't
duplicate a number and might require patch rework to renumber things
(which is what we're going through right now).

What preferences do others have on this?

Thanks,
-NGK

> Malini
> 
> -----Original Message-----
> From: Clark, Robert Graham [mailto:robert.clark at hp.com] 
> Sent: Friday, May 02, 2014 1:51 AM
> To: openstack-security at lists.openstack.org
> Subject: [Openstack-security] OSSN-0013 ready for review
> 
> https://review.openstack.org/#/c/91755/
> 
> _______________________________________________
> 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
> 



From bdpayne at acm.org  Mon May  5 20:35:54 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Mon, 5 May 2014 13:35:54 -0700
Subject: [Openstack-security] OSSN-0013 ready for review
In-Reply-To: <5367EDB9.9060009@redhat.com>
References: <CF891AF2.B2A3%robert.clark@hp.com>
 <EE6FFF4F6C34C84C8C98DD2414EEA47E72310939@fmsmsx117.amr.corp.intel.com>
 <5367EDB9.9060009@redhat.com>
Message-ID: <CAFpPvXD_NGY8j780RaUDe6hnsru4dS055ASubHLQ6yqBJuC3SQ@mail.gmail.com>

I think it makes sense to assign the OSSN number as early as possible.  If
they are published out of order... I'm not too worried about that.


On Mon, May 5, 2014 at 12:59 PM, Nathan Kinder <nkinder at redhat.com> wrote:

>
>
> On 05/05/2014 12:39 PM, Bhandaru, Malini K wrote:
> > We have two OSSN-0013s making their way!
> > Need a better number reservation system. :-)
>
> Let's let Rob take OSSN-0013, and the one you are working on can be
> OSSN-0014.
>
> If we want to reserve a number, we could grab it on the OSSN wiki page
> ahead of time.  My concern with this is that  someone could grab a
> number to start writing a security note, then disappear for some time
> (or the issue takes a lot of back and forth to get through review).  In
> the meantime, other notes might be written and published.  This will
> result in the numbers being out of sequence.  It's not the end of the
> world, but it is a bit confusing.  This isn't a theoretical situation
> either, as OSSN-0010 was published after OSSN-0011 and OSSN-0012:
>
>     https://wiki.openstack.org/wiki/Security_Notes
>
> The alternative is that we assign the number at publishing time.  This
> requires more diligence at patch approval time to ensure that we don't
> duplicate a number and might require patch rework to renumber things
> (which is what we're going through right now).
>
> What preferences do others have on this?
>
> Thanks,
> -NGK
>
> > Malini
> >
> > -----Original Message-----
> > From: Clark, Robert Graham [mailto:robert.clark at hp.com]
> > Sent: Friday, May 02, 2014 1:51 AM
> > To: openstack-security at lists.openstack.org
> > Subject: [Openstack-security] OSSN-0013 ready for review
> >
> > https://review.openstack.org/#/c/91755/
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140505/0177c57e/attachment.html>

From rcritten at redhat.com  Mon May  5 21:04:08 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Mon, 05 May 2014 17:04:08 -0400
Subject: [Openstack-security] OSSN-0013 ready for review
In-Reply-To: <CAFpPvXD_NGY8j780RaUDe6hnsru4dS055ASubHLQ6yqBJuC3SQ@mail.gmail.com>
References: <CF891AF2.B2A3%robert.clark@hp.com>
 <EE6FFF4F6C34C84C8C98DD2414EEA47E72310939@fmsmsx117.amr.corp.intel.com>
 <5367EDB9.9060009@redhat.com>
 <CAFpPvXD_NGY8j780RaUDe6hnsru4dS055ASubHLQ6yqBJuC3SQ@mail.gmail.com>
Message-ID: <5367FCC8.5050008@redhat.com>

Bryan D. Payne wrote:
> I think it makes sense to assign the OSSN number as early as possible.
>   If they are published out of order... I'm not too worried about that.

Yeah, I think that would follow the CVE model as well.

rob

>
>
> On Mon, May 5, 2014 at 12:59 PM, Nathan Kinder <nkinder at redhat.com
> <mailto:nkinder at redhat.com>> wrote:
>
>
>
>     On 05/05/2014 12:39 PM, Bhandaru, Malini K wrote:
>      > We have two OSSN-0013s making their way!
>      > Need a better number reservation system. :-)
>
>     Let's let Rob take OSSN-0013, and the one you are working on can be
>     OSSN-0014.
>
>     If we want to reserve a number, we could grab it on the OSSN wiki page
>     ahead of time.  My concern with this is that  someone could grab a
>     number to start writing a security note, then disappear for some time
>     (or the issue takes a lot of back and forth to get through review).  In
>     the meantime, other notes might be written and published.  This will
>     result in the numbers being out of sequence.  It's not the end of the
>     world, but it is a bit confusing.  This isn't a theoretical situation
>     either, as OSSN-0010 was published after OSSN-0011 and OSSN-0012:
>
>     https://wiki.openstack.org/wiki/Security_Notes
>
>     The alternative is that we assign the number at publishing time.  This
>     requires more diligence at patch approval time to ensure that we don't
>     duplicate a number and might require patch rework to renumber things
>     (which is what we're going through right now).
>
>     What preferences do others have on this?
>
>     Thanks,
>     -NGK
>
>      > Malini
>      >
>      > -----Original Message-----
>      > From: Clark, Robert Graham [mailto:robert.clark at hp.com
>     <mailto:robert.clark at hp.com>]
>      > Sent: Friday, May 02, 2014 1:51 AM
>      > To: openstack-security at lists.openstack.org
>     <mailto:openstack-security at lists.openstack.org>
>      > Subject: [Openstack-security] OSSN-0013 ready for review
>      >
>      > https://review.openstack.org/#/c/91755/
>      >
>      > _______________________________________________
>      > 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
>
>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>




From robert.clark at hp.com  Mon May  5 21:06:59 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Mon, 5 May 2014 21:06:59 +0000
Subject: [Openstack-security] OSSN-0013 ready for review
In-Reply-To: <5367FCC8.5050008@redhat.com>
References: <CF891AF2.B2A3%robert.clark@hp.com>
 <EE6FFF4F6C34C84C8C98DD2414EEA47E72310939@fmsmsx117.amr.corp.intel.com>
 <5367EDB9.9060009@redhat.com>
 <CAFpPvXD_NGY8j780RaUDe6hnsru4dS055ASubHLQ6yqBJuC3SQ@mail.gmail.com>
 <5367FCC8.5050008@redhat.com>
Message-ID: <A0C170085C37664D93EE1604364858A1122EB4F6@G4W3300.americas.hpqcorp.net>

> -----Original Message-----
> From: Rob Crittenden [mailto:rcritten at redhat.com]
> Sent: 05 May 2014 22:04
> To: Bryan D. Payne; Nathan Kinder
> Cc: openstack-security at lists.openstack.org
> Subject: Re: [Openstack-security] OSSN-0013 ready for review
> 
> Bryan D. Payne wrote:
> > I think it makes sense to assign the OSSN number as early as
possible.
> >   If they are published out of order... I'm not too worried about
that.
> 
> Yeah, I think that would follow the CVE model as well.
> 
> rob

+1 No problem there. Grabbing the page on the wiki seems like an easy
way to do things.


> 
> >
> >
> > On Mon, May 5, 2014 at 12:59 PM, Nathan Kinder <nkinder at redhat.com
> > <mailto:nkinder at redhat.com>> wrote:
> >
> >
> >
> >     On 05/05/2014 12:39 PM, Bhandaru, Malini K wrote:
> >      > We have two OSSN-0013s making their way!
> >      > Need a better number reservation system. :-)
> >
> >     Let's let Rob take OSSN-0013, and the one you are working on can
be
> >     OSSN-0014.
> >
> >     If we want to reserve a number, we could grab it on the OSSN
wiki page
> >     ahead of time.  My concern with this is that  someone could grab
a
> >     number to start writing a security note, then disappear for some
time
> >     (or the issue takes a lot of back and forth to get through
review).  In
> >     the meantime, other notes might be written and published.  This
will
> >     result in the numbers being out of sequence.  It's not the end
of the
> >     world, but it is a bit confusing.  This isn't a theoretical
situation
> >     either, as OSSN-0010 was published after OSSN-0011 and
OSSN-0012:
> >
> >     https://wiki.openstack.org/wiki/Security_Notes
> >
> >     The alternative is that we assign the number at publishing time.
This
> >     requires more diligence at patch approval time to ensure that we
don't
> >     duplicate a number and might require patch rework to renumber
things
> >     (which is what we're going through right now).
> >
> >     What preferences do others have on this?
> >
> >     Thanks,
> >     -NGK
> >
> >      > Malini
> >      >
> >      > -----Original Message-----
> >      > From: Clark, Robert Graham [mailto:robert.clark at hp.com
> >     <mailto:robert.clark at hp.com>]
> >      > Sent: Friday, May 02, 2014 1:51 AM
> >      > To: openstack-security at lists.openstack.org
> >     <mailto:openstack-security at lists.openstack.org>
> >      > Subject: [Openstack-security] OSSN-0013 ready for review
> >      >
> >      > https://review.openstack.org/#/c/91755/
> >      >
> >      > _______________________________________________
> >      > 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
> >
> >
> >
> >
> > _______________________________________________
> > 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 --------------
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/20140505/cad572d7/attachment.bin>

From nkinder at redhat.com  Mon May  5 21:16:22 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Mon, 05 May 2014 14:16:22 -0700
Subject: [Openstack-security] OSSN-0013 ready for review
In-Reply-To: <A0C170085C37664D93EE1604364858A1122EB4F6@G4W3300.americas.hpqcorp.net>
References: <CF891AF2.B2A3%robert.clark@hp.com>
 <EE6FFF4F6C34C84C8C98DD2414EEA47E72310939@fmsmsx117.amr.corp.intel.com>
 <5367EDB9.9060009@redhat.com>
 <CAFpPvXD_NGY8j780RaUDe6hnsru4dS055ASubHLQ6yqBJuC3SQ@mail.gmail.com>
 <5367FCC8.5050008@redhat.com>
 <A0C170085C37664D93EE1604364858A1122EB4F6@G4W3300.americas.hpqcorp.net>
Message-ID: <5367FFA6.9010200@redhat.com>



On 05/05/2014 02:06 PM, Clark, Robert Graham wrote:
>> -----Original Message-----
>> From: Rob Crittenden [mailto:rcritten at redhat.com]
>> Sent: 05 May 2014 22:04
>> To: Bryan D. Payne; Nathan Kinder
>> Cc: openstack-security at lists.openstack.org
>> Subject: Re: [Openstack-security] OSSN-0013 ready for review
>>
>> Bryan D. Payne wrote:
>>> I think it makes sense to assign the OSSN number as early as
> possible.
>>>   If they are published out of order... I'm not too worried about
> that.
>>
>> Yeah, I think that would follow the CVE model as well.
>>
>> rob
> 
> +1 No problem there. Grabbing the page on the wiki seems like an easy
> way to do things.

Works for me.  I'll add a note to the "Security Note Process" page [1]
that covers this.  Thanks to everyone for weighing in on this.

Thanks
-NGK

[1] https://wiki.openstack.org/wiki/Security/Security_Note_Process

> 
> 
>>
>>>
>>>
>>> On Mon, May 5, 2014 at 12:59 PM, Nathan Kinder <nkinder at redhat.com
>>> <mailto:nkinder at redhat.com>> wrote:
>>>
>>>
>>>
>>>     On 05/05/2014 12:39 PM, Bhandaru, Malini K wrote:
>>>      > We have two OSSN-0013s making their way!
>>>      > Need a better number reservation system. :-)
>>>
>>>     Let's let Rob take OSSN-0013, and the one you are working on can
> be
>>>     OSSN-0014.
>>>
>>>     If we want to reserve a number, we could grab it on the OSSN
> wiki page
>>>     ahead of time.  My concern with this is that  someone could grab
> a
>>>     number to start writing a security note, then disappear for some
> time
>>>     (or the issue takes a lot of back and forth to get through
> review).  In
>>>     the meantime, other notes might be written and published.  This
> will
>>>     result in the numbers being out of sequence.  It's not the end
> of the
>>>     world, but it is a bit confusing.  This isn't a theoretical
> situation
>>>     either, as OSSN-0010 was published after OSSN-0011 and
> OSSN-0012:
>>>
>>>     https://wiki.openstack.org/wiki/Security_Notes
>>>
>>>     The alternative is that we assign the number at publishing time.
> This
>>>     requires more diligence at patch approval time to ensure that we
> don't
>>>     duplicate a number and might require patch rework to renumber
> things
>>>     (which is what we're going through right now).
>>>
>>>     What preferences do others have on this?
>>>
>>>     Thanks,
>>>     -NGK
>>>
>>>      > Malini
>>>      >
>>>      > -----Original Message-----
>>>      > From: Clark, Robert Graham [mailto:robert.clark at hp.com
>>>     <mailto:robert.clark at hp.com>]
>>>      > Sent: Friday, May 02, 2014 1:51 AM
>>>      > To: openstack-security at lists.openstack.org
>>>     <mailto:openstack-security at lists.openstack.org>
>>>      > Subject: [Openstack-security] OSSN-0013 ready for review
>>>      >
>>>      > https://review.openstack.org/#/c/91755/
>>>      >
>>>      > _______________________________________________
>>>      > 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
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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



From malini.k.bhandaru at intel.com  Tue May  6 01:38:22 2014
From: malini.k.bhandaru at intel.com (Bhandaru, Malini K)
Date: Tue, 6 May 2014 01:38:22 +0000
Subject: [Openstack-security] OSSN-0013 ready for review
In-Reply-To: <5367FFA6.9010200@redhat.com>
References: <CF891AF2.B2A3%robert.clark@hp.com>
 <EE6FFF4F6C34C84C8C98DD2414EEA47E72310939@fmsmsx117.amr.corp.intel.com>
 <5367EDB9.9060009@redhat.com>
 <CAFpPvXD_NGY8j780RaUDe6hnsru4dS055ASubHLQ6yqBJuC3SQ@mail.gmail.com>
 <5367FCC8.5050008@redhat.com>
 <A0C170085C37664D93EE1604364858A1122EB4F6@G4W3300.americas.hpqcorp.net>
 <5367FFA6.9010200@redhat.com>
Message-ID: <EE6FFF4F6C34C84C8C98DD2414EEA47E72310E67@fmsmsx117.amr.corp.intel.com>

In the wiki we could say "work in progress" .. so they do not feel they are missing an OSSN when they encounter OSSN holes.

Sure thing, I shall rename my OSSN. Please provide comments on the current one and then I shall publish for OSSN-0014.

-----Original Message-----
From: Nathan Kinder [mailto:nkinder at redhat.com] 
Sent: Monday, May 05, 2014 2:16 PM
To: Clark, Robert Graham; Rob Crittenden; Bryan D. Payne
Cc: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] OSSN-0013 ready for review



On 05/05/2014 02:06 PM, Clark, Robert Graham wrote:
>> -----Original Message-----
>> From: Rob Crittenden [mailto:rcritten at redhat.com]
>> Sent: 05 May 2014 22:04
>> To: Bryan D. Payne; Nathan Kinder
>> Cc: openstack-security at lists.openstack.org
>> Subject: Re: [Openstack-security] OSSN-0013 ready for review
>>
>> Bryan D. Payne wrote:
>>> I think it makes sense to assign the OSSN number as early as
> possible.
>>>   If they are published out of order... I'm not too worried about
> that.
>>
>> Yeah, I think that would follow the CVE model as well.
>>
>> rob
> 
> +1 No problem there. Grabbing the page on the wiki seems like an easy
> way to do things.

Works for me.  I'll add a note to the "Security Note Process" page [1] that covers this.  Thanks to everyone for weighing in on this.

Thanks
-NGK

[1] https://wiki.openstack.org/wiki/Security/Security_Note_Process

> 
> 
>>
>>>
>>>
>>> On Mon, May 5, 2014 at 12:59 PM, Nathan Kinder <nkinder at redhat.com 
>>> <mailto:nkinder at redhat.com>> wrote:
>>>
>>>
>>>
>>>     On 05/05/2014 12:39 PM, Bhandaru, Malini K wrote:
>>>      > We have two OSSN-0013s making their way!
>>>      > Need a better number reservation system. :-)
>>>
>>>     Let's let Rob take OSSN-0013, and the one you are working on can
> be
>>>     OSSN-0014.
>>>
>>>     If we want to reserve a number, we could grab it on the OSSN
> wiki page
>>>     ahead of time.  My concern with this is that  someone could grab
> a
>>>     number to start writing a security note, then disappear for some
> time
>>>     (or the issue takes a lot of back and forth to get through
> review).  In
>>>     the meantime, other notes might be written and published.  This
> will
>>>     result in the numbers being out of sequence.  It's not the end
> of the
>>>     world, but it is a bit confusing.  This isn't a theoretical
> situation
>>>     either, as OSSN-0010 was published after OSSN-0011 and
> OSSN-0012:
>>>
>>>     https://wiki.openstack.org/wiki/Security_Notes
>>>
>>>     The alternative is that we assign the number at publishing time.
> This
>>>     requires more diligence at patch approval time to ensure that we
> don't
>>>     duplicate a number and might require patch rework to renumber
> things
>>>     (which is what we're going through right now).
>>>
>>>     What preferences do others have on this?
>>>
>>>     Thanks,
>>>     -NGK
>>>
>>>      > Malini
>>>      >
>>>      > -----Original Message-----
>>>      > From: Clark, Robert Graham [mailto:robert.clark at hp.com
>>>     <mailto:robert.clark at hp.com>]
>>>      > Sent: Friday, May 02, 2014 1:51 AM
>>>      > To: openstack-security at lists.openstack.org
>>>     <mailto:openstack-security at lists.openstack.org>
>>>      > Subject: [Openstack-security] OSSN-0013 ready for review
>>>      >
>>>      > https://review.openstack.org/#/c/91755/
>>>      >
>>>      > _______________________________________________
>>>      > 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
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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-securit
>> y

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



From 1316271 at bugs.launchpad.net  Mon May  5 19:02:22 2014
From: 1316271 at bugs.launchpad.net (David Hill)
Date: Mon, 05 May 2014 19:02:22 -0000
Subject: [Openstack-security] [Bug 1316271] [NEW] Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140505190222.27207.36590.malonedeb@gac.canonical.com>

*** This bug is a security vulnerability ***

Public security bug reported:

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

** Affects: nova
     Importance: Undecided
         Status: New


** Tags: iptables nova nova-network security

** Information type changed from Private Security to Public 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/1316271

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

Status in OpenStack Compute (Nova):
  New

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 1316271 at bugs.launchpad.net  Mon May  5 19:23:59 2014
From: 1316271 at bugs.launchpad.net (David Hill)
Date: Mon, 05 May 2014 19:23:59 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140505192359.24847.13173.malone@wampee.canonical.com>

We could add a default boolean that would be false by default before
pushing this to trunk ... The effect of this patch would be the
following:

Chain nova-network-FORWARD (1 references)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     tcp  --  0.0.0.0/0            x.x.x.x          tcp dpt:8775
DROP       all  --  0.0.0.0/0            x.x.x.x

Chain nova-network-INPUT (1 references)
target     prot opt source               destination
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:67
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:67
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:53
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:53
ACCEPT     tcp  --  0.0.0.0/0            x.x.x.x          tcp dpt:8775
DROP       all  --  0.0.0.0/0            x.x.x.x

Instead of:
Chain nova-network-FORWARD (1 references)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     tcp  --  0.0.0.0/0            10.30.96.8          tcp dpt:8775

Chain nova-network-INPUT (1 references)
target     prot opt source               destination
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:67
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:67
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:53
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:53


** Tags added: ssh

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

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 thierry.carrez+lp at gmail.com  Tue May  6 14:07:02 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Tue, 06 May 2014 14:07:02 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140506140703.21490.49879.launchpad@chaenomeles.canonical.com>

** Also affects: ossa
   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/1316271

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

Status in OpenStack Compute (Nova):
  New
Status in OpenStack Security Advisories:
  New

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 thierry.carrez+lp at gmail.com  Tue May  6 14:49:05 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Tue, 06 May 2014 14:49:05 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140506144908.23765.7952.launchpad@wampee.canonical.com>

** Changed in: ossa
       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/1316271

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

Status in OpenStack Compute (Nova):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 1289033 at bugs.launchpad.net  Tue May  6 14:59:27 2014
From: 1289033 at bugs.launchpad.net (Launchpad Bug Tracker)
Date: Tue, 06 May 2014 14:59:27 -0000
Subject: [Openstack-security] [Bug 1289033] Re: [OSSA-2014-010] XSS in
 Horizon-Orchestration (CVE-2014-0157)
References: <20140306223232.13317.99583.malonedeb@gac.canonical.com>
Message-ID: <20140506145928.29549.9960.launchpad@ackee.canonical.com>

** Branch linked: lp:ubuntu/saucy-security/horizon

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

Title:
  [OSSA-2014-010] XSS in Horizon-Orchestration (CVE-2014-0157)

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

Bug description:
  *Description*
  XSS vulnerability identified in Horizon-Orchestration while uploading a stack template.
  Arbitrary Javascript code may be introduced via the "Description" fields of Heat templates; such code was found to be executed by Horizon.

  *Threat Description*
  -Potential Adversaries: malicious Heat templates owners/malicious Heat templates catalogs.
  -Potential Assets: horizon user/admin access credentials (session cookies/CSRF tokens), VMs/Network configuration/management, tenants confidential informartion, etc.
  -Potential Threats: Malicious Heat template owner/catalog makes an Horizon user to utilize a malicious template, which once introduced in Horizon obtains user access credentials and send them back to the attacker. 

  *Environment*
  One node with Devstack over Ubuntu13.10, latest Icehouse code, Firefox web browser and the following OpenStack configuration:
  shell, key, horizon, g-reg, g-api, n-api, n-cpu, n-cond, n-crt, n-net, n-sch, n-novnc, n-xvnc, n-cauth, n-obj, c-api, c-sch, c-vol, ceilometer-acompute, ceilometer-acentral, ceilometer-collector, ceilometer-api, ceilometer-alarm-notifier, ceilometer-alarm-evaluator, h-eng, h-api, h-api-cfn, h-api-cw  

  *Steps to reproduce*
  1- Sign-in to Horizon and click on Orchestration/Stack section.
  2- Click on "Launch Stack"
  3- Select "Direct input", and copy-paste into "Template data" the contents of some template (I have used: 
  https://github.com/openstack/heat-templates/blob/master/cfn/F17/AutoScalingMultiAZSample.template)
  4- Update the contents of the DBUsername "Description" field with the following:
     "DBUsername": {
  	...
        "Description" : "<script>alert('XSS!!!')</script>",
  	...
      },
  5- Click on Next
  6- Being on the Launch Stack form, click on DBUsername text box as if you were going to modify its value.
  7- A pop-up saying "XSS!!!" will appear, confirming the XSS vulnerability.

  *How to fix*
  - Perform input validation for "Description" fields in templates (need to take into account all template input methods: upload from URL, upload from file, direct input).
  - Perform output sanitization when displaying template's "Description" messages.

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



From 1316271 at bugs.launchpad.net  Tue May  6 15:29:26 2014
From: 1316271 at bugs.launchpad.net (David Hill)
Date: Tue, 06 May 2014 15:29:26 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140506152926.20585.39450.malone@gac.canonical.com>

What's missing?

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 tristan.cacqueray at enovance.com  Tue May  6 15:38:57 2014
From: tristan.cacqueray at enovance.com (Tristan Cacqueray)
Date: Tue, 06 May 2014 15:38:57 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140506153857.22520.88721.malone@soybean.canonical.com>

@David, the advisory task is incomplete pending additional details from
security reviewers (nova-coresec team).

For your information, the process is described there:
https://wiki.openstack.org/wiki/VulnerabilityManagement#Reception

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 1316271 at bugs.launchpad.net  Tue May  6 22:13:05 2014
From: 1316271 at bugs.launchpad.net (David Hill)
Date: Tue, 06 May 2014 22:13:05 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140506221305.22072.34681.malone@soybean.canonical.com>

For some reasons, dhcp needs to talk with loopback...

--- linux_net.py.orig   2014-05-06 15:22:13.525362875 +0000
+++ linux_net.py        2014-05-06 22:01:42.914944165 +0000
@@ -808,6 +808,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 ! -i lo '
+                                             '-j DROP' % network_ref['dhcp_server'])
+    iptables_manager.ipv4['filter'].add_rule('FORWARD',
+                                             '-d %s ! -i lo '
+                                             '-j DROP' % network_ref['dhcp_server'])
+    iptables_manager.apply()
+
 def initialize_gateway_device(dev, network_ref):
     if not network_ref:
         return
@@ -1049,6 +1067,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)
@@ -1101,6 +1120,7 @@

     _add_dnsmasq_accept_rules(dev)

+    isolate_compute_from_guest(network_ref)

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

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 May  7 00:55:26 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 07 May 2014 00:55:26 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1Whq8s-0001mR-BL@review.openstack.org>


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

Log:
commit da9fca124ab59ca9d61f7d9111455fed2f4bbeb8
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue May 6 19:36:59 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From 1174499 at bugs.launchpad.net  Wed May  7 00:55:30 2014
From: 1174499 at bugs.launchpad.net (Openstack Gerrit)
Date: Wed, 07 May 2014 00:55:30 -0000
Subject: [Openstack-security] [Bug 1174499] Related fix proposed to
	python-keystoneclient (master)
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140507005530.20585.38753.malone@gac.canonical.com>

Related fix proposed to branch: master
Review: https://review.openstack.org/92499

-- 
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 OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (Keystone):
  Fix Committed
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  In Progress

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/horizon/+bug/1174499/+subscriptions



From 1316271 at bugs.launchpad.net  Wed May  7 15:38:38 2014
From: 1316271 at bugs.launchpad.net (David Hill)
Date: Wed, 07 May 2014 15:38:38 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140507153839.24363.22152.malone@wampee.canonical.com>

Nova is using dhcp_release in order to communicate with the DHCP server
to release the IP address so ! -i lo addresses this issue.

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 May  7 16:15:45 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 07 May 2014 16:15:45 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1Wi4VV-0004c6-0Z@review.openstack.org>


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

Log:
commit b06a4ddf1a6e2c5feb8266b312a9f2461875894b
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue May 6 19:36:59 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From robert.clark at hp.com  Thu May  8 09:10:44 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Thu, 8 May 2014 09:10:44 +0000
Subject: [Openstack-security] Certificate life in OpenStack
Message-ID: <A0C170085C37664D93EE1604364858A1122EDBB2@G4W3300.americas.hpqcorp.net>

We are looking at various appliocations of short-life certificates in
OpenStack, an idea I've discussed with a few members of the OpenStack
Security Group previously.

Has anyone done any analysis on what the shortest lifespan you can
generally get away with, or to put it another way, what's the longest
operation that ever happens with an individual certificate?

I'm sure this will vary by service but very curious to see what others
have done.

-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/20140508/8289a51f/attachment.bin>

From d.w.chadwick at kent.ac.uk  Thu May  8 09:51:32 2014
From: d.w.chadwick at kent.ac.uk (David Chadwick)
Date: Thu, 08 May 2014 10:51:32 +0100
Subject: [Openstack-security] Certificate life in OpenStack
In-Reply-To: <A0C170085C37664D93EE1604364858A1122EDBB2@G4W3300.americas.hpqcorp.net>
References: <A0C170085C37664D93EE1604364858A1122EDBB2@G4W3300.americas.hpqcorp.net>
Message-ID: <536B53A4.2030504@kent.ac.uk>

I dont think there is a correct answer to this. In general you have to
pick a time (any time) that will cater for the majority of transactions,
and then have some sort of refresh mechanism for those that are longer
than this. If you pick too long a time then people will start to ask for
a revocation facility (as happened in the grid for proxy certificates),
which negates the point of having short lived certificates in the first
place

regards

David

On 08/05/2014 10:10, Clark, Robert Graham wrote:
> We are looking at various appliocations of short-life certificates in
> OpenStack, an idea I've discussed with a few members of the OpenStack
> Security Group previously.
> 
> Has anyone done any analysis on what the shortest lifespan you can
> generally get away with, or to put it another way, what's the longest
> operation that ever happens with an individual certificate?
> 
> I'm sure this will vary by service but very curious to see what others
> have done.
> 
> -Rob
> 
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 



From robert.clark at hp.com  Thu May  8 12:23:04 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Thu, 8 May 2014 12:23:04 +0000
Subject: [Openstack-security] Reminder: No OSSG meeting today
Message-ID: <A0C170085C37664D93EE1604364858A1122EDD6C@G4W3300.americas.hpqcorp.net>

EOM.

-------------- 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/20140508/e896c9f0/attachment.bin>

From nkinder at redhat.com  Thu May  8 15:40:34 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Thu, 08 May 2014 15:40:34 -0000
Subject: [Openstack-security] [Bug 1260679] Re: Multiple drivers set
	insecure file permissions
References: <20131213105542.17101.92136.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140508154036.22231.35238.launchpad@soybean.canonical.com>

** Changed in: ossn
       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/1260679

Title:
  Multiple drivers set insecure file permissions

Status in Cinder:
  In Progress
Status in OpenStack Security Notes:
  In Progress

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 nkinder at redhat.com  Thu May  8 16:47:23 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Thu, 08 May 2014 09:47:23 -0700
Subject: [Openstack-security] OSSN-0013 ready for review
In-Reply-To: <EE6FFF4F6C34C84C8C98DD2414EEA47E72310E67@fmsmsx117.amr.corp.intel.com>
References: <CF891AF2.B2A3%robert.clark@hp.com>
 <EE6FFF4F6C34C84C8C98DD2414EEA47E72310939@fmsmsx117.amr.corp.intel.com>
 <5367EDB9.9060009@redhat.com>
 <CAFpPvXD_NGY8j780RaUDe6hnsru4dS055ASubHLQ6yqBJuC3SQ@mail.gmail.com>
 <5367FCC8.5050008@redhat.com>
 <A0C170085C37664D93EE1604364858A1122EB4F6@G4W3300.americas.hpqcorp.net>
 <5367FFA6.9010200@redhat.com>
 <EE6FFF4F6C34C84C8C98DD2414EEA47E72310E67@fmsmsx117.amr.corp.intel.com>
Message-ID: <536BB51B.3000206@redhat.com>



On 05/05/2014 06:38 PM, Bhandaru, Malini K wrote:
> In the wiki we could say "work in progress" .. so they do not feel they are missing an OSSN when they encounter OSSN holes.

I've gone ahead and outlined this procedure on the Security Note process
page here:

https://wiki.openstack.org/wiki/Security/Security_Note_Process#Number_Assignment

Thanks,
-NGK

> 
> Sure thing, I shall rename my OSSN. Please provide comments on the current one and then I shall publish for OSSN-0014.
> 
> -----Original Message-----
> From: Nathan Kinder [mailto:nkinder at redhat.com] 
> Sent: Monday, May 05, 2014 2:16 PM
> To: Clark, Robert Graham; Rob Crittenden; Bryan D. Payne
> Cc: openstack-security at lists.openstack.org
> Subject: Re: [Openstack-security] OSSN-0013 ready for review
> 
> 
> 
> On 05/05/2014 02:06 PM, Clark, Robert Graham wrote:
>>> -----Original Message-----
>>> From: Rob Crittenden [mailto:rcritten at redhat.com]
>>> Sent: 05 May 2014 22:04
>>> To: Bryan D. Payne; Nathan Kinder
>>> Cc: openstack-security at lists.openstack.org
>>> Subject: Re: [Openstack-security] OSSN-0013 ready for review
>>>
>>> Bryan D. Payne wrote:
>>>> I think it makes sense to assign the OSSN number as early as
>> possible.
>>>>   If they are published out of order... I'm not too worried about
>> that.
>>>
>>> Yeah, I think that would follow the CVE model as well.
>>>
>>> rob
>>
>> +1 No problem there. Grabbing the page on the wiki seems like an easy
>> way to do things.
> 
> Works for me.  I'll add a note to the "Security Note Process" page [1] that covers this.  Thanks to everyone for weighing in on this.
> 
> Thanks
> -NGK
> 
> [1] https://wiki.openstack.org/wiki/Security/Security_Note_Process
> 
>>
>>
>>>
>>>>
>>>>
>>>> On Mon, May 5, 2014 at 12:59 PM, Nathan Kinder <nkinder at redhat.com 
>>>> <mailto:nkinder at redhat.com>> wrote:
>>>>
>>>>
>>>>
>>>>     On 05/05/2014 12:39 PM, Bhandaru, Malini K wrote:
>>>>      > We have two OSSN-0013s making their way!
>>>>      > Need a better number reservation system. :-)
>>>>
>>>>     Let's let Rob take OSSN-0013, and the one you are working on can
>> be
>>>>     OSSN-0014.
>>>>
>>>>     If we want to reserve a number, we could grab it on the OSSN
>> wiki page
>>>>     ahead of time.  My concern with this is that  someone could grab
>> a
>>>>     number to start writing a security note, then disappear for some
>> time
>>>>     (or the issue takes a lot of back and forth to get through
>> review).  In
>>>>     the meantime, other notes might be written and published.  This
>> will
>>>>     result in the numbers being out of sequence.  It's not the end
>> of the
>>>>     world, but it is a bit confusing.  This isn't a theoretical
>> situation
>>>>     either, as OSSN-0010 was published after OSSN-0011 and
>> OSSN-0012:
>>>>
>>>>     https://wiki.openstack.org/wiki/Security_Notes
>>>>
>>>>     The alternative is that we assign the number at publishing time.
>> This
>>>>     requires more diligence at patch approval time to ensure that we
>> don't
>>>>     duplicate a number and might require patch rework to renumber
>> things
>>>>     (which is what we're going through right now).
>>>>
>>>>     What preferences do others have on this?
>>>>
>>>>     Thanks,
>>>>     -NGK
>>>>
>>>>      > Malini
>>>>      >
>>>>      > -----Original Message-----
>>>>      > From: Clark, Robert Graham [mailto:robert.clark at hp.com
>>>>     <mailto:robert.clark at hp.com>]
>>>>      > Sent: Friday, May 02, 2014 1:51 AM
>>>>      > To: openstack-security at lists.openstack.org
>>>>     <mailto:openstack-security at lists.openstack.org>
>>>>      > Subject: [Openstack-security] OSSN-0013 ready for review
>>>>      >
>>>>      > https://review.openstack.org/#/c/91755/
>>>>      >
>>>>      > _______________________________________________
>>>>      > 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
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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-securit
>>> y
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 



From 1315556 at bugs.launchpad.net  Fri May  9 15:38:45 2014
From: 1315556 at bugs.launchpad.net (Guang Yee)
Date: Fri, 09 May 2014 15:38:45 -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: <20140509153846.20461.55520.launchpad@gac.canonical.com>

** Changed in: keystone
     Assignee: (unassigned) => Guang Yee (guang-yee)

-- 
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):
  Triaged

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 ayoung at redhat.com  Fri May  9 19:51:35 2014
From: ayoung at redhat.com (Adam Young)
Date: Fri, 09 May 2014 15:51:35 -0400
Subject: [Openstack-security] Certificate life in OpenStack
In-Reply-To: <536B53A4.2030504@kent.ac.uk>
References: <A0C170085C37664D93EE1604364858A1122EDBB2@G4W3300.americas.hpqcorp.net>
 <536B53A4.2030504@kent.ac.uk>
Message-ID: <536D31C7.6000000@redhat.com>

On 05/08/2014 05:51 AM, David Chadwick wrote:
> I dont think there is a correct answer to this. In general you have to
> pick a time (any time) that will cater for the majority of transactions,
> and then have some sort of refresh mechanism for those that are longer
> than this. If you pick too long a time then people will start to ask for
> a revocation facility (as happened in the grid for proxy certificates),
> which negates the point of having short lived certificates in the first
> place
>
> regards

I'd like to make the distinction between Authentication and 
Authorization here.   Certificates really should be just used for 
Authentication, with another server performing authorization work.

David has much more specific language for this, but keeping it in terms 
of Keystone:  certificates should be relatively long lived. Tokens are 
short lived.  What David said about proxy certs is true for Keystone 
tokens as well.

Keystone's job is to enforce short duration confirmation of attributes 
specific to OpenStack that can be used to check policy at a decision 
point.  It is the lifetime of these attributes that should be considered 
ephemeral.

Certificates currently are used for SSL and Keystone token signing. In 
both these cases, we would be wise to add on CRL checking (OCSP is 
possible, but probably not right for OpenStack, as we tend to need bulk).




>
> David
>
> On 08/05/2014 10:10, Clark, Robert Graham wrote:
>> We are looking at various appliocations of short-life certificates in
>> OpenStack, an idea I've discussed with a few members of the OpenStack
>> Security Group previously.
>>
>> Has anyone done any analysis on what the shortest lifespan you can
>> generally get away with, or to put it another way, what's the longest
>> operation that ever happens with an individual certificate?
>>
>> I'm sure this will vary by service but very curious to see what others
>> have done.
>>
>> -Rob
>>
>>
>>
>> _______________________________________________
>> 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




From d.w.chadwick at kent.ac.uk  Sat May 10 07:18:01 2014
From: d.w.chadwick at kent.ac.uk (David Chadwick)
Date: Sat, 10 May 2014 08:18:01 +0100
Subject: [Openstack-security] Certificate life in OpenStack
In-Reply-To: <536D31C7.6000000@redhat.com>
References: <A0C170085C37664D93EE1604364858A1122EDBB2@G4W3300.americas.hpqcorp.net>
 <536B53A4.2030504@kent.ac.uk> <536D31C7.6000000@redhat.com>
Message-ID: <536DD2A9.6040304@kent.ac.uk>

I think there is no agreed naming to differentiate between authn and
authz tokens/certificates/claims/assertions, and in protocols such as
SAML, the token/certificate/claim/assertion performs both authn and
authz tasks, which makes it even more unclear.

We could agree on different names for use within the Openstack|Keystone
domain for the authn and authz blobs, but I dont think that would be
necessarily helpful. Rather context could imply which one you are
talking about, or alternatively the adjectives authn and authz could be
used to differentiate when context is insufficient.

regards

David


On 09/05/2014 20:51, Adam Young wrote:
> On 05/08/2014 05:51 AM, David Chadwick wrote:
>> I dont think there is a correct answer to this. In general you have to
>> pick a time (any time) that will cater for the majority of transactions,
>> and then have some sort of refresh mechanism for those that are longer
>> than this. If you pick too long a time then people will start to ask for
>> a revocation facility (as happened in the grid for proxy certificates),
>> which negates the point of having short lived certificates in the first
>> place
>>
>> regards
> 
> I'd like to make the distinction between Authentication and
> Authorization here.   Certificates really should be just used for
> Authentication, with another server performing authorization work.
> 
> David has much more specific language for this, but keeping it in terms
> of Keystone:  certificates should be relatively long lived. Tokens are
> short lived.  What David said about proxy certs is true for Keystone
> tokens as well.
> 
> Keystone's job is to enforce short duration confirmation of attributes
> specific to OpenStack that can be used to check policy at a decision
> point.  It is the lifetime of these attributes that should be considered
> ephemeral.
> 
> Certificates currently are used for SSL and Keystone token signing. In
> both these cases, we would be wise to add on CRL checking (OCSP is
> possible, but probably not right for OpenStack, as we tend to need bulk).
> 
> 
> 
> 
>>
>> David
>>
>> On 08/05/2014 10:10, Clark, Robert Graham wrote:
>>> We are looking at various appliocations of short-life certificates in
>>> OpenStack, an idea I've discussed with a few members of the OpenStack
>>> Security Group previously.
>>>
>>> Has anyone done any analysis on what the shortest lifespan you can
>>> generally get away with, or to put it another way, what's the longest
>>> operation that ever happens with an individual certificate?
>>>
>>> I'm sure this will vary by service but very curious to see what others
>>> have done.
>>>
>>> -Rob
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
> 



From bdpayne at acm.org  Mon May 12 03:41:48 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Sun, 11 May 2014 23:41:48 -0400
Subject: [Openstack-security] OSSG Lunch at Atlanta Summit
In-Reply-To: <CAFpPvXCEAhHWUD7aEBAS0PGiK1cuJKEtK9_UKPWSpxUKF6ZRpg@mail.gmail.com>
References: <CAFpPvXCEAhHWUD7aEBAS0PGiK1cuJKEtK9_UKPWSpxUKF6ZRpg@mail.gmail.com>
Message-ID: <CAFpPvXCAzhGUgyeQDiuncQ4wSp9ktu5BQx8bHVMX_asnRb-8eg@mail.gmail.com>

Welcome to Atlanta everyone!

I'd like to get a headcount for the Thursday OSSG lunch so that I can
choose an appropriate restaurant and make a reservation.  Please RSVP by
replying _just to me_ (no need to spam the list) no later than 5p on
Tuesday evening.

Thanks!
-bryan




On Thu, May 1, 2014 at 8:25 PM, Bryan D. Payne <bdpayne at acm.org> wrote:

> With the summit just around the corner, I wanted to ensure that we set
> aside a time for OSSG to meet while in Atlanta.  So, please mark your
> calendars:
>
> When: Thursday May 15 @ 12:30p
> Location: TBD but near the GWCC, I'll send out an update via email
>
> I realize that there are Keystone sessions on either side of this lunch
> slot.  Even so, this appears to be the best option all around.  For people
> involved in Keystone, I encourage you to join us for as long as you can!
>
> I know that OSSG has lots to discuss during the week.  This lunch can be a
> working lunch, but I hope that it also somewhat social.  Let's try to
> coordinate some other meeting times during the week to discuss specific
> topics of interest to the OSSG community.  Watch for other emails
> coordinating those.
>
> More details on the lunch will be coming over the next week!
>
> Cheers,
> -bryan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140511/aa3dbdf5/attachment.html>

From noloader at gmail.com  Mon May 12 05:37:40 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 12 May 2014 01:37:40 -0400
Subject: [Openstack-security] Certificate life in OpenStack
In-Reply-To: <A0C170085C37664D93EE1604364858A1122EDBB2@G4W3300.americas.hpqcorp.net>
References: <A0C170085C37664D93EE1604364858A1122EDBB2@G4W3300.americas.hpqcorp.net>
Message-ID: <CAH8yC8k0F5SvTmdTapbySY6JGxFewuf4GwFYs6owVoUGwyZBDw@mail.gmail.com>

On Thu, May 8, 2014 at 5:10 AM, Clark, Robert Graham
<robert.clark at hp.com> wrote:
> We are looking at various appliocations of short-life certificates in
> OpenStack, an idea I've discussed with a few members of the OpenStack
> Security Group previously.
>
> Has anyone done any analysis on what the shortest lifespan you can
> generally get away with, or to put it another way, what's the longest
> operation that ever happens with an individual certificate?
>
> I'm sure this will vary by service but very curious to see what others
> have done.

The longest operation seems like its a critical parameter here.
Because of the triple-handshake vulnerability (CVE-2014-1295), some
(all?) implementations bind old and new sessions. In the case of
Apple, I believe they require certificate continuity. If the
certificate changes, then that could disrupt a service. (I can only
say "could" because I'm not sure how certificate continuity is being
measured).

Jeff



From noloader at gmail.com  Mon May 12 08:33:47 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 12 May 2014 04:33:47 -0400
Subject: [Openstack-security] Certificate life in OpenStack
In-Reply-To: <536D31C7.6000000@redhat.com>
References: <A0C170085C37664D93EE1604364858A1122EDBB2@G4W3300.americas.hpqcorp.net>
 <536B53A4.2030504@kent.ac.uk> <536D31C7.6000000@redhat.com>
Message-ID: <CAH8yC8nRnwyvkZQ1_TtCDDYsqhdY5axseB4esoXG2K-Adk_+_Q@mail.gmail.com>

On Fri, May 9, 2014 at 3:51 PM, Adam Young <ayoung at redhat.com> wrote:
> On 05/08/2014 05:51 AM, David Chadwick wrote:
>>
>> I dont think there is a correct answer to this. In general you have to
>> pick a time (any time) that will cater for the majority of transactions,
>> and then have some sort of refresh mechanism for those that are longer
>> than this. If you pick too long a time then people will start to ask for
>> a revocation facility (as happened in the grid for proxy certificates),
>> which negates the point of having short lived certificates in the first
>> place
>
> ...
> David has much more specific language for this, but keeping it in terms of
> Keystone:  certificates should be relatively long lived. Tokens are short
> lived.  What David said about proxy certs is true for Keystone tokens as
> well.
What is the lifetime of the assertion made by Keystone? I just went
through the OpenStack Security Guide (http://docs.openstack.org/sec/),
and I did not see a treatment on the subject.

Related: can a service, such as Nova, reach back and ask Keystone if a
user is still valid (and hence infer if the token is still valid)?
Here, the service is a relying party.

If the token is long-lived *and* Keystone cannot be queried, then all
we know is some user was authenticated at some time in the past. 2
hours in the past is not too bad, but 28 days in the past might leave
something to be desired. Its the same kind of architectural defect
incumbent to code signing.

> Keystone's job is to enforce short duration confirmation of attributes
> specific to OpenStack that can be used to check policy at a decision point.
> It is the lifetime of these attributes that should be considered ephemeral.

State of the Project Keystone
(https://www.youtube.com/watch?v=jdmUbBgd_1g) states its up to the
various services to perform entitlement and authorization checks. What
does "enforce short duration confirmation of attributes" mean?

> Certificates currently are used for SSL and Keystone token signing. In both
> these cases, we would be wise to add on CRL checking (OCSP is possible, but
> probably not right for OpenStack, as we tend to need bulk).

OCSP has its own set of problems. See, for example, Gutmann's
Engineering Security
(https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf), Chapter 8,
PKI. Online Revocation Authorities, Problems with OCSP, pp. 643 - 648.

How about SPKI-like validations and revalidations? See
http://tools.ietf.org/html/rfc2693.

Jeff



From nkinder at redhat.com  Mon May 12 14:38:18 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Mon, 12 May 2014 10:38:18 -0400
Subject: [Openstack-security] Certificate life in OpenStack
In-Reply-To: <CAH8yC8nRnwyvkZQ1_TtCDDYsqhdY5axseB4esoXG2K-Adk_+_Q@mail.gmail.com>
References: <A0C170085C37664D93EE1604364858A1122EDBB2@G4W3300.americas.hpqcorp.net>
 <536B53A4.2030504@kent.ac.uk> <536D31C7.6000000@redhat.com>
 <CAH8yC8nRnwyvkZQ1_TtCDDYsqhdY5axseB4esoXG2K-Adk_+_Q@mail.gmail.com>
Message-ID: <5370DCDA.1040903@redhat.com>



On 05/12/2014 04:33 AM, Jeffrey Walton wrote:
> On Fri, May 9, 2014 at 3:51 PM, Adam Young <ayoung at redhat.com> wrote:
>> On 05/08/2014 05:51 AM, David Chadwick wrote:
>>>
>>> I dont think there is a correct answer to this. In general you have to
>>> pick a time (any time) that will cater for the majority of transactions,
>>> and then have some sort of refresh mechanism for those that are longer
>>> than this. If you pick too long a time then people will start to ask for
>>> a revocation facility (as happened in the grid for proxy certificates),
>>> which negates the point of having short lived certificates in the first
>>> place
>>
>> ...
>> David has much more specific language for this, but keeping it in terms of
>> Keystone:  certificates should be relatively long lived. Tokens are short
>> lived.  What David said about proxy certs is true for Keystone tokens as
>> well.
> What is the lifetime of the assertion made by Keystone? I just went
> through the OpenStack Security Guide (http://docs.openstack.org/sec/),
> and I did not see a treatment on the subject.

In Havana, the default token validity duration was 24 hours.  In
Icehouse, that was changed to 1 hour.  The duration is configurable, so
it can be tuned to whatever value is deemed appropriate for a particular
deployment.

> 
> Related: can a service, such as Nova, reach back and ask Keystone if a
> user is still valid (and hence infer if the token is still valid)?
> Here, the service is a relying party.

That's how the old UUID tokens worked.  With PKI tokens, Keystone does
not need to be involved with the validation of tokens.  A service is
able to validate the token signature to ensure it was really issued by
Keystone, then it can check if it is still valid.  I don't think you
want to funnel all validation through Keystone, as it would be a
bottleneck.  Token revocation would be able to handle situations where
you can't wait until the token validity expires.

> 
> If the token is long-lived *and* Keystone cannot be queried, then all
> we know is some user was authenticated at some time in the past. 2
> hours in the past is not too bad, but 28 days in the past might leave
> something to be desired. Its the same kind of architectural defect
> incumbent to code signing.
> 
>> Keystone's job is to enforce short duration confirmation of attributes
>> specific to OpenStack that can be used to check policy at a decision point.
>> It is the lifetime of these attributes that should be considered ephemeral.
> 
> State of the Project Keystone
> (https://www.youtube.com/watch?v=jdmUbBgd_1g) states its up to the
> various services to perform entitlement and authorization checks. What
> does "enforce short duration confirmation of attributes" mean?
> 
>> Certificates currently are used for SSL and Keystone token signing. In both
>> these cases, we would be wise to add on CRL checking (OCSP is possible, but
>> probably not right for OpenStack, as we tend to need bulk).
> 
> OCSP has its own set of problems. See, for example, Gutmann's
> Engineering Security
> (https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf), Chapter 8,
> PKI. Online Revocation Authorities, Problems with OCSP, pp. 643 - 648.
> 
> How about SPKI-like validations and revalidations? See
> http://tools.ietf.org/html/rfc2693.

Adam was referring to actual x.509 certificates and how they are used
today, not Keystone tokens.  I'm not sure if your comments were thinking
of something like OCSP for tokens, or for the certificates used to
enable SSL for the Keystone API endpoint or token signing.

Tokens can be revoked in Keystone, and the services can basically use a
CRL like concept to see if tokens have been revoked when validating them.

Thanks,
-NGK
> 
> Jeff
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 



From robert.clark at hp.com  Mon May 12 18:12:34 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Mon, 12 May 2014 18:12:34 +0000
Subject: [Openstack-security] OSSN Cadence
Message-ID: <CF968751.BF26%robert.clark@hp.com>

Nathan gave a great talk on OSSNs today, we went from 3 OSSNs in the last release to 10 in the current release.

I’d like to continue this upward trend in the next release, I think that the new processes in place have made contributing easier and greatly improved the quality of our OSSNs.

So, Ideas and suggestions for ramping up OSSNs?



From robert.clark at hp.com  Mon May 12 21:20:54 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Mon, 12 May 2014 21:20:54 +0000
Subject: [Openstack-security] Security Guide :: Certificate management in
	OpenStack?
Message-ID: <CF96B375.C029%robert.clark@hp.com>

Hi All

During the talks today I noticed a number of certificate management questions, I counted 4-5 in three talks, I think perhaps there’s a need to improve the guidance here, maybe as part of the security guide?

-Rob



From robert.clark at hp.com  Mon May 12 21:26:22 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Mon, 12 May 2014 21:26:22 +0000
Subject: [Openstack-security] OSSN Cadence
In-Reply-To: <CAFpPvXDtKNc5OeOm7JChcNq4j_Q0kfVYC2ceOs_zDawvjQer+A@mail.gmail.com>
Message-ID: <CF96B100.C001%robert.clark@hp.com>

Agreed but how do we get to that, I know when we were talking about starting the OSSN process Theirry envisioned publishing something in the order or one per week which I think would be attainable – certainly there are enough defects/issues to do this – thoughts?



From: "Bryan D. Payne" <bryan at thepaynes.cc<mailto:bryan at thepaynes.cc>>
Date: Mon, 12 May 2014 13:50:15 -0700
To: Robert Clark <robert.clark at hp.com<mailto:robert.clark at hp.com>>
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] OSSN Cadence


Step 1 ... We need more OSSN bugs files with topic ideas.

-bryan

On May 12, 2014 2:13 PM, "Clark, Robert Graham" <robert.clark at hp.com<mailto:robert.clark at hp.com>> wrote:
Nathan gave a great talk on OSSNs today, we went from 3 OSSNs in the last release to 10 in the current release.

I’d like to continue this upward trend in the next release, I think that the new processes in place have made contributing easier and greatly improved the quality of our OSSNs.

So, Ideas and suggestions for ramping up OSSNs?

_______________________________________________
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



From nkinder at redhat.com  Tue May 13 04:20:30 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Tue, 13 May 2014 00:20:30 -0400
Subject: [Openstack-security] OSSN Cadence
In-Reply-To: <CF96B100.C001%robert.clark@hp.com>
References: <CF96B100.C001%robert.clark@hp.com>
Message-ID: <53719D8E.4090508@redhat.com>



On 05/12/2014 05:26 PM, Clark, Robert Graham wrote:
> Agreed but how do we get to that, I know when we were talking about starting the OSSN process Theirry envisioned publishing something in the order or one per week which I think would be attainable – certainly there are enough defects/issues to do this – thoughts?

Thus far, it seems like the majority of the OSSN bugs originate from
issues that the VMT evaluates and determines that they aren't worthy of
being an OSSA.  Instead of relying on this being the main source of
OSSNs, I think we need to look at the incoming 'SecurityImpact' bugs to
determine what qualifies as an issue worthy of a new OSSN.  We receive
notification of plenty of bugs with the 'SecurityImpact' tag set, so I
think we just need to be more diligent in looking at them to determine
if an OSSN would be useful.

-NGK

> 
> 
> 
> From: "Bryan D. Payne" <bryan at thepaynes.cc<mailto:bryan at thepaynes.cc>>
> Date: Mon, 12 May 2014 13:50:15 -0700
> To: Robert Clark <robert.clark at hp.com<mailto:robert.clark at hp.com>>
> 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] OSSN Cadence
> 
> 
> Step 1 ... We need more OSSN bugs files with topic ideas.
> 
> -bryan
> 
> On May 12, 2014 2:13 PM, "Clark, Robert Graham" <robert.clark at hp.com<mailto:robert.clark at hp.com>> wrote:
> Nathan gave a great talk on OSSNs today, we went from 3 OSSNs in the last release to 10 in the current release.
> 
> I’d like to continue this upward trend in the next release, I think that the new processes in place have made contributing easier and greatly improved the quality of our OSSNs.
> 
> So, Ideas and suggestions for ramping up OSSNs?
> 
> _______________________________________________
> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 



From gerrit2 at review.openstack.org  Wed May 14 14:08:30 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 14 May 2014 14:08:30 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WkZrC-00032h-Gb@review.openstack.org>


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

Log:
commit af1960ef28e3548654e75abd222c7ea5e6d7660e
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue May 6 19:36:59 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From gerrit2 at review.openstack.org  Wed May 14 14:35:02 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 14 May 2014 14:35:02 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WkaGs-0004Zm-2R@review.openstack.org>


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

Log:
commit 4833d205b14afc9e02966636a666e872ed5e4b25
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue May 6 19:36:59 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From 1316271 at bugs.launchpad.net  Wed May 14 20:12:56 2014
From: 1316271 at bugs.launchpad.net (Robert Clark)
Date: Wed, 14 May 2014 20:12:56 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140514201257.16298.89208.malone@soybean.canonical.com>

Can't this be done by implementing EBtables on the Compute host to
disallow inappropriate traffic from the nova-network bridge?

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 May 14 20:58:02 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 14 May 2014 20:58:02 +0000
Subject: [Openstack-security] [openstack/ironic] SecurityImpact review
 request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e
Message-ID: <E1WkgFW-0002Yv-Cn@review.openstack.org>


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

Log:
commit 327d32726dbc1d9a1ee97315a66210f76c8123f8
Author: Josh Gachnang <josh at pcsforeducation.com>
Date:   Wed Mar 19 16:47:38 2014 -0700

    Adding swift temp url support
    
    This patch will allow properly configured Glance servers to return a temporary
    URL for an object hosted on Swift. It will require Glance to use Swift
    as its backend. A temporary URL will let the agent download an image from
    Glance without requiring an auth_token, which gives access more than just
    Glance. The easiest way to use it is to enable direct_url in Glance, but
    you can set the appropriate config options to avoid needing to enable it.
    
    We/I need to add a note in the docs about Swift being a possible dependency
    for Ironic deploys using IPA, along with how to set the Temp URL key.
    
    Swift perfomance concerns will be addressed in this blueprint:
    https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads
    
    SecurityImpact
    DocImpact
    
    Implements: blueprint swift-temp-urls
    Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e




From bdpayne at acm.org  Wed May 14 21:37:16 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Wed, 14 May 2014 14:37:16 -0700
Subject: [Openstack-security] OSSG Lunch at Atlanta Summit
In-Reply-To: <CAFpPvXCAzhGUgyeQDiuncQ4wSp9ktu5BQx8bHVMX_asnRb-8eg@mail.gmail.com>
References: <CAFpPvXCEAhHWUD7aEBAS0PGiK1cuJKEtK9_UKPWSpxUKF6ZRpg@mail.gmail.com>
 <CAFpPvXCAzhGUgyeQDiuncQ4wSp9ktu5BQx8bHVMX_asnRb-8eg@mail.gmail.com>
Message-ID: <CAFpPvXBbO0bSgvHGKFEjYsmNMxho4=ftb4xk6VEqYOUPhxZRpg@mail.gmail.com>

Here's the final details for the OSSG lunch.

When: Thursday May 15 at 12:30p (or a bit later if you can't be there right
on time)
Where: Terraces Restaurant located on the street level of Building B here
at the GWCC -- http://gwcc.com/attendees/dining_options/Terraces.aspx

We currently have about 15-20 people planning to attend.  I have chosen
this location with the hopes that it will make it easier for people who may
need to come / go to other conference sessions.  Please stop in and join us
for as much time as you can.  Looking forward to seeing everyone tomorrow!

Cheers,
-bryan




On Sun, May 11, 2014 at 8:41 PM, Bryan D. Payne <bdpayne at acm.org> wrote:

> Welcome to Atlanta everyone!
>
> I'd like to get a headcount for the Thursday OSSG lunch so that I can
> choose an appropriate restaurant and make a reservation.  Please RSVP by
> replying _just to me_ (no need to spam the list) no later than 5p on
> Tuesday evening.
>
> Thanks!
> -bryan
>
>
>
>
> On Thu, May 1, 2014 at 8:25 PM, Bryan D. Payne <bdpayne at acm.org> wrote:
>
>> With the summit just around the corner, I wanted to ensure that we set
>> aside a time for OSSG to meet while in Atlanta.  So, please mark your
>> calendars:
>>
>> When: Thursday May 15 @ 12:30p
>> Location: TBD but near the GWCC, I'll send out an update via email
>>
>> I realize that there are Keystone sessions on either side of this lunch
>> slot.  Even so, this appears to be the best option all around.  For people
>> involved in Keystone, I encourage you to join us for as long as you can!
>>
>> I know that OSSG has lots to discuss during the week.  This lunch can be
>> a working lunch, but I hope that it also somewhat social.  Let's try to
>> coordinate some other meeting times during the week to discuss specific
>> topics of interest to the OSSG community.  Watch for other emails
>> coordinating those.
>>
>> More details on the lunch will be coming over the next week!
>>
>> Cheers,
>> -bryan
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140514/9d0534b4/attachment.html>

From 1316271 at bugs.launchpad.net  Wed May 14 21:39:13 2014
From: 1316271 at bugs.launchpad.net (David Hill)
Date: Wed, 14 May 2014 21:39:13 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140514213913.806.46869.malone@gac.canonical.com>

I don't think ebtables will work because you'll be able to contact the
gateway of another compute node.  This patch has been tested and prevent
all VMs from all compute nodes from accessing any compute node using
nova-network.

(I don't know much of ebtables so I can't be 100% sure of this statement
but iptables does the trick)

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 1316271 at bugs.launchpad.net  Wed May 14 22:30:26 2014
From: 1316271 at bugs.launchpad.net (David Hill)
Date: Wed, 14 May 2014 22:30:26 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140514223026.1500.76845.malone@wampee.canonical.com>

Didn't test it yet but:

--- a/nova/network/linux_net.py
+++ b/nova/network/linux_net.py
@@ -1631,10 +1631,14 @@ def remove_ebtables_rules(rules, table='filter'):
 def isolate_dhcp_address(interface, address):
     # block arp traffic to address across the interface
     rules = []
+    rules.append('INPUT -p TCP -i %s --dst %s --ip-destination-port 8776 -j ALLOW'
+                 % (interface, address))
     rules.append('INPUT -p ARP -i %s --arp-ip-dst %s -j DROP'
                  % (interface, address))
     rules.append('OUTPUT -p ARP -o %s --arp-ip-src %s -j DROP'
                  % (interface, address))
+    rules.append('INPUT -i %s --dst %s -j DROP'
+                 % (interface, address))
     # NOTE(vish): the above is not possible with iptables/arptables
     ensure_ebtables_rules(rules)
     # block dhcp broadcast traffic across the interface

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 1316271 at bugs.launchpad.net  Wed May 14 22:32:11 2014
From: 1316271 at bugs.launchpad.net (David Hill)
Date: Wed, 14 May 2014 22:32:11 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140514223211.1246.66631.malone@wampee.canonical.com>

The full patch would look like this:

--- a/nova/network/linux_net.py
+++ b/nova/network/linux_net.py
@@ -1631,10 +1631,14 @@ def remove_ebtables_rules(rules, table='filter'):
 def isolate_dhcp_address(interface, address):
     # block arp traffic to address across the interface
     rules = []
+    rules.append('INPUT -p TCP -i %s --dst %s --ip-destination-port 8776 -j ALLOW'
+                 % (interface, address))
     rules.append('INPUT -p ARP -i %s --arp-ip-dst %s -j DROP'
                  % (interface, address))
     rules.append('OUTPUT -p ARP -o %s --arp-ip-src %s -j DROP'
                  % (interface, address))
+    rules.append('INPUT -i %s --dst %s -j DROP'
+                 % (interface, address))
     # NOTE(vish): the above is not possible with iptables/arptables
     ensure_ebtables_rules(rules)
     # block dhcp broadcast traffic across the interface
@@ -1663,10 +1667,14 @@ def isolate_dhcp_address(interface, address):
 def remove_isolate_dhcp_address(interface, address):
     # block arp traffic to address across the interface
     rules = []
+    rules.append('INPUT -p TCP -i %s --dst %s --ip-destination-port 8776 -j ALLOW'
+                 % (interface, address))
     rules.append('INPUT -p ARP -i %s --arp-ip-dst %s -j DROP'
                  % (interface, address))
     rules.append('OUTPUT -p ARP -o %s --arp-ip-src %s -j DROP'
                  % (interface, address))
+    rules.append('INPUT -i %s --dst %s -j DROP'
+                 % (interface, address))
     remove_ebtables_rules(rules)
     # NOTE(vish): the above is not possible with iptables/arptables
     # block dhcp broadcast traffic across the interface

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 1316271 at bugs.launchpad.net  Wed May 14 22:37:46 2014
From: 1316271 at bugs.launchpad.net (David Hill)
Date: Wed, 14 May 2014 22:37:46 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140514223746.1324.38197.malone@wampee.canonical.com>

I'm not quite sure but I doubt this patch will work because we're not
using share_dhcp_address and by default that one is set to false.
Looking at the code, the simplest method to get that enforced is to add
it to iptables.

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 1316271 at bugs.launchpad.net  Wed May 14 22:49:14 2014
From: 1316271 at bugs.launchpad.net (David Hill)
Date: Wed, 14 May 2014 22:49:14 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140514224914.450.48056.malone@gac.canonical.com>

Would that be a better patch?

--- a/nova/virt/libvirt/firewall.py
+++ b/nova/virt/libvirt/firewall.py
@@ -76,6 +76,28 @@ class NWFilterFirewall(base_firewall.FirewallDriver):
                   </filter>'''
 
     @staticmethod
+    def nova_isolate_compte_node():
+        """This filter will disallow all traffic toward the gateway of the guests.
+        """
+
+        return '''<filter name='nova-allow-dhcp-server' chain='ipv4'>
+                    <uuid>891e4787-e5c0-d59b-cda6-41bc3c6b36fc</uuid>
+                    <rule action='allow' direction='in'
+                          priority='100'>
+                      <tcp dstipaddr='$DHCPSERVER'
+                           dstportstart='8776'/>
+                    </rule>
+                    <rule action='drop' direction='in'
+                          priority='100'>
+                      <tcp dstipaddr='$DHCPSERVER' />
+                    </rule>
+                    <rule action='drop' direction='in'
+                          priority='100'>
+                      <udp dstipaddr='$DHCPSERVER' />
+                    </rule>
+                  </filter>'''
+
+    @staticmethod
     def nova_dhcp_filter():
         """The standard allow-dhcp-server filter is an <ip> one, so it uses
            ebtables to allow traffic through. Without a corresponding rule in
@@ -221,6 +243,7 @@ class NWFilterFirewall(base_firewall.FirewallDriver):
         self._define_filter(self._filter_container('nova-vpn',
                                                    ['allow-dhcp-server']))
         self._define_filter(self.nova_dhcp_filter)
+        self._define_filter(self.nova_compute_isolation)
 
         self.static_filters_configured = True

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 sriram at sriramhere.com  Wed May 14 23:50:17 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Wed, 14 May 2014 19:50:17 -0400
Subject: [Openstack-security] OSSG Lunch at Atlanta Summit
In-Reply-To: <CAFpPvXBbO0bSgvHGKFEjYsmNMxho4=ftb4xk6VEqYOUPhxZRpg@mail.gmail.com>
References: <CAFpPvXCEAhHWUD7aEBAS0PGiK1cuJKEtK9_UKPWSpxUKF6ZRpg@mail.gmail.com>
 <CAFpPvXCAzhGUgyeQDiuncQ4wSp9ktu5BQx8bHVMX_asnRb-8eg@mail.gmail.com>
 <CAFpPvXBbO0bSgvHGKFEjYsmNMxho4=ftb4xk6VEqYOUPhxZRpg@mail.gmail.com>
Message-ID: <CAP6wb7LRtVX138y7VGup7Vuw6GOZmrjNuMz2Fr8=uQDYap617g@mail.gmail.com>

Bryan,

Thanks for doing this. I forgot to respond, but I DEFINITELY want to join.
Hope that still works.

thanks,
-Srirma


On Wed, May 14, 2014 at 5:37 PM, Bryan D. Payne <bdpayne at acm.org> wrote:

> Here's the final details for the OSSG lunch.
>
> When: Thursday May 15 at 12:30p (or a bit later if you can't be there
> right on time)
> Where: Terraces Restaurant located on the street level of Building B here
> at the GWCC -- http://gwcc.com/attendees/dining_options/Terraces.aspx
>
> We currently have about 15-20 people planning to attend.  I have chosen
> this location with the hopes that it will make it easier for people who may
> need to come / go to other conference sessions.  Please stop in and join us
> for as much time as you can.  Looking forward to seeing everyone tomorrow!
>
> Cheers,
> -bryan
>
>
>
>
> On Sun, May 11, 2014 at 8:41 PM, Bryan D. Payne <bdpayne at acm.org> wrote:
>
>> Welcome to Atlanta everyone!
>>
>> I'd like to get a headcount for the Thursday OSSG lunch so that I can
>> choose an appropriate restaurant and make a reservation.  Please RSVP by
>> replying _just to me_ (no need to spam the list) no later than 5p on
>> Tuesday evening.
>>
>> Thanks!
>> -bryan
>>
>>
>>
>>
>> On Thu, May 1, 2014 at 8:25 PM, Bryan D. Payne <bdpayne at acm.org> wrote:
>>
>>> With the summit just around the corner, I wanted to ensure that we set
>>> aside a time for OSSG to meet while in Atlanta.  So, please mark your
>>> calendars:
>>>
>>> When: Thursday May 15 @ 12:30p
>>> Location: TBD but near the GWCC, I'll send out an update via email
>>>
>>> I realize that there are Keystone sessions on either side of this lunch
>>> slot.  Even so, this appears to be the best option all around.  For people
>>> involved in Keystone, I encourage you to join us for as long as you can!
>>>
>>> I know that OSSG has lots to discuss during the week.  This lunch can be
>>> a working lunch, but I hope that it also somewhat social.  Let's try to
>>> coordinate some other meeting times during the week to discuss specific
>>> topics of interest to the OSSG community.  Watch for other emails
>>> coordinating those.
>>>
>>> More details on the lunch will be coming over the next week!
>>>
>>> Cheers,
>>> -bryan
>>>
>>
>>
>
> _______________________________________________
> 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/20140514/be170a4a/attachment.html>

From 1316271 at bugs.launchpad.net  Wed May 14 23:46:22 2014
From: 1316271 at bugs.launchpad.net (David Hill)
Date: Wed, 14 May 2014 23:46:22 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140514234622.547.10785.malone@gac.canonical.com>

This one needs to be tested:

--- a/nova/virt/libvirt/firewall.py
+++ b/nova/virt/libvirt/firewall.py
@@ -76,6 +76,28 @@ class NWFilterFirewall(base_firewall.FirewallDriver):
                   </filter>'''
 
     @staticmethod
+    def nova_dhcp_isolate_filter():
+        """This filter will disallow all traffic toward the gateway of the guests.
+        """
+
+        return '''<filter name='nova-isolate-dhcp-server' chain='ipv4'>
+                    <uuid>891e4787-e5c0-d59b-cda6-41bc3c6b36fc</uuid>
+                    <rule action='allow' direction='in'
+                          priority='100'>
+                      <tcp dstipaddr='$DHCPSERVER'
+                           dstportstart='8776'/>
+                    </rule>
+                    <rule action='drop' direction='in'
+                          priority='100'>
+                      <tcp dstipaddr='$DHCPSERVER' />
+                    </rule>
+                    <rule action='drop' direction='in'
+                          priority='100'>
+                      <udp dstipaddr='$DHCPSERVER' />
+                    </rule>
+                  </filter>'''
+
+    @staticmethod
     def nova_dhcp_filter():
         """The standard allow-dhcp-server filter is an <ip> one, so it uses
            ebtables to allow traffic through. Without a corresponding rule in
@@ -221,6 +243,7 @@ class NWFilterFirewall(base_firewall.FirewallDriver):
         self._define_filter(self._filter_container('nova-vpn',
                                                    ['allow-dhcp-server']))
         self._define_filter(self.nova_dhcp_filter)
+        self._define_filter(self.nova_dhcp_isolate_filter)
 
         self.static_filters_configured = True

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 1316271 at bugs.launchpad.net  Thu May 15 02:15:36 2014
From: 1316271 at bugs.launchpad.net (David Hill)
Date: Thu, 15 May 2014 02:15:36 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140515021536.25460.60004.malone@chaenomeles.canonical.com>

Well, sorry to spam, but I don't know where this could be injected in
the code...  The easiest place is where it is put in iptables and it
also protects the compute node from being access from all the other
guests from all the other computes nodes.    If it's a ebtable INPUT
rule, it must be global and not on a by instance basis.   All my
previous patches wont work (execpt the first one) as they are on a by
instance basis or if share_dhcp_adress is set to true which is not the
case in our case.

This patch should be addressing it:

--- a/nova/network/linux_net.py
+++ b/nova/network/linux_net.py
@@ -1447,6 +1447,9 @@ class LinuxBridgeInterfaceDriver(LinuxNetInterfaceDriver):
 
         if CONF.share_dhcp_address:
             remove_isolate_dhcp_address(iface, network['dhcp_server'])
+       else 
+            remove_isolate_compute_node(iface, network['dhcp_server'])
+
 
         iptables_manager.apply()
         return self.get_dev(network)
@@ -1627,6 +1630,13 @@ def remove_ebtables_rules(rules, table='filter'):
         cmd = ['ebtables', '-t', table, '-D'] + rule.split()
         _execute(*cmd, check_exit_code=False, run_as_root=True)
 
+def isolate_compute_node(interface, address):
+    rules = []
+    rules.append('INPUT -p TCP -i %s --dst %s --ip-destination-port 8776 -j ALLOW'
+                 % (interface, address))
+    rules.append('INPUT -i %s --dst %s -j DROP'
+                 % (interface, address))
+    ensure_ebtables_rules(rules)
 
 def isolate_dhcp_address(interface, address):
     # block arp traffic to address across the interface

--- a/nova/network/linux_net.py
+++ b/nova/network/linux_net.py
@@ -1430,6 +1430,9 @@ class LinuxBridgeInterfaceDriver(LinuxNetInterfaceDriver):
 
         if CONF.share_dhcp_address:
             isolate_dhcp_address(iface, network['dhcp_server'])
+        else
+            isolate_compute_node(iface, network['dhcp_server'])
+
         # NOTE(vish): applying here so we don't get a lock conflict
         iptables_manager.apply()
         return network['bridge']
@@ -1447,6 +1450,9 @@ class LinuxBridgeInterfaceDriver(LinuxNetInterfaceDriver):
 
         if CONF.share_dhcp_address:
             remove_isolate_dhcp_address(iface, network['dhcp_server'])
+       else 
+            remove_isolate_compute_node(iface, network['dhcp_server'])
+
 
         iptables_manager.apply()
         return self.get_dev(network)
@@ -1627,6 +1633,13 @@ def remove_ebtables_rules(rules, table='filter'):
         cmd = ['ebtables', '-t', table, '-D'] + rule.split()
         _execute(*cmd, check_exit_code=False, run_as_root=True)
 
+def isolate_compute_node(interface, address):
+    rules = []
+    rules.append('INPUT -p TCP -i %s --dst %s --ip-destination-port 8776 -j ALLOW'
+                 % (interface, address))
+    rules.append('INPUT -i %s --dst %s -j DROP'
+                 % (interface, address))
+    ensure_ebtables_rules(rules)
 
 def isolate_dhcp_address(interface, address):
     # block arp traffic to address across the interface
@@ -1659,6 +1672,13 @@ def isolate_dhcp_address(interface, address):
                           % (interface, address, CONF.iptables_drop_action)),
                          top=True)
 
+def remove_isolate_compute_node(interface, address):
+    rules = []
+    rules.append('INPUT -p TCP -i %s --dst %s --ip-destination-port 8776 -j ALLOW'
+                 % (interface, address))
+    rules.append('INPUT -i %s --dst %s -j DROP'
+                 % (interface, address))
+    remove_ebtables_rules(rules)
 
 def remove_isolate_dhcp_address(interface, address):
     # block arp traffic to address across the interface

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 mriedem at us.ibm.com  Thu May 15 17:29:18 2014
From: mriedem at us.ibm.com (Matt Riedemann)
Date: Thu, 15 May 2014 17:29:18 -0000
Subject: [Openstack-security] [Bug 1319943] [NEW] libvirt driver's to_xml
 method logs iscsi auth_password if debug
References: <20140515172919.15967.70050.malonedeb@gac.canonical.com>
Message-ID: <20140515172919.15967.70050.malonedeb@gac.canonical.com>

Public bug reported:

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

** Affects: nova
     Importance: Undecided
         Status: New


** Tags: libvirt 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/1319943

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

Status in OpenStack Compute (Nova):
  New

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 mriedem at us.ibm.com  Thu May 15 17:36:27 2014
From: mriedem at us.ibm.com (Matt Riedemann)
Date: Thu, 15 May 2014 17:36:27 -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: <20140515173627.2249.4809.malone@wampee.canonical.com>

It's the block_device_info object that has the password getting logged.

** Tags added: volume

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

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 mriedem at us.ibm.com  Thu May 15 19:29:02 2014
From: mriedem at us.ibm.com (Matt Riedemann)
Date: Thu, 15 May 2014 19:29:02 -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: <20140515192902.16373.91043.malone@gac.canonical.com>

Patch is up: https://review.openstack.org/#/c/93787/

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

** Changed in: nova
     Assignee: (unassigned) => Matt Riedemann (mriedem)

** Changed in: nova
   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/1319943

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

Status in OpenStack Compute (Nova):
  In Progress

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 1316271 at bugs.launchpad.net  Thu May 15 19:59:55 2014
From: 1316271 at bugs.launchpad.net (David Hill)
Date: Thu, 15 May 2014 19:59:55 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140515195956.16373.16096.launchpad@gac.canonical.com>

** Tags added: ebtables

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 bpokorny at linux.vnet.ibm.com  Fri May 16 04:15:43 2014
From: bpokorny at linux.vnet.ibm.com (Brad Pokorny)
Date: Fri, 16 May 2014 04:15:43 -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: <20140516041544.31973.48064.launchpad@soybean.canonical.com>

** Tags added: libvirt 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/1320028

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

Status in OpenStack Compute (Nova):
  In Progress

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 bpokorny at linux.vnet.ibm.com  Sun May 18 17:32:29 2014
From: bpokorny at linux.vnet.ibm.com (Brad Pokorny)
Date: Sun, 18 May 2014 17:32:29 -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: <20140518173229.16499.88913.malone@gac.canonical.com>

This requires changes to the oslo mask password code as well.

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

** Changed in: oslo
     Assignee: (unassigned) => Brad Pokorny (bpokorny)

-- 
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):
  In Progress
Status in Oslo - a Library of Common OpenStack Code:
  New

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 1320028 at bugs.launchpad.net  Sun May 18 18:35:50 2014
From: 1320028 at bugs.launchpad.net (OpenStack Infra)
Date: Sun, 18 May 2014 18:35:50 -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: <20140518183550.2281.76476.malone@wampee.canonical.com>

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

** Changed in: oslo
       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/1320028

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

Status in OpenStack Compute (Nova):
  In Progress
Status in Oslo - a Library of Common OpenStack Code:
  In Progress

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  Mon May 19 14:55:50 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Mon, 19 May 2014 14:55:50 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140519145550.24340.30344.malone@gac.canonical.com>

nova coresec: care to comment on this one ?

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 1316271 at bugs.launchpad.net  Mon May 19 16:28:10 2014
From: 1316271 at bugs.launchpad.net (Brian Haley)
Date: Mon, 19 May 2014 16:28:10 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140519162810.1545.32069.malone@gac.canonical.com>

I'm not working on nova-network currently, but did in a previous life so
will add a comment.

One of the better ways to do this is to add a rule to the libvirt xml
file to drop all inbound packets to the compute host, something like
this in nova/virt/libvirt/firewall.py:

+    def nova_no_my_ip_address(self):
+        # Drop all IPv4 packets going to CONF.my_ip, since the network
+        # stack will loop them back.
+        retval = "<filter name='nova-no-my-ip-address' chain='ipv4'>"
+        retval += """<rule action='drop' direction='out'>
+                       <ip dstipaddr='%s' />
+                     </rule>""" % CONF.my_ip
+        retval += '</filter>'
+        return retval

Then just put some code in _ensure_static_filters() to define and append
that to the existing filter set.

That's untested and based on older code, I see there is a
get_host_ip_addr() method now that might be a better choice.

My $.02

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 1315556 at bugs.launchpad.net  Mon May 19 19:21:46 2014
From: 1315556 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 19 May 2014 19:21:46 -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: <20140519192147.18280.44375.malone@soybean.canonical.com>

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

** Changed in: keystone
       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/1315556

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

Status in OpenStack Identity (Keystone):
  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 openstack at nemebean.com  Mon May 19 23:17:18 2014
From: openstack at nemebean.com (Ben Nemec)
Date: Mon, 19 May 2014 23:17:18 -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: <20140519231721.18778.39772.launchpad@wampee.canonical.com>

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

-- 
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):
  In Progress
Status in Oslo - a Library of Common OpenStack Code:
  In Progress

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 1320028 at bugs.launchpad.net  Tue May 20 19:36:05 2014
From: 1320028 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 20 May 2014 19:36: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: <20140520193605.19322.56166.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/94109
Committed: https://git.openstack.org/cgit/openstack/oslo-incubator/commit/?id=cdcc19c1d78a4a88daabfb64b27abd4924aa442d
Submitter: Jenkins
Branch:    master

commit cdcc19c1d78a4a88daabfb64b27abd4924aa442d
Author: Brad Pokorny <bpokorny at us.ibm.com>
Date:   Sun May 18 18:26:33 2014 +0000

    Mask passwords that are included in commands
    
    The current password masking doesn't scrub passwords from commands
    that may be written to log files.  This commit adds support for
    scrubbing passwords provided as options with commands.
    
    Adds tests to ensure commands are properly sanitized.
    
    Change-Id: I37b9a80142ec5dcadb731332d8c5f494bdc7bfc1
    Closes-Bug: #1320028


** Changed in: oslo
       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/1320028

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

Status in OpenStack Compute (Nova):
  In Progress
Status in Oslo - a Library of Common OpenStack Code:
  Fix Committed

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 mriedem at us.ibm.com  Wed May 21 14:30:43 2014
From: mriedem at us.ibm.com (Matt Riedemann)
Date: Wed, 21 May 2014 14:30:43 -0000
Subject: [Openstack-security] [Bug 1321785] [NEW] RFE: block_device_info
 dict should have a password key rather than clear password
References: <20140521143043.29900.37913.malonedeb@wampee.canonical.com>
Message-ID: <20140521143043.29900.37913.malonedeb@wampee.canonical.com>

Public bug reported:

See bug 1319943 and the related patch
https://review.openstack.org/#/c/93787/ for details, but right now the
block_device_info dict passed around in the nova virt driver can contain
a clear text password for the auth_password key.

That bug and patch are masking the password when logged in the immediate
known locations, but this could continue to crop up so we should change
the design such that the block_device_info dict doesn't contain the
password but rather a key to a store that nova can retrieve the password
for use.

Comment from Daniel Berrange in the patch above:

"Long term I think we need to figure out a way to remove the passwords
from any data dicts we pass around. Ideally the block device info would
merely contain something like a UUID to identify a password, which Nova
could use to fetch the actual password from a secure password manager
service at time of use. Thus we wouldn't have to worry about random
objects/dicts containing actual passwords. Obviously this isn't
something we can do now, but could you file an RFE to address this from
a design POV, because masking passwords at time of logging call is not
really a viable long term strategy IMHO."

** Affects: nova
     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/1321785

Title:
  RFE: block_device_info dict should have a password key rather than
  clear password

Status in OpenStack Compute (Nova):
  New

Bug description:
  See bug 1319943 and the related patch
  https://review.openstack.org/#/c/93787/ for details, but right now the
  block_device_info dict passed around in the nova virt driver can
  contain a clear text password for the auth_password key.

  That bug and patch are masking the password when logged in the
  immediate known locations, but this could continue to crop up so we
  should change the design such that the block_device_info dict doesn't
  contain the password but rather a key to a store that nova can
  retrieve the password for use.

  Comment from Daniel Berrange in the patch above:

  "Long term I think we need to figure out a way to remove the passwords
  from any data dicts we pass around. Ideally the block device info
  would merely contain something like a UUID to identify a password,
  which Nova could use to fetch the actual password from a secure
  password manager service at time of use. Thus we wouldn't have to
  worry about random objects/dicts containing actual passwords.
  Obviously this isn't something we can do now, but could you file an
  RFE to address this from a design POV, because masking passwords at
  time of logging call is not really a viable long term strategy IMHO."

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



From tristan.cacqueray at enovance.com  Wed May 21 16:20:40 2014
From: tristan.cacqueray at enovance.com (Tristan Cacqueray)
Date: Wed, 21 May 2014 16:20:40 -0000
Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in
	meter http.request
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140521162040.9786.32338.malone@gac.canonical.com>

Once a bug is public, we won't handle it privately. Setting it back to
public

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

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

** Information type changed from Private to Public 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:
  auth token is exposed in meter http.request

Status in OpenStack Telemetry (Ceilometer):
  New
Status in Oslo - a Library of Common OpenStack Code:
  In Progress
Status in OpenStack Security Advisories:
  Incomplete
Status in pyCADF:
  New

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 openstack at nemebean.com  Wed May 21 16:46:02 2014
From: openstack at nemebean.com (Ben Nemec)
Date: Wed, 21 May 2014 16:46:02 -0000
Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in
	meter http.request
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140521164605.16048.99049.launchpad@soybean.canonical.com>

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

-- 
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:
  auth token is exposed in meter http.request

Status in OpenStack Telemetry (Ceilometer):
  New
Status in Oslo - a Library of Common OpenStack Code:
  In Progress
Status in OpenStack Security Advisories:
  Incomplete
Status in pyCADF:
  New

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 1321080 at bugs.launchpad.net  Wed May 21 16:06:39 2014
From: 1321080 at bugs.launchpad.net (Launchpad Bug Tracker)
Date: Wed, 21 May 2014 16:06:39 -0000
Subject: [Openstack-security] [Bug 1321080] [NEW] auth token is exposed in
	meter http.request
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140521160639.25520.34923.launchpad@chaenomeles.canonical.com>

You have been subscribed to a private bug by gordon chung (chungg):

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"

** Affects: ceilometer
     Importance: Undecided
         Status: New

** Affects: oslo
     Importance: Undecided
     Assignee: gordon chung (chungg)
         Status: New

** Affects: pycadf
     Importance: Critical
     Assignee: gordon chung (chungg)
         Status: New

-- 
auth token is exposed in meter http.request
https://bugs.launchpad.net/bugs/1321080
You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report.



From 1321080 at bugs.launchpad.net  Wed May 21 16:26:20 2014
From: 1321080 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 21 May 2014 16:26:20 -0000
Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in
	meter http.request
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140521162620.16048.2073.malone@soybean.canonical.com>

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

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

-- 
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:
  auth token is exposed in meter http.request

Status in OpenStack Telemetry (Ceilometer):
  New
Status in Oslo - a Library of Common OpenStack Code:
  In Progress
Status in OpenStack Security Advisories:
  Incomplete
Status in pyCADF:
  New

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 1321080 at bugs.launchpad.net  Wed May 21 22:42:04 2014
From: 1321080 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 21 May 2014 22:42:04 -0000
Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in
	meter http.request
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140521224204.24898.6491.malone@chaenomeles.canonical.com>

Reviewed:  https://review.openstack.org/94666
Committed: https://git.openstack.org/cgit/openstack/oslo-incubator/commit/?id=09281ccf7837b70962ad2dfbaa1e84722ad987e8
Submitter: Jenkins
Branch:    master

commit 09281ccf7837b70962ad2dfbaa1e84722ad987e8
Author: Gordon Chung <chungg at ca.ibm.com>
Date:   Tue May 20 12:30:41 2014 -0400

    remove token from notifier middleware
    
    notifier middleware is capturing token and sending it to MQ. this
    is not advisable so we should filter it out.
    
    Change-Id: Ia1bfa1bd24989681db1d2f385defc12e69a01f8d
    Closes-Bug: #1321080


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

-- 
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:
  auth token is exposed in meter http.request

Status in OpenStack Telemetry (Ceilometer):
  New
Status in Oslo - a Library of Common OpenStack Code:
  Fix Committed
Status in OpenStack Security Advisories:
  Incomplete
Status in pyCADF:
  New

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 1321080 at bugs.launchpad.net  Thu May 22 04:22:00 2014
From: 1321080 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 22 May 2014 04:22:00 -0000
Subject: [Openstack-security] [Bug 1321080] Fix proposed to oslo-incubator
	(stable/icehouse)
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140522042200.16116.72083.malone@soybean.canonical.com>

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

-- 
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:
  auth token is exposed in meter http.request

Status in OpenStack Telemetry (Ceilometer):
  New
Status in Oslo - a Library of Common OpenStack Code:
  Fix Committed
Status in OpenStack Security Advisories:
  Incomplete
Status in pyCADF:
  New

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 liuzhikun at gmail.com  Thu May 22 02:42:48 2014
From: liuzhikun at gmail.com (Zhi Kun Liu)
Date: Thu, 22 May 2014 02:42:48 -0000
Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in
	meter http.request
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140522024249.29530.61008.launchpad@wampee.canonical.com>

** Tags added: icehouse-backport-potential

-- 
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:
  auth token is exposed in meter http.request

Status in OpenStack Telemetry (Ceilometer):
  New
Status in Oslo - a Library of Common OpenStack Code:
  Fix Committed
Status in OpenStack Security Advisories:
  Incomplete
Status in pyCADF:
  New

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 1322173 at bugs.launchpad.net  Thu May 22 13:15:08 2014
From: 1322173 at bugs.launchpad.net (Ihor Kaharlichenko)
Date: Thu, 22 May 2014 13:15:08 -0000
Subject: [Openstack-security] [Bug 1322173] [NEW] nova boot with explicitly
 defined security groups doesn't apply proper groups
References: <20140522131508.10129.29697.malonedeb@gac.canonical.com>
Message-ID: <20140522131508.10129.29697.malonedeb@gac.canonical.com>

Public bug reported:

Steps to reproduce:

$ nova boot --flavor 2 --image $image_id --nic port-id=$port_id --security-groups onlyssh --poll ihor-test-01 | grep security_groups
| security_groups                      | onlyssh                                                    |

$ nova show ihor-test-01 | grep security_groups
| security_groups                      | default                                                    |

I tried using both name and id of a security group, none of approaches
work.

Expected behavior:

The security group list is persisted and applied.

Actual behavior:

The security group list is neither persisted nor applied.

Environment:

* CentOS 6.5
* OpenStack havana
* /etc/neutron/l3_agent.ini:
[DEFAULT]
interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
ovs_use_veth = True
use_namespaces = True
handle_internal_only_routers = False
external_network_bridge =
* /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini
[ovs]
tenant_network_type = vlan
network_vlan_ranges = physnet1:1000:2000
tunnel_id_ranges =
integration_bridge = br-int
bridge_mappings = physnet1:br-vlan
[agent]
[securitygroup]
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

** Affects: nova
     Importance: Undecided
         Status: New


** Tags: network 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/1322173

Title:
  nova boot with explicitly defined security groups doesn't apply proper
  groups

Status in OpenStack Compute (Nova):
  New

Bug description:
  Steps to reproduce:

  $ nova boot --flavor 2 --image $image_id --nic port-id=$port_id --security-groups onlyssh --poll ihor-test-01 | grep security_groups
  | security_groups                      | onlyssh                                                    |

  $ nova show ihor-test-01 | grep security_groups
  | security_groups                      | default                                                    |

  I tried using both name and id of a security group, none of approaches
  work.

  Expected behavior:

  The security group list is persisted and applied.

  Actual behavior:

  The security group list is neither persisted nor applied.

  Environment:

  * CentOS 6.5
  * OpenStack havana
  * /etc/neutron/l3_agent.ini:
  [DEFAULT]
  interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
  ovs_use_veth = True
  use_namespaces = True
  handle_internal_only_routers = False
  external_network_bridge =
  * /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini
  [ovs]
  tenant_network_type = vlan
  network_vlan_ranges = physnet1:1000:2000
  tunnel_id_ranges =
  integration_bridge = br-int
  bridge_mappings = physnet1:br-vlan
  [agent]
  [securitygroup]
  firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

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



From thierry.carrez+lp at gmail.com  Thu May 22 13:29:49 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 22 May 2014 13:29:49 -0000
Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in
	meter http.request
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140522132950.29900.73007.malone@wampee.canonical.com>

I think this one will need an OSSA. I suspect that meter is
traditionally read by people other than tenant admins ?

-- 
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:
  auth token is exposed in meter http.request

Status in OpenStack Telemetry (Ceilometer):
  New
Status in Oslo - a Library of Common OpenStack Code:
  Fix Committed
Status in OpenStack Security Advisories:
  Incomplete
Status in pyCADF:
  New

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 simon.pasquier at bull.net  Thu May 22 13:34:20 2014
From: simon.pasquier at bull.net (Simon Pasquier)
Date: Thu, 22 May 2014 13:34:20 -0000
Subject: [Openstack-security] [Bug 1322173] Re: nova boot with explicitly
 defined security groups doesn't apply proper groups
References: <20140522131508.10129.29697.malonedeb@gac.canonical.com>
Message-ID: <20140522133421.25456.21805.malone@chaenomeles.canonical.com>

Since you specified the port-id option, the security groups which apply to your VM are those already associated to the port and not the ones passed to the "nova boot" command. There might be a bug report somewhere in nova about that.
Also have you checked the Nova logs?

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

Title:
  nova boot with explicitly defined security groups doesn't apply proper
  groups

Status in OpenStack Compute (Nova):
  New

Bug description:
  Steps to reproduce:

  $ nova boot --flavor 2 --image $image_id --nic port-id=$port_id --security-groups onlyssh --poll ihor-test-01 | grep security_groups
  | security_groups                      | onlyssh                                                    |

  $ nova show ihor-test-01 | grep security_groups
  | security_groups                      | default                                                    |

  I tried using both name and id of a security group, none of approaches
  work.

  Expected behavior:

  The security group list is persisted and applied.

  Actual behavior:

  The security group list is neither persisted nor applied.

  Environment:

  * CentOS 6.5
  * OpenStack havana
  * /etc/neutron/l3_agent.ini:
  [DEFAULT]
  interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
  ovs_use_veth = True
  use_namespaces = True
  handle_internal_only_routers = False
  external_network_bridge =
  * /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini
  [ovs]
  tenant_network_type = vlan
  network_vlan_ranges = physnet1:1000:2000
  tunnel_id_ranges =
  integration_bridge = br-int
  bridge_mappings = physnet1:br-vlan
  [agent]
  [securitygroup]
  firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

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



From 1321080 at bugs.launchpad.net  Thu May 22 14:13:01 2014
From: 1321080 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 22 May 2014 14:13:01 -0000
Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in
	meter http.request
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140522141301.25223.17364.malone@chaenomeles.canonical.com>

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

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

-- 
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:
  auth token is exposed in meter http.request

Status in OpenStack Telemetry (Ceilometer):
  New
Status in Oslo - a Library of Common OpenStack Code:
  Fix Committed
Status in OpenStack Security Advisories:
  Incomplete
Status in pyCADF:
  In Progress

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 jarret.raim at RACKSPACE.COM  Thu May 22 14:48:54 2014
From: jarret.raim at RACKSPACE.COM (Jarret Raim)
Date: Thu, 22 May 2014 14:48:54 +0000
Subject: [Openstack-security] [Barbican][OSSG][Keystone] Mid-Cycle Meetup
Message-ID: <CFA37881.98060%jarret.raim@rackspace.com>

All,

There was some interest at the Summit in semi-combining the mid-cycle meet
ups for Barbican, Keystone and the OSSG as there is some overlap in team
members and interest areas. The current dates being considered are:

Mon, July 7 - Barbican
Tue, July 8 - Barbican
Wed, July 9 - Barbican / Keystone
Thu, July 10 - Keystone
Fri, July 11 - Keystone

Assuming these dates work for for everyone, we'll fit some OSSG work in
during whatever days make the most sense. The current plan is to have the
meet up in San Antonio at the new Geekdom location, which is downtown.
This should make travel a bit easier for everyone as people won't need
cars are there are plenty of hotels and restaurants within walking / short
cab distance.

I wanted to try to get a quick head count from the Barbican and OSSG folks
(I think Dolph already has one for Keystone). I'd also like to know if you
are a Barbican person interested in going to the Keystone sessions or vice
versa.

Once we get a rough head count estimate, Dolph and I can work on getting
everything booked.





Thanks,

--
Jarret Raim 
@jarretraim


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5611 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140522/590540f6/attachment.bin>

From dstanek at dstanek.com  Thu May 22 14:55:33 2014
From: dstanek at dstanek.com (David Stanek)
Date: Thu, 22 May 2014 10:55:33 -0400
Subject: [Openstack-security] [openstack-dev] [Barbican][OSSG][Keystone]
	Mid-Cycle Meetup
In-Reply-To: <CFA37881.98060%jarret.raim@rackspace.com>
References: <CFA37881.98060%jarret.raim@rackspace.com>
Message-ID: <CAO69NdmF_8hVq6L=m86MVoF3G7QA98fncJd_2gNB0pc-cdv5ww@mail.gmail.com>

On Thu, May 22, 2014 at 10:48 AM, Jarret Raim <jarret.raim at rackspace.com>wrote:

>
> This should make travel a bit easier for everyone as people won't need


Hey Jarret,

I'm going to be at the Keystone meetup for sure, but I'm also thinking
about going to the Barbican meetup too.

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140522/2bec83b7/attachment.html>

From chungg at linux.vnet.ibm.com  Thu May 22 14:52:10 2014
From: chungg at linux.vnet.ibm.com (gordon chung)
Date: Thu, 22 May 2014 14:52:10 -0000
Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in
	meter http.request
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140522145210.9688.56473.launchpad@gac.canonical.com>

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

-- 
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:
  auth token is exposed in meter http.request

Status in OpenStack Telemetry (Ceilometer):
  New
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in Oslo - a Library of Common OpenStack Code:
  Fix Committed
Status in OpenStack Security Advisories:
  Incomplete
Status in pyCADF:
  In Progress

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 1321080 at bugs.launchpad.net  Thu May 22 14:53:12 2014
From: 1321080 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 22 May 2014 14:53:12 -0000
Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in
	meter http.request
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140522145312.31035.24643.malone@wampee.canonical.com>

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

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

** Changed in: neutron
     Assignee: (unassigned) => gordon chung (chungg)

-- 
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:
  auth token is exposed in meter http.request

Status in OpenStack Telemetry (Ceilometer):
  New
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in Oslo - a Library of Common OpenStack Code:
  Fix Committed
Status in OpenStack Security Advisories:
  Incomplete
Status in pyCADF:
  In Progress

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 tmckay at redhat.com  Thu May 22 14:04:43 2014
From: tmckay at redhat.com (Trevor McKay)
Date: Thu, 22 May 2014 10:04:43 -0400
Subject: [Openstack-security] Requesting assistance with a security issue
Message-ID: <1400767483.2915.2.camel@tmckaylt.rdu.redhat.com>

Hello folks,

  This is my first reported security issue with OpenStack.
(Should I celebrate? :) )

  I've created the following bug against Sahara.  Any input from
the VMT would be welcome.  I'd like to get this resolved in the 
Juno cycle.

https://bugs.launchpad.net/sahara/+bug/1321906

Best regards,

Trevor





From nkinder at redhat.com  Thu May 22 15:55:26 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Thu, 22 May 2014 08:55:26 -0700
Subject: [Openstack-security] [Barbican][OSSG][Keystone] Mid-Cycle Meetup
In-Reply-To: <CFA37881.98060%jarret.raim@rackspace.com>
References: <CFA37881.98060%jarret.raim@rackspace.com>
Message-ID: <537E1DEE.8080904@redhat.com>



On 05/22/2014 07:48 AM, Jarret Raim wrote:
> All,
> 
> There was some interest at the Summit in semi-combining the mid-cycle meet
> ups for Barbican, Keystone and the OSSG as there is some overlap in team
> members and interest areas. The current dates being considered are:
> 
> Mon, July 7 - Barbican
> Tue, July 8 - Barbican
> Wed, July 9 - Barbican / Keystone
> Thu, July 10 - Keystone
> Fri, July 11 - Keystone

I'm interested in attending, but unfortunately I can't make these dates.

> 
> Assuming these dates work for for everyone, we'll fit some OSSG work in
> during whatever days make the most sense. The current plan is to have the
> meet up in San Antonio at the new Geekdom location, which is downtown.
> This should make travel a bit easier for everyone as people won't need
> cars are there are plenty of hotels and restaurants within walking / short
> cab distance.
> 
> I wanted to try to get a quick head count from the Barbican and OSSG folks
> (I think Dolph already has one for Keystone). I'd also like to know if you
> are a Barbican person interested in going to the Keystone sessions or vice
> versa.

All of the above. :)

-NGK

> 
> Once we get a rough head count estimate, Dolph and I can work on getting
> everything booked.
> 
> 
> 
> 
> 
> Thanks,
> 
> --
> Jarret Raim 
> @jarretraim
> 
> 
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 



From robert.clark at hp.com  Thu May 22 16:33:13 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Thu, 22 May 2014 16:33:13 +0000
Subject: [Openstack-security] Requesting assistance with a security issue
In-Reply-To: <1400767483.2915.2.camel@tmckaylt.rdu.redhat.com>
References: <1400767483.2915.2.camel@tmckaylt.rdu.redhat.com>
Message-ID: <A0C170085C37664D93EE1604364858A11230BBCA@G9W0763.americas.hpqcorp.net>

Hi Trevor, thanks for reaching out.

I'm not able to view the bug, I suspect it's because it's a private
issue.

If you'd like, you can subscribe me to the bug, I'll take a look and add
others who can contribute?

-Rob

> -----Original Message-----
> From: Trevor McKay [mailto:tmckay at redhat.com]
> Sent: 22 May 2014 15:05
> To: openstack-security at lists.openstack.org
> Subject: [Openstack-security] Requesting assistance with a security
issue
> 
> Hello folks,
> 
>   This is my first reported security issue with OpenStack.
> (Should I celebrate? :) )
> 
>   I've created the following bug against Sahara.  Any input from the
VMT
> would be welcome.  I'd like to get this resolved in the Juno cycle.
> 
> https://bugs.launchpad.net/sahara/+bug/1321906
> 
> Best regards,
> 
> Trevor
> 
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
-------------- 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/20140522/8ce9e17d/attachment.bin>

From 1321080 at bugs.launchpad.net  Thu May 22 19:34:48 2014
From: 1321080 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 22 May 2014 19:34:48 -0000
Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in
	meter http.request
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140522193448.16152.53668.malone@soybean.canonical.com>

Reviewed:  https://review.openstack.org/94878
Committed: https://git.openstack.org/cgit/openstack/pycadf/commit/?id=966d4410a1a69e0a3af678442a1a965dae80d720
Submitter: Jenkins
Branch:    master

commit 966d4410a1a69e0a3af678442a1a965dae80d720
Author: Gordon Chung <chungg at ca.ibm.com>
Date:   Thu May 22 10:11:52 2014 -0400

    remove token from notifier middleware
    
    notifier middleware is capturing token and sending it to MQ. this
    is not advisable so we should filter it out.
    
    Change-Id: I11d9f2f23fc3b60c945c33d4d02bd7640d88a083
    Closes-Bug: #1321080


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

-- 
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:
  auth token is exposed in meter http.request

Status in OpenStack Telemetry (Ceilometer):
  New
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in Oslo - a Library of Common OpenStack Code:
  Fix Committed
Status in OpenStack Security Advisories:
  Incomplete
Status in pyCADF:
  Fix Committed

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 sriram at sriramhere.com  Thu May 22 23:59:07 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Thu, 22 May 2014 16:59:07 -0700
Subject: [Openstack-security] [Barbican][OSSG][Keystone] Mid-Cycle Meetup
In-Reply-To: <537E1DEE.8080904@redhat.com>
References: <CFA37881.98060%jarret.raim@rackspace.com>
 <537E1DEE.8080904@redhat.com>
Message-ID: <537e8f6c.884e320a.5e78.73b8@mx.google.com>

OSSG,

Was this discussed today? Rob and Bryan were mentioning about mid cycle OSSG meet up. Is this thread about that?

Thanks,
Sriram 

-----Original Message-----
From: "Nathan Kinder" <nkinder at redhat.com>
Sent: ‎5/‎22/‎2014 8:57 AM
To: "Jarret Raim" <jarret.raim at RACKSPACE.COM>; "OpenStack List" <openstack-dev at lists.openstack.org>; "openstack-security at lists.openstack.org" <openstack-security at lists.openstack.org>
Subject: Re: [Openstack-security] [Barbican][OSSG][Keystone] Mid-Cycle Meetup



On 05/22/2014 07:48 AM, Jarret Raim wrote:
> All,
> 
> There was some interest at the Summit in semi-combining the mid-cycle meet
> ups for Barbican, Keystone and the OSSG as there is some overlap in team
> members and interest areas. The current dates being considered are:
> 
> Mon, July 7 - Barbican
> Tue, July 8 - Barbican
> Wed, July 9 - Barbican / Keystone
> Thu, July 10 - Keystone
> Fri, July 11 - Keystone

I'm interested in attending, but unfortunately I can't make these dates.

> 
> Assuming these dates work for for everyone, we'll fit some OSSG work in
> during whatever days make the most sense. The current plan is to have the
> meet up in San Antonio at the new Geekdom location, which is downtown.
> This should make travel a bit easier for everyone as people won't need
> cars are there are plenty of hotels and restaurants within walking / short
> cab distance.
> 
> I wanted to try to get a quick head count from the Barbican and OSSG folks
> (I think Dolph already has one for Keystone). I'd also like to know if you
> are a Barbican person interested in going to the Keystone sessions or vice
> versa.

All of the above. :)

-NGK

> 
> Once we get a rough head count estimate, Dolph and I can work on getting
> everything booked.
> 
> 
> 
> 
> 
> Thanks,
> 
> --
> Jarret Raim 
> @jarretraim
> 
> 
> 
> 
> _______________________________________________
> 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/20140522/a9979d71/attachment.html>

From bdpayne at acm.org  Fri May 23 01:14:28 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Thu, 22 May 2014 21:14:28 -0400
Subject: [Openstack-security] [Barbican][OSSG][Keystone] Mid-Cycle Meetup
In-Reply-To: <CFA37881.98060%jarret.raim@rackspace.com>
References: <CFA37881.98060%jarret.raim@rackspace.com>
Message-ID: <CAFpPvXCzV51FNcGmdBBJbB+Ar1e_2zXnVMER_G4z-QWq5DD0mw@mail.gmail.com>

I plan on attending.
-bryan


On Thu, May 22, 2014 at 10:48 AM, Jarret Raim <jarret.raim at rackspace.com>wrote:

> All,
>
> There was some interest at the Summit in semi-combining the mid-cycle meet
> ups for Barbican, Keystone and the OSSG as there is some overlap in team
> members and interest areas. The current dates being considered are:
>
> Mon, July 7 - Barbican
> Tue, July 8 - Barbican
> Wed, July 9 - Barbican / Keystone
> Thu, July 10 - Keystone
> Fri, July 11 - Keystone
>
> Assuming these dates work for for everyone, we'll fit some OSSG work in
> during whatever days make the most sense. The current plan is to have the
> meet up in San Antonio at the new Geekdom location, which is downtown.
> This should make travel a bit easier for everyone as people won't need
> cars are there are plenty of hotels and restaurants within walking / short
> cab distance.
>
> I wanted to try to get a quick head count from the Barbican and OSSG folks
> (I think Dolph already has one for Keystone). I'd also like to know if you
> are a Barbican person interested in going to the Keystone sessions or vice
> versa.
>
> Once we get a rough head count estimate, Dolph and I can work on getting
> everything booked.
>
>
>
>
>
> Thanks,
>
> --
> Jarret Raim
> @jarretraim
>
>
>
> _______________________________________________
> 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/20140522/0e648589/attachment.html>

From robert.clark at hp.com  Fri May 23 07:09:26 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Fri, 23 May 2014 07:09:26 +0000
Subject: [Openstack-security] [Barbican][OSSG][Keystone] Mid-Cycle Meetup
In-Reply-To: <CAFpPvXCzV51FNcGmdBBJbB+Ar1e_2zXnVMER_G4z-QWq5DD0mw@mail.gmail.com>
References: <CFA37881.98060%jarret.raim@rackspace.com>
 <CAFpPvXCzV51FNcGmdBBJbB+Ar1e_2zXnVMER_G4z-QWq5DD0mw@mail.gmail.com>
Message-ID: <CFA4B271.ECAA%robert.clark@hp.com>

I’d like to attend all the Barbican stuff and I’m sure there’ll be some interesting Keystone things too.

I think it’s likely we’d do more parallel ‘OSSG’ stuff on the Keystone days though

I’m free on these dates.

From: Bryan Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>>
Date: Friday, 23 May 2014 02:14
To: Jarret Raim <jarret.raim at RACKSPACE.COM<mailto:jarret.raim at RACKSPACE.COM>>
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>>, OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [Openstack-security] [Barbican][OSSG][Keystone] Mid-Cycle Meetup

I plan on attending.
-bryan


On Thu, May 22, 2014 at 10:48 AM, Jarret Raim <jarret.raim at rackspace.com<mailto:jarret.raim at rackspace.com>> wrote:
All,

There was some interest at the Summit in semi-combining the mid-cycle meet
ups for Barbican, Keystone and the OSSG as there is some overlap in team
members and interest areas. The current dates being considered are:

Mon, July 7 - Barbican
Tue, July 8 - Barbican
Wed, July 9 - Barbican / Keystone
Thu, July 10 - Keystone
Fri, July 11 - Keystone

Assuming these dates work for for everyone, we'll fit some OSSG work in
during whatever days make the most sense. The current plan is to have the
meet up in San Antonio at the new Geekdom location, which is downtown.
This should make travel a bit easier for everyone as people won't need
cars are there are plenty of hotels and restaurants within walking / short
cab distance.

I wanted to try to get a quick head count from the Barbican and OSSG folks
(I think Dolph already has one for Keystone). I'd also like to know if you
are a Barbican person interested in going to the Keystone sessions or vice
versa.

Once we get a rough head count estimate, Dolph and I can work on getting
everything booked.





Thanks,

--
Jarret Raim
@jarretraim



_______________________________________________
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





From robert.clark at hp.com  Fri May 23 07:12:56 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Fri, 23 May 2014 07:12:56 +0000
Subject: [Openstack-security] Minutes from the latest OSSG meeting 22nd May
	2014
Message-ID: <CFA4B386.ECBE%robert.clark@hp.com>

http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/opens
tack_security_group.2014-05-22-18.01.html

Meeting summary
1. OSSG Meetup

2. OSSG Tasks 

3. VMT Metrics 

4. Low hanging fruit
1. https://github.com/tmcpeak/cryptoAuditor
2. https://github.com/tmcpeak/cryptoAuditor Comments and suggestions
welcome 
3. ACTION: malini1 To document the various things we can identify in
OpenStack code that could have security impact using only basic tooling.
To compile a simle list on the wiki and encourage contributions from other
members

5. Developer Security Guidelines (hyakuhei
1. https://wiki.openstack.org/wiki/Security/Guidelines


6. AOB
1. ACTION: hyakuhei to look at moving to a 1 hour meeting and finding a
better meeting slot




From robert.clark at hp.com  Fri May 23 07:15:29 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Fri, 23 May 2014 07:15:29 +0000
Subject: [Openstack-security] Was: [Barbican][OSSG][Keystone] Mid-Cycle
 Meetup (-dev dropped)
Message-ID: <CFA4B2D0.ECAF%robert.clark@hp.com>

Note: Sriram dropped –dev from this thread so we can speak a little more openly.

It was discussed a lot at the conference and yesterday on the OSSG call. The proposal is basically as Jarret has outlined, we will piggy-back with Barbican on their mid-cycle meet up. It turns out that as this is their first mid-cycle they are buddying up with Keystone so there’ll be plenty of us there.

I think this is a great opportunity to get the OSSG together and to drive forward some of those initiatives that just work better when people are in the same place. Things like the security guidelines, improving the security guide etc are a great fit.

Everyone on the OSSG – please go badger your employers for  travel budget/booking asap.

-Rob

From: Sriram Subramanian <sriram at sriramhere.com<mailto:sriram at sriramhere.com>>
Date: Friday, 23 May 2014 00:59
To: Nathan Kinder <nkinder at redhat.com<mailto:nkinder at redhat.com>>, "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] [Barbican][OSSG][Keystone] Mid-Cycle Meetup

OSSG,

Was this discussed today? Rob and Bryan were mentioning about mid cycle OSSG meet up. Is this thread about that?

Thanks,
Sriram
________________________________
From: Nathan Kinder<mailto:nkinder at redhat.com>
Sent: 5/22/2014 8:57 AM
To: Jarret Raim<mailto:jarret.raim at RACKSPACE.COM>; OpenStack List<mailto:openstack-dev at lists.openstack.org>; openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>
Subject: Re: [Openstack-security] [Barbican][OSSG][Keystone] Mid-Cycle Meetup



On 05/22/2014 07:48 AM, Jarret Raim wrote:
> All,
>
> There was some interest at the Summit in semi-combining the mid-cycle meet
> ups for Barbican, Keystone and the OSSG as there is some overlap in team
> members and interest areas. The current dates being considered are:
>
> Mon, July 7 - Barbican
> Tue, July 8 - Barbican
> Wed, July 9 - Barbican / Keystone
> Thu, July 10 - Keystone
> Fri, July 11 - Keystone

I'm interested in attending, but unfortunately I can't make these dates.

>
> Assuming these dates work for for everyone, we'll fit some OSSG work in
> during whatever days make the most sense. The current plan is to have the
> meet up in San Antonio at the new Geekdom location, which is downtown.
> This should make travel a bit easier for everyone as people won't need
> cars are there are plenty of hotels and restaurants within walking / short
> cab distance.
>
> I wanted to try to get a quick head count from the Barbican and OSSG folks
> (I think Dolph already has one for Keystone). I'd also like to know if you
> are a Barbican person interested in going to the Keystone sessions or vice
> versa.

All of the above. :)

-NGK

>
> Once we get a rough head count estimate, Dolph and I can work on getting
> everything booked.
>
>
>
>
>
> Thanks,
>
> --
> Jarret Raim
> @jarretraim
>
>
>
>
> _______________________________________________
> 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



From thierry at openstack.org  Fri May 23 08:25:30 2014
From: thierry at openstack.org (Thierry Carrez)
Date: Fri, 23 May 2014 10:25:30 +0200
Subject: [Openstack-security] Requesting assistance with a security issue
In-Reply-To: <1400767483.2915.2.camel@tmckaylt.rdu.redhat.com>
References: <1400767483.2915.2.camel@tmckaylt.rdu.redhat.com>
Message-ID: <537F05FA.5010709@openstack.org>

Trevor McKay wrote:
> Hello folks,
> 
>   This is my first reported security issue with OpenStack.
> (Should I celebrate? :) )
> 
>   I've created the following bug against Sahara.  Any input from
> the VMT would be welcome.  I'd like to get this resolved in the 
> Juno cycle.
> 
> https://bugs.launchpad.net/sahara/+bug/1321906

Hey Trevor,

The Vulnerability Management Team is responsible for handling such
submissions. Your post made me realize we didn't have access to Sahara
Private security bugs, and I just fixed the problem. We'll get back to
you on the private bug ASAP.

-- 
Thierry Carrez (ttx)
OpenStack Vulnerability Management Team



From sriram at sriramhere.com  Fri May 23 14:08:39 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Fri, 23 May 2014 07:08:39 -0700
Subject: [Openstack-security] [Barbican][OSSG][Keystone] Mid-Cycle
 Meetup(-dev dropped)
In-Reply-To: <CFA4B2D0.ECAF%robert.clark@hp.com>
References: <CFA4B2D0.ECAF%robert.clark@hp.com>
Message-ID: <537f568e.4788440a.4079.ffffd6e4@mx.google.com>

Thanks Rob!

Regarding badgering employers, any chance of big companies sponsoring independent entities like me?

Thanks,
Sriram 

-----Original Message-----
From: "Clark, Robert Graham" <robert.clark at hp.com>
Sent: ‎5/‎23/‎2014 12:16 AM
To: "Sriram Subramanian" <sriram at sriramhere.com>; "Nathan Kinder" <nkinder at redhat.com>; "openstack-security at lists.openstack.org" <openstack-security at lists.openstack.org>
Subject: Was: [Openstack-security] [Barbican][OSSG][Keystone] Mid-Cycle Meetup(-dev dropped)

Note: Sriram dropped –dev from this thread so we can speak a little more openly.

It was discussed a lot at the conference and yesterday on the OSSG call. The proposal is basically as Jarret has outlined, we will piggy-back with Barbican on their mid-cycle meet up. It turns out that as this is their first mid-cycle they are buddying up with Keystone so there’ll be plenty of us there.

I think this is a great opportunity to get the OSSG together and to drive forward some of those initiatives that just work better when people are in the same place. Things like the security guidelines, improving the security guide etc are a great fit.

Everyone on the OSSG – please go badger your employers for  travel budget/booking asap.

-Rob

From: Sriram Subramanian <sriram at sriramhere.com<mailto:sriram at sriramhere.com>>
Date: Friday, 23 May 2014 00:59
To: Nathan Kinder <nkinder at redhat.com<mailto:nkinder at redhat.com>>, "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] [Barbican][OSSG][Keystone] Mid-Cycle Meetup

OSSG,

Was this discussed today? Rob and Bryan were mentioning about mid cycle OSSG meet up. Is this thread about that?

Thanks,
Sriram
________________________________
From: Nathan Kinder<mailto:nkinder at redhat.com>
Sent: 5/22/2014 8:57 AM
To: Jarret Raim<mailto:jarret.raim at RACKSPACE.COM>; OpenStack List<mailto:openstack-dev at lists.openstack.org>; openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>
Subject: Re: [Openstack-security] [Barbican][OSSG][Keystone] Mid-Cycle Meetup



On 05/22/2014 07:48 AM, Jarret Raim wrote:
> All,
>
> There was some interest at the Summit in semi-combining the mid-cycle meet
> ups for Barbican, Keystone and the OSSG as there is some overlap in team
> members and interest areas. The current dates being considered are:
>
> Mon, July 7 - Barbican
> Tue, July 8 - Barbican
> Wed, July 9 - Barbican / Keystone
> Thu, July 10 - Keystone
> Fri, July 11 - Keystone

I'm interested in attending, but unfortunately I can't make these dates.

>
> Assuming these dates work for for everyone, we'll fit some OSSG work in
> during whatever days make the most sense. The current plan is to have the
> meet up in San Antonio at the new Geekdom location, which is downtown.
> This should make travel a bit easier for everyone as people won't need
> cars are there are plenty of hotels and restaurants within walking / short
> cab distance.
>
> I wanted to try to get a quick head count from the Barbican and OSSG folks
> (I think Dolph already has one for Keystone). I'd also like to know if you
> are a Barbican person interested in going to the Keystone sessions or vice
> versa.

All of the above. :)

-NGK

>
> Once we get a rough head count estimate, Dolph and I can work on getting
> everything booked.
>
>
>
>
>
> Thanks,
>
> --
> Jarret Raim
> @jarretraim
>
>
>
>
> _______________________________________________
> 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/20140523/fadfd251/attachment.html>

From 1322173 at bugs.launchpad.net  Mon May 26 12:35:38 2014
From: 1322173 at bugs.launchpad.net (Ihor Kaharlichenko)
Date: Mon, 26 May 2014 12:35:38 -0000
Subject: [Openstack-security] [Bug 1322173] Re: nova boot with explicitly
 defined security groups doesn't apply proper groups
References: <20140522131508.10129.29697.malonedeb@gac.canonical.com>
Message-ID: <20140526123538.9886.9103.malone@gac.canonical.com>

I have checked the nova's compute logs, but unfortunately those didn't
shed any light on the problem. There were neither errors nor warning
stating that security-groups argument was ignored, nothing.

I checked whether security groups apply if I boot the instance with
--nic net-id=$NETWORK_ID and indeed, this works as expected. So Simon is
probably right.

This behavior is counter-intuitive and I still consider it a bug. Nova
should have either warned me about --security-groups argument being
completely ignored or add it to the list of security groups just next to
the ones defined for each ports used. But in any case it shouldn't be
silent.

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

Title:
  nova boot with explicitly defined security groups doesn't apply proper
  groups

Status in OpenStack Compute (Nova):
  New

Bug description:
  Steps to reproduce:

  $ nova boot --flavor 2 --image $image_id --nic port-id=$port_id --security-groups onlyssh --poll ihor-test-01 | grep security_groups
  | security_groups                      | onlyssh                                                    |

  $ nova show ihor-test-01 | grep security_groups
  | security_groups                      | default                                                    |

  I tried using both name and id of a security group, none of approaches
  work.

  Expected behavior:

  The security group list is persisted and applied.

  Actual behavior:

  The security group list is neither persisted nor applied.

  Environment:

  * CentOS 6.5
  * OpenStack havana
  * /etc/neutron/l3_agent.ini:
  [DEFAULT]
  interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
  ovs_use_veth = True
  use_namespaces = True
  handle_internal_only_routers = False
  external_network_bridge =
  * /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini
  [ovs]
  tenant_network_type = vlan
  network_vlan_ranges = physnet1:1000:2000
  tunnel_id_ranges =
  integration_bridge = br-int
  bridge_mappings = physnet1:br-vlan
  [agent]
  [securitygroup]
  firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

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



From fungi at yuggoth.org  Mon May 26 14:39:53 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 26 May 2014 14:39:53 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140526143956.29499.77007.launchpad@wampee.canonical.com>

** Changed in: ossa
     Assignee: (unassigned) => Jeremy Stanley (fungi)

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 thierry.carrez+lp at gmail.com  Mon May 26 14:49:19 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Mon, 26 May 2014 14:49:19 -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: <20140526144919.9961.9699.malone@gac.canonical.com>

That would be a welcome strengthening, but I don't think this is
exploitable as is.

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

** Information type changed from Public Security to Public

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

Title:
  Using random.random() should not be used to generate randomness used
  for security reasons

Status in Cinder:
  Triaged
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  Mon May 26 14:53:50 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Mon, 26 May 2014 14:53:50 -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: <20140526145351.29861.58365.malone@wampee.canonical.com>

OK, so this would be considered a missing security feature (weak
security for internal communications). That needs to be fixed in future
versions for sure. But we typically don't issue OSSA for those.

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

** Tags added: security

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

Title:
  Cinder utils SSHPool should allow customized ssh host keys and missing
  policy

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

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  Mon May 26 14:57:23 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Mon, 26 May 2014 14:57:23 -0000
Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in
	meter http.request
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140526145727.15744.60618.launchpad@soybean.canonical.com>

** Changed in: ossa
       Status: Incomplete => Confirmed

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

-- 
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:
  auth token is exposed in meter http.request

Status in OpenStack Telemetry (Ceilometer):
  New
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in Oslo - a Library of Common OpenStack Code:
  Fix Committed
Status in OpenStack Security Advisories:
  Confirmed
Status in pyCADF:
  Fix Committed

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 fungi at yuggoth.org  Mon May 26 15:08:01 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 26 May 2014 15:08:01 -0000
Subject: [Openstack-security] [Bug 1322766] Re: Cinder wipe/shred fails open
References: <20140523222522.10305.61680.malonedeb@gac.canonical.com>
Message-ID: <20140526150801.30293.822.malone@wampee.canonical.com>

I've subscribed the OSSG in case they want to weigh in on this before
switching it to public.

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

Title:
  Cinder wipe/shred fails open

Status in Cinder:
  New
Status in OpenStack Security Advisories:
  Incomplete

Bug description:
  Previously, lvm_type=default signified a volume should be zero'd or
  wiped when deleting the volume. Zeroization could be avoided with
  lvm_type=thin. At
  https://github.com/openstack/cinder/commit/bb06ebd0f6a75a6ba55a7c022de96a91e3750d20,
  the following was added:

      volume_clear = none, zero, shred
      volume_clear_size = size_in_MiB

  Looking at the code from the commit, the default behavior of wiping
  was changed, and the change resulted in a "fail open". That is, no
  wipe occurs on configuration errors or typos:

  +        LOG.info(_("Performing secure delete on volume: %s") % volume['id'])
  +
  +        if FLAGS.volume_clear == 'zero':
  +            if size_in_m == 0:
  +                return self._copy_volume('/dev/zero', vol_path, size_in_g)
  +            else:
  +                clear_cmd = ['shred', '-n0', '-z', '-s%dMiB' % size_in_m]
  +        elif FLAGS.volume_clear == 'shred':
  +            clear_cmd = ['shred', '-n3']
  +            if size_in_m:
  +                clear_cmd.append('-s%dMiB' % size_in_m)
  +        else:
  +            LOG.error(_("Error unrecognized volume_clear option: %s"),
  +                      FLAGS.volume_clear)
  +            return

  Perhaps previous behavior should be restored:

      * default = one pass of 0's
      * a valid config changes the behavior
      * an invalid config still uses default behavior

  I think it s important to ensure cinder serves zero'ized block among
  tenants in the common case to ensure no data leaks of sensitive or
  highly sensitive data. Its going to be an important safeguard,
  especially in industries like US Financial and US Federal.

  Operators that don't handle sensitive or highly sensitive data can
  'volume_clear = none'.

  And the unexpected case of a configuration error or typo ensures the
  system fails safe. In fact, specifying 'volume_clear = 1' or
  'volume_clear = true' or 'volume_clear = yes' should trigger the
  unexpected fail open.

  From the low hanging fruit department.... Feel free to release it at
  any time. The "security vulnerability" was checked to ensure the
  security folks had an opportunity to provide feedback.

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



From fungi at yuggoth.org  Mon May 26 20:13:51 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 26 May 2014 20:13:51 -0000
Subject: [Openstack-security] [Bug 1322766] Re: Cinder wipe/shred fails open
References: <20140523222522.10305.61680.malonedeb@gac.canonical.com>
Message-ID: <20140526201351.10033.66133.malone@gac.canonical.com>

Well, already public. Setting as public-security so that the openstack-
security mailing list will be notified.

** Information type changed from Private Security to Public 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/1322766

Title:
  Cinder wipe/shred fails open

Status in Cinder:
  New
Status in OpenStack Security Advisories:
  Incomplete

Bug description:
  Previously, lvm_type=default signified a volume should be zero'd or
  wiped when deleting the volume. Zeroization could be avoided with
  lvm_type=thin. At
  https://github.com/openstack/cinder/commit/bb06ebd0f6a75a6ba55a7c022de96a91e3750d20,
  the following was added:

      volume_clear = none, zero, shred
      volume_clear_size = size_in_MiB

  Looking at the code from the commit, the default behavior of wiping
  was changed, and the change resulted in a "fail open". That is, no
  wipe occurs on configuration errors or typos:

  +        LOG.info(_("Performing secure delete on volume: %s") % volume['id'])
  +
  +        if FLAGS.volume_clear == 'zero':
  +            if size_in_m == 0:
  +                return self._copy_volume('/dev/zero', vol_path, size_in_g)
  +            else:
  +                clear_cmd = ['shred', '-n0', '-z', '-s%dMiB' % size_in_m]
  +        elif FLAGS.volume_clear == 'shred':
  +            clear_cmd = ['shred', '-n3']
  +            if size_in_m:
  +                clear_cmd.append('-s%dMiB' % size_in_m)
  +        else:
  +            LOG.error(_("Error unrecognized volume_clear option: %s"),
  +                      FLAGS.volume_clear)
  +            return

  Perhaps previous behavior should be restored:

      * default = one pass of 0's
      * a valid config changes the behavior
      * an invalid config still uses default behavior

  I think it s important to ensure cinder serves zero'ized block among
  tenants in the common case to ensure no data leaks of sensitive or
  highly sensitive data. Its going to be an important safeguard,
  especially in industries like US Financial and US Federal.

  Operators that don't handle sensitive or highly sensitive data can
  'volume_clear = none'.

  And the unexpected case of a configuration error or typo ensures the
  system fails safe. In fact, specifying 'volume_clear = 1' or
  'volume_clear = true' or 'volume_clear = yes' should trigger the
  unexpected fail open.

  From the low hanging fruit department.... Feel free to release it at
  any time. The "security vulnerability" was checked to ensure the
  security folks had an opportunity to provide feedback.

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



From 1322766 at bugs.launchpad.net  Mon May 26 15:07:18 2014
From: 1322766 at bugs.launchpad.net (Launchpad Bug Tracker)
Date: Mon, 26 May 2014 15:07:18 -0000
Subject: [Openstack-security] [Bug 1322766] [NEW] Cinder wipe/shred fails
	open
References: <20140523222522.10305.61680.malonedeb@gac.canonical.com>
Message-ID: <20140526150719.25084.95246.launchpad@chaenomeles.canonical.com>

*** This bug is a security vulnerability ***

You have been subscribed to a private security bug by Jeremy Stanley (fungi):

Previously, lvm_type=default signified a volume should be zero'd or
wiped when deleting the volume. Zeroization could be avoided with
lvm_type=thin. At
https://github.com/openstack/cinder/commit/bb06ebd0f6a75a6ba55a7c022de96a91e3750d20,
the following was added:

    volume_clear = none, zero, shred
    volume_clear_size = size_in_MiB

Looking at the code from the commit, the default behavior of wiping was
changed, and the change resulted in a "fail open". That is, no wipe
occurs on configuration errors or typos:

+        LOG.info(_("Performing secure delete on volume: %s") % volume['id'])
+
+        if FLAGS.volume_clear == 'zero':
+            if size_in_m == 0:
+                return self._copy_volume('/dev/zero', vol_path, size_in_g)
+            else:
+                clear_cmd = ['shred', '-n0', '-z', '-s%dMiB' % size_in_m]
+        elif FLAGS.volume_clear == 'shred':
+            clear_cmd = ['shred', '-n3']
+            if size_in_m:
+                clear_cmd.append('-s%dMiB' % size_in_m)
+        else:
+            LOG.error(_("Error unrecognized volume_clear option: %s"),
+                      FLAGS.volume_clear)
+            return

Perhaps previous behavior should be restored:

    * default = one pass of 0's
    * a valid config changes the behavior
    * an invalid config still uses default behavior

I think it s important to ensure cinder serves zero'ized block among
tenants in the common case to ensure no data leaks of sensitive or
highly sensitive data. Its going to be an important safeguard,
especially in industries like US Financial and US Federal.

Operators that don't handle sensitive or highly sensitive data can
'volume_clear = none'.

And the unexpected case of a configuration error or typo ensures the
system fails safe. In fact, specifying 'volume_clear = 1' or
'volume_clear = true' or 'volume_clear = yes' should trigger the
unexpected fail open.

>From the low hanging fruit department.... Feel free to release it at any
time. The "security vulnerability" was checked to ensure the security
folks had an opportunity to provide feedback.

** Affects: cinder
     Importance: Undecided
         Status: New

** Affects: ossa
     Importance: Undecided
         Status: Incomplete

-- 
Cinder wipe/shred fails open
https://bugs.launchpad.net/bugs/1322766
You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report.



From 1322766 at bugs.launchpad.net  Tue May 27 08:10:49 2014
From: 1322766 at bugs.launchpad.net (Robert Clark)
Date: Tue, 27 May 2014 08:10:49 -0000
Subject: [Openstack-security] [Bug 1322766] Re: Cinder wipe/shred fails open
References: <20140523222522.10305.61680.malonedeb@gac.canonical.com>
Message-ID: <20140527081049.24898.10078.malone@chaenomeles.canonical.com>

Seems OSSN worthy, well caught Jeff.

We should have a separate conversation about the usefulness of "shred"

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

Title:
  Cinder wipe/shred fails open

Status in Cinder:
  New
Status in OpenStack Security Advisories:
  Incomplete

Bug description:
  Previously, lvm_type=default signified a volume should be zero'd or
  wiped when deleting the volume. Zeroization could be avoided with
  lvm_type=thin. At
  https://github.com/openstack/cinder/commit/bb06ebd0f6a75a6ba55a7c022de96a91e3750d20,
  the following was added:

      volume_clear = none, zero, shred
      volume_clear_size = size_in_MiB

  Looking at the code from the commit, the default behavior of wiping
  was changed, and the change resulted in a "fail open". That is, no
  wipe occurs on configuration errors or typos:

  +        LOG.info(_("Performing secure delete on volume: %s") % volume['id'])
  +
  +        if FLAGS.volume_clear == 'zero':
  +            if size_in_m == 0:
  +                return self._copy_volume('/dev/zero', vol_path, size_in_g)
  +            else:
  +                clear_cmd = ['shred', '-n0', '-z', '-s%dMiB' % size_in_m]
  +        elif FLAGS.volume_clear == 'shred':
  +            clear_cmd = ['shred', '-n3']
  +            if size_in_m:
  +                clear_cmd.append('-s%dMiB' % size_in_m)
  +        else:
  +            LOG.error(_("Error unrecognized volume_clear option: %s"),
  +                      FLAGS.volume_clear)
  +            return

  Perhaps previous behavior should be restored:

      * default = one pass of 0's
      * a valid config changes the behavior
      * an invalid config still uses default behavior

  I think it s important to ensure cinder serves zero'ized block among
  tenants in the common case to ensure no data leaks of sensitive or
  highly sensitive data. Its going to be an important safeguard,
  especially in industries like US Financial and US Federal.

  Operators that don't handle sensitive or highly sensitive data can
  'volume_clear = none'.

  And the unexpected case of a configuration error or typo ensures the
  system fails safe. In fact, specifying 'volume_clear = 1' or
  'volume_clear = true' or 'volume_clear = yes' should trigger the
  unexpected fail open.

  From the low hanging fruit department.... Feel free to release it at
  any time. The "security vulnerability" was checked to ensure the
  security folks had an opportunity to provide feedback.

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



From 1320056 at bugs.launchpad.net  Tue May 27 08:28:55 2014
From: 1320056 at bugs.launchpad.net (Robert Clark)
Date: Tue, 27 May 2014 08:28:55 -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: <20140527082855.25289.79710.malone@chaenomeles.canonical.com>

We should probably document this with an OSSN as deployers may have an
incorrect understanding of the security offered with this feature

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

Title:
  Cinder utils SSHPool should allow customized ssh host keys and missing
  policy

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

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 1319643 at bugs.launchpad.net  Tue May 27 08:38:31 2014
From: 1319643 at bugs.launchpad.net (Robert Clark)
Date: Tue, 27 May 2014 08:38:31 -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: <20140527083831.10374.74990.malone@gac.canonical.com>

Where there's a defined security feature in OpenStack, such as here with
the use of cryptographic functions in Cinder we should ensure that they
are done correctly. I think failures to do this _are_ security issues
and should be addressed and documented as such.

This probably isn't a big enough issue to warrant an OSSA and I don'
think that an OSSN would be appropriate either if the plan is to improve
this in the next release.

-- 
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:
  Triaged
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 1316271 at bugs.launchpad.net  Tue May 27 08:47:40 2014
From: 1316271 at bugs.launchpad.net (Robert Clark)
Date: Tue, 27 May 2014 08:47:40 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140527084740.25456.8761.malone@chaenomeles.canonical.com>

What workarounds might be available that could form an OSSN to cover
this and previous releases?

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 1322173 at bugs.launchpad.net  Tue May 27 08:57:34 2014
From: 1322173 at bugs.launchpad.net (Robert Clark)
Date: Tue, 27 May 2014 08:57:34 -0000
Subject: [Openstack-security] [Bug 1322173] Re: nova boot with explicitly
 defined security groups doesn't apply proper groups
References: <20140522131508.10129.29697.malonedeb@gac.canonical.com>
Message-ID: <20140527085734.9719.61894.malone@gac.canonical.com>

There should probably be some mechanism for feeding back to the client
when they've made a request that doesn't make sense (like specifying
port-id and a security group rule)

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

Title:
  nova boot with explicitly defined security groups doesn't apply proper
  groups

Status in OpenStack Compute (Nova):
  New

Bug description:
  Steps to reproduce:

  $ nova boot --flavor 2 --image $image_id --nic port-id=$port_id --security-groups onlyssh --poll ihor-test-01 | grep security_groups
  | security_groups                      | onlyssh                                                    |

  $ nova show ihor-test-01 | grep security_groups
  | security_groups                      | default                                                    |

  I tried using both name and id of a security group, none of approaches
  work.

  Expected behavior:

  The security group list is persisted and applied.

  Actual behavior:

  The security group list is neither persisted nor applied.

  Environment:

  * CentOS 6.5
  * OpenStack havana
  * /etc/neutron/l3_agent.ini:
  [DEFAULT]
  interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
  ovs_use_veth = True
  use_namespaces = True
  handle_internal_only_routers = False
  external_network_bridge =
  * /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini
  [ovs]
  tenant_network_type = vlan
  network_vlan_ranges = physnet1:1000:2000
  tunnel_id_ranges =
  integration_bridge = br-int
  bridge_mappings = physnet1:br-vlan
  [agent]
  [securitygroup]
  firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

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



From gerrit2 at review.openstack.org  Tue May 27 12:43:40 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 27 May 2014 12:43:40 +0000
Subject: [Openstack-security] [openstack/glance] SecurityImpact review
 request change I20ddab5c3359071daf7505268c72331e4c786987
Message-ID: <E1WpGjE-0001P5-6Y@review.openstack.org>


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

Log:
commit c93a7a22c02b5b95c85027da3a26e5f378b8f1f2
Author: Thomas Leaman <thomas.leaman at hp.com>
Date:   Mon Feb 24 17:03:33 2014 +0000

    Bump python-swiftclient version
    
    https://review.openstack.org/#/c/69187/ introduced SSL certificate checking
    in python-swiftclient (released as v2.0). This patch ensures that the version
    of swiftclient used will verify SSL certificates correctly.
    
    This patch also documents the `swift_store_auth_insecure` configuration
    option for bypassing the cert verification
    
    DocImpact
    SecurityImpact
    
    Change-Id: I20ddab5c3359071daf7505268c72331e4c786987




From fungi at yuggoth.org  Tue May 27 14:10:22 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 27 May 2014 14:10:22 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140527141022.25084.71312.malone@chaenomeles.canonical.com>

For some reason I was thinking there was an OSSN covering this, but the
closest I found was the one on poor configuration instructions for live
migration exposing libvirt's control interface to tenant instances. I
also don't see anything in the security guide specifically addressing
network hardening for compute nodes (recommended filter rules for local
interfaces, isolating running services onto separate VLANs from instance
virtual interfaces, et cetera) though it's possible I've overlooked it.

** Changed in: ossa
     Assignee: Jeremy Stanley (fungi) => (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/1316271

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

Status in OpenStack Compute (Nova):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 mb at us.ibm.com  Tue May 27 14:04:42 2014
From: mb at us.ibm.com (Mohammad Banikazemi)
Date: Tue, 27 May 2014 14:04:42 -0000
Subject: [Openstack-security] [Bug 1320098] Re: neutronclient debug logging
 includes keystone auth token
References: <20140516064420.2758.66631.malonedeb@wampee.canonical.com>
Message-ID: <20140527140442.25053.60917.launchpad@chaenomeles.canonical.com>

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

Title:
  neutronclient debug logging includes keystone auth token

Status in Python client library for Neutron:
  In Progress

Bug description:
  neutronclient is logging the auth token in the nova logs. Since the
  logs are world-readable, this means anyone user on this system can see
  the auth token, which they can then use to get OpenStack administrator
  access.

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



From nkinder at redhat.com  Tue May 27 14:59:25 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Tue, 27 May 2014 14:59:25 -0000
Subject: [Openstack-security] [Bug 1322766] Re: Cinder wipe/shred fails open
References: <20140523222522.10305.61680.malonedeb@gac.canonical.com>
Message-ID: <20140527145925.30862.64790.launchpad@wampee.canonical.com>

** 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 the bug report.
https://bugs.launchpad.net/bugs/1322766

Title:
  Cinder wipe/shred fails open

Status in Cinder:
  New
Status in OpenStack Security Advisories:
  Incomplete
Status in OpenStack Security Notes:
  New

Bug description:
  Previously, lvm_type=default signified a volume should be zero'd or
  wiped when deleting the volume. Zeroization could be avoided with
  lvm_type=thin. At
  https://github.com/openstack/cinder/commit/bb06ebd0f6a75a6ba55a7c022de96a91e3750d20,
  the following was added:

      volume_clear = none, zero, shred
      volume_clear_size = size_in_MiB

  Looking at the code from the commit, the default behavior of wiping
  was changed, and the change resulted in a "fail open". That is, no
  wipe occurs on configuration errors or typos:

  +        LOG.info(_("Performing secure delete on volume: %s") % volume['id'])
  +
  +        if FLAGS.volume_clear == 'zero':
  +            if size_in_m == 0:
  +                return self._copy_volume('/dev/zero', vol_path, size_in_g)
  +            else:
  +                clear_cmd = ['shred', '-n0', '-z', '-s%dMiB' % size_in_m]
  +        elif FLAGS.volume_clear == 'shred':
  +            clear_cmd = ['shred', '-n3']
  +            if size_in_m:
  +                clear_cmd.append('-s%dMiB' % size_in_m)
  +        else:
  +            LOG.error(_("Error unrecognized volume_clear option: %s"),
  +                      FLAGS.volume_clear)
  +            return

  Perhaps previous behavior should be restored:

      * default = one pass of 0's
      * a valid config changes the behavior
      * an invalid config still uses default behavior

  I think it s important to ensure cinder serves zero'ized block among
  tenants in the common case to ensure no data leaks of sensitive or
  highly sensitive data. Its going to be an important safeguard,
  especially in industries like US Financial and US Federal.

  Operators that don't handle sensitive or highly sensitive data can
  'volume_clear = none'.

  And the unexpected case of a configuration error or typo ensures the
  system fails safe. In fact, specifying 'volume_clear = 1' or
  'volume_clear = true' or 'volume_clear = yes' should trigger the
  unexpected fail open.

  From the low hanging fruit department.... Feel free to release it at
  any time. The "security vulnerability" was checked to ensure the
  security folks had an opportunity to provide feedback.

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



From 1322766 at bugs.launchpad.net  Tue May 27 15:28:15 2014
From: 1322766 at bugs.launchpad.net (Eric Harney)
Date: Tue, 27 May 2014 15:28:15 -0000
Subject: [Openstack-security] [Bug 1322766] Re: Cinder wipe/shred fails open
References: <20140523222522.10305.61680.malonedeb@gac.canonical.com>
Message-ID: <20140527152815.10033.87516.malone@gac.canonical.com>

Havana and Icehouse fail safely with an error indicating that the config
value was invalid.  The code referenced in the description seems to be
from Grizzly.

Change was made at https://review.openstack.org/#/c/46572/ for bug
1225194.

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

Title:
  Cinder wipe/shred fails open

Status in Cinder:
  New
Status in OpenStack Security Advisories:
  Incomplete
Status in OpenStack Security Notes:
  New

Bug description:
  Previously, lvm_type=default signified a volume should be zero'd or
  wiped when deleting the volume. Zeroization could be avoided with
  lvm_type=thin. At
  https://github.com/openstack/cinder/commit/bb06ebd0f6a75a6ba55a7c022de96a91e3750d20,
  the following was added:

      volume_clear = none, zero, shred
      volume_clear_size = size_in_MiB

  Looking at the code from the commit, the default behavior of wiping
  was changed, and the change resulted in a "fail open". That is, no
  wipe occurs on configuration errors or typos:

  +        LOG.info(_("Performing secure delete on volume: %s") % volume['id'])
  +
  +        if FLAGS.volume_clear == 'zero':
  +            if size_in_m == 0:
  +                return self._copy_volume('/dev/zero', vol_path, size_in_g)
  +            else:
  +                clear_cmd = ['shred', '-n0', '-z', '-s%dMiB' % size_in_m]
  +        elif FLAGS.volume_clear == 'shred':
  +            clear_cmd = ['shred', '-n3']
  +            if size_in_m:
  +                clear_cmd.append('-s%dMiB' % size_in_m)
  +        else:
  +            LOG.error(_("Error unrecognized volume_clear option: %s"),
  +                      FLAGS.volume_clear)
  +            return

  Perhaps previous behavior should be restored:

      * default = one pass of 0's
      * a valid config changes the behavior
      * an invalid config still uses default behavior

  I think it s important to ensure cinder serves zero'ized block among
  tenants in the common case to ensure no data leaks of sensitive or
  highly sensitive data. Its going to be an important safeguard,
  especially in industries like US Financial and US Federal.

  Operators that don't handle sensitive or highly sensitive data can
  'volume_clear = none'.

  And the unexpected case of a configuration error or typo ensures the
  system fails safe. In fact, specifying 'volume_clear = 1' or
  'volume_clear = true' or 'volume_clear = yes' should trigger the
  unexpected fail open.

  From the low hanging fruit department.... Feel free to release it at
  any time. The "security vulnerability" was checked to ensure the
  security folks had an opportunity to provide feedback.

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



From fungi at yuggoth.org  Tue May 27 17:14:02 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 27 May 2014 17:14:02 -0000
Subject: [Openstack-security] [Bug 1322766] Re: Cinder wipe/shred fails open
References: <20140523222522.10305.61680.malonedeb@gac.canonical.com>
Message-ID: <20140527171402.15646.96655.malone@soybean.canonical.com>

As this does not affect any releases currently under security support,
I'm removing the security advisory task.

** No longer affects: ossa

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

Title:
  Cinder wipe/shred fails open

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

Bug description:
  Previously, lvm_type=default signified a volume should be zero'd or
  wiped when deleting the volume. Zeroization could be avoided with
  lvm_type=thin. At
  https://github.com/openstack/cinder/commit/bb06ebd0f6a75a6ba55a7c022de96a91e3750d20,
  the following was added:

      volume_clear = none, zero, shred
      volume_clear_size = size_in_MiB

  Looking at the code from the commit, the default behavior of wiping
  was changed, and the change resulted in a "fail open". That is, no
  wipe occurs on configuration errors or typos:

  +        LOG.info(_("Performing secure delete on volume: %s") % volume['id'])
  +
  +        if FLAGS.volume_clear == 'zero':
  +            if size_in_m == 0:
  +                return self._copy_volume('/dev/zero', vol_path, size_in_g)
  +            else:
  +                clear_cmd = ['shred', '-n0', '-z', '-s%dMiB' % size_in_m]
  +        elif FLAGS.volume_clear == 'shred':
  +            clear_cmd = ['shred', '-n3']
  +            if size_in_m:
  +                clear_cmd.append('-s%dMiB' % size_in_m)
  +        else:
  +            LOG.error(_("Error unrecognized volume_clear option: %s"),
  +                      FLAGS.volume_clear)
  +            return

  Perhaps previous behavior should be restored:

      * default = one pass of 0's
      * a valid config changes the behavior
      * an invalid config still uses default behavior

  I think it s important to ensure cinder serves zero'ized block among
  tenants in the common case to ensure no data leaks of sensitive or
  highly sensitive data. Its going to be an important safeguard,
  especially in industries like US Financial and US Federal.

  Operators that don't handle sensitive or highly sensitive data can
  'volume_clear = none'.

  And the unexpected case of a configuration error or typo ensures the
  system fails safe. In fact, specifying 'volume_clear = 1' or
  'volume_clear = true' or 'volume_clear = yes' should trigger the
  unexpected fail open.

  From the low hanging fruit department.... Feel free to release it at
  any time. The "security vulnerability" was checked to ensure the
  security folks had an opportunity to provide feedback.

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



From fungi at yuggoth.org  Tue May 27 17:15:29 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 27 May 2014 17:15:29 -0000
Subject: [Openstack-security] [Bug 1322766] Re: Cinder wipe/shred fails open
References: <20140523222522.10305.61680.malonedeb@gac.canonical.com>
Message-ID: <20140527171529.9999.22403.malone@gac.canonical.com>

Also, it may be worth marking this as a duplicate of (fixed) bug
1225194.

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

Title:
  Cinder wipe/shred fails open

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

Bug description:
  Previously, lvm_type=default signified a volume should be zero'd or
  wiped when deleting the volume. Zeroization could be avoided with
  lvm_type=thin. At
  https://github.com/openstack/cinder/commit/bb06ebd0f6a75a6ba55a7c022de96a91e3750d20,
  the following was added:

      volume_clear = none, zero, shred
      volume_clear_size = size_in_MiB

  Looking at the code from the commit, the default behavior of wiping
  was changed, and the change resulted in a "fail open". That is, no
  wipe occurs on configuration errors or typos:

  +        LOG.info(_("Performing secure delete on volume: %s") % volume['id'])
  +
  +        if FLAGS.volume_clear == 'zero':
  +            if size_in_m == 0:
  +                return self._copy_volume('/dev/zero', vol_path, size_in_g)
  +            else:
  +                clear_cmd = ['shred', '-n0', '-z', '-s%dMiB' % size_in_m]
  +        elif FLAGS.volume_clear == 'shred':
  +            clear_cmd = ['shred', '-n3']
  +            if size_in_m:
  +                clear_cmd.append('-s%dMiB' % size_in_m)
  +        else:
  +            LOG.error(_("Error unrecognized volume_clear option: %s"),
  +                      FLAGS.volume_clear)
  +            return

  Perhaps previous behavior should be restored:

      * default = one pass of 0's
      * a valid config changes the behavior
      * an invalid config still uses default behavior

  I think it s important to ensure cinder serves zero'ized block among
  tenants in the common case to ensure no data leaks of sensitive or
  highly sensitive data. Its going to be an important safeguard,
  especially in industries like US Financial and US Federal.

  Operators that don't handle sensitive or highly sensitive data can
  'volume_clear = none'.

  And the unexpected case of a configuration error or typo ensures the
  system fails safe. In fact, specifying 'volume_clear = 1' or
  'volume_clear = true' or 'volume_clear = yes' should trigger the
  unexpected fail open.

  From the low hanging fruit department.... Feel free to release it at
  any time. The "security vulnerability" was checked to ensure the
  security folks had an opportunity to provide feedback.

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



From 1319943 at bugs.launchpad.net  Tue May 27 17:43:10 2014
From: 1319943 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 27 May 2014 17:43:10 -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: <20140527174310.9719.97513.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/93787
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=5dda3a6ab2becb5dd0b58c088f6daad807e12276
Submitter: Jenkins
Branch:    master

commit 5dda3a6ab2becb5dd0b58c088f6daad807e12276
Author: Matt Riedemann <mriedem at us.ibm.com>
Date:   Thu May 15 12:22:19 2014 -0700

    Mask block_device_info auth_password in virt driver debug logs
    
    The block_device_info object can have an auth_password key which is
    getting logged at debug level in several virt drivers so we need to
    sanitize the message getting logged.
    
    Adds tests to ensure the logged messages are properly sanitized.
    
    Note that bug 1321785 was opened to track the long-term design issues
    with storing the password in the block_device_info dict since this can
    crop up elsewhere if it's logged.  The immediate fix here is to mask
    what's already exposed.
    
    Closes-Bug: #1319943
    
    Change-Id: I0eae07ce3f0f39861eb97ec3dec44895386c7d04


** Changed in: nova
       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/1319943

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

Status in OpenStack Compute (Nova):
  Fix Committed

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 1174499 at bugs.launchpad.net  Wed May 28 01:26:37 2014
From: 1174499 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 28 May 2014 01:26:37 -0000
Subject: [Openstack-security] [Bug 1174499] Related fix merged to
	python-keystoneclient (master)
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140528012637.30457.55411.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/92499
Committed: https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=41b3abd42dbadab536bfd3793211ca001e7ffc8d
Submitter: Jenkins
Branch:    master

commit 41b3abd42dbadab536bfd3793211ca001e7ffc8d
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue May 6 19:33:46 2014 -0500

    auth_token hashes PKI token once
    
    auth_token was hashing the PKI token multiple times. With this
    change, the token is hashed once.
    
    Change-Id: I70d3339d09deb2d3528f141d37138971038f4075
    Related-Bug: #1174499

-- 
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 OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (Keystone):
  Fix Committed
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  In Progress

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/horizon/+bug/1174499/+subscriptions



From gerrit2 at review.openstack.org  Wed May 28 01:40:45 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 28 May 2014 01:40:45 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WpSrF-0007gd-0r@review.openstack.org>


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

Log:
commit 22db04bb6bee3ab15a90510bb6c1780d2a254300
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue May 6 19:36:59 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From 1174499 at bugs.launchpad.net  Wed May 28 01:40:41 2014
From: 1174499 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 28 May 2014 01:40:41 -0000
Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140528014043.9926.18877.launchpad@gac.canonical.com>

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

-- 
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 OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (Keystone):
  Fix Committed
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  In Progress

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/horizon/+bug/1174499/+subscriptions



From 1174499 at bugs.launchpad.net  Wed May 28 05:11:44 2014
From: 1174499 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 28 May 2014 05:11:44 -0000
Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140528051144.15619.52487.malone@soybean.canonical.com>

Reviewed:  https://review.openstack.org/80398
Committed: https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=22db04bb6bee3ab15a90510bb6c1780d2a254300
Submitter: Jenkins
Branch:    master

commit 22db04bb6bee3ab15a90510bb6c1780d2a254300
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue May 6 19:36:59 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80


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

Title:
  Keystone token hashing is MD5

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

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/horizon/+bug/1174499/+subscriptions



From m.channappa.negalur at accenture.com  Wed May 28 10:36:08 2014
From: m.channappa.negalur at accenture.com (m.channappa.negalur at accenture.com)
Date: Wed, 28 May 2014 10:36:08 +0000
Subject: [Openstack-security] Autoscaling : JEOS images problem
Message-ID: <62B2E0AF85006349B035A166913276B20B3BDA46@048-CH1MPN3-391.048d.mgd.msft.net>

Hello team,
I was using below images  to launch a stack  for autoscaling  on my openstack Havana setup.

http://fedorapeople.org/groups/heat/prebuilt-jeos-images/

but here

F17-x86_64-cfntools.qcow2<http://fedorapeople.org/groups/heat/prebuilt-jeos-images/F17-x86_64-cfntools.qcow2>                         02-Jun-2013 22:22  455M  -- working fine , but packages I am not getting
F18-x86_64-cfntools.qcow2<http://fedorapeople.org/groups/heat/prebuilt-jeos-images/F18-x86_64-cfntools.qcow2>                         06-Feb-2014 04:22  490M  --- unable to mount some of the file system, many services failing while booting
F18-x86_64-openshift-origin-broker-cfntools.qcow2<http://fedorapeople.org/groups/heat/prebuilt-jeos-images/F18-x86_64-openshift-origin-broker-cfntools.qcow2> 29-May-2013 11:43  728M  -- don't know can I use it
F18-x86_64-openshift-origin-node-cfntools.qcow2<http://fedorapeople.org/groups/heat/prebuilt-jeos-images/F18-x86_64-openshift-origin-node-cfntools.qcow2>   29-May-2013 16:01  963M  -- don't know can I use it
F19-i386-cfntools.qcow2<http://fedorapeople.org/groups/heat/prebuilt-jeos-images/F19-i386-cfntools.qcow2>                           05-Oct-2013 19:47  448M  --- metalink problem , unable to download packages
F19-x86_64-cfntools.qcow2<http://fedorapeople.org/groups/heat/prebuilt-jeos-images/F19-x86_64-cfntools.qcow2>    -- For all images my openstack is able to launch a instance , but for this images pops "Valid Host not found error"



Please suggest me can I try any other images ...

Regards,
Malleshi CN

________________________________

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.
______________________________________________________________________________________

www.accenture.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140528/9da8c89c/attachment.html>

From robert.clark at hp.com  Wed May 28 11:29:53 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Wed, 28 May 2014 11:29:53 +0000
Subject: [Openstack-security] Autoscaling : JEOS images problem
Message-ID: <CFAB867D.F68E%robert.clark@hp.com>

Hi Malleshi,

I’m not sure that this is a security specific question, you will probably get a better response from reaching out to the general list:


From: "m.channappa.negalur at accenture.com<mailto:m.channappa.negalur at accenture.com>" <m.channappa.negalur at accenture.com<mailto:m.channappa.negalur at accenture.com>>
Date: Wednesday, 28 May 2014 11:36
To: "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: [Openstack-security] Autoscaling : JEOS images problem

Hello team,
I was using below images  to launch a stack  for autoscaling  on my openstack Havana setup.

http://fedorapeople.org/groups/heat/prebuilt-jeos-images/

but here

F17-x86_64-cfntools.qcow2<http://fedorapeople.org/groups/heat/prebuilt-jeos-images/F17-x86_64-cfntools.qcow2>                         02-Jun-2013 22:22  455M  -- working fine , but packages I am not getting
F18-x86_64-cfntools.qcow2<http://fedorapeople.org/groups/heat/prebuilt-jeos-images/F18-x86_64-cfntools.qcow2>                         06-Feb-2014 04:22  490M  --- unable to mount some of the file system, many services failing while booting
F18-x86_64-openshift-origin-broker-cfntools.qcow2<http://fedorapeople.org/groups/heat/prebuilt-jeos-images/F18-x86_64-openshift-origin-broker-cfntools.qcow2> 29-May-2013 11:43  728M  -- don’t know can I use it
F18-x86_64-openshift-origin-node-cfntools.qcow2<http://fedorapeople.org/groups/heat/prebuilt-jeos-images/F18-x86_64-openshift-origin-node-cfntools.qcow2>   29-May-2013 16:01  963M  -- don’t know can I use it
F19-i386-cfntools.qcow2<http://fedorapeople.org/groups/heat/prebuilt-jeos-images/F19-i386-cfntools.qcow2>                           05-Oct-2013 19:47  448M  --- metalink problem , unable to download packages
F19-x86_64-cfntools.qcow2<http://fedorapeople.org/groups/heat/prebuilt-jeos-images/F19-x86_64-cfntools.qcow2>    -- For all images my openstack is able to launch a instance , but for this images pops “Valid Host not found error”



Please suggest me can I try any other images …

Regards,
Malleshi CN

________________________________

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.
______________________________________________________________________________________

www.accenture.com



From fungi at yuggoth.org  Wed May 28 19:39:39 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 28 May 2014 19:39:39 -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: <20140528193939.25520.31860.malone@chaenomeles.canonical.com>

I've removed the advisory task, switched the bug from public security
(indicating some sort of actual vulnerability) to public, and added the
"security" tag to indicate it's a potential strengthening opportunity.

** No longer affects: ossa

** Information type changed from Public Security to Public

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

Title:
  Standard random number generators (using shuffle )  should not be used
  to generate randomness

Status in Cinder:
  Triaged

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 malini.k.bhandaru at intel.com  Thu May 29 03:55:00 2014
From: malini.k.bhandaru at intel.com (Bhandaru, Malini K)
Date: Thu, 29 May 2014 03:55:00 +0000
Subject: [Openstack-security] Security Anti-Patterns
Message-ID: <EE6FFF4F6C34C84C8C98DD2414EEA47E724216D8@fmsmsx117.amr.corp.intel.com>

Hello Everyone!

Can you think of a security anti-pattern? Share them and help make OpenStack more secure.

Below is an excerpt from the wiki under development  -- https://wiki.openstack.org/wiki/Security/OpenStack_Security_Impact_Checks



OpenStack security is getting greater scrutiny as adoption increases. At the Icehouse summit during an OSSG design session we floated the idea of incorporating automated tests to capture some security anti-patterns.

For instance, consider cinder file permissions bug<https://bugs.launchpad.net/cinder/+bug/1260679>; the extent of the bug, namely affected drivers, was determined with a grep, a check for "chmod" with promiscuous file settings for group and world. It transpired that several of the drivers were setting volume file permissions to 777 and 666!

Yet another test possible is checing for shell command executions as root. Occasionally these cannot be avoided but alerting to these helps the developer re-think the code and at the very least justify its need.

Hope to hear from you!
Malini
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140529/6c248a0c/attachment.html>

From kseifried at redhat.com  Thu May 29 04:56:52 2014
From: kseifried at redhat.com (Kurt Seifried)
Date: Wed, 28 May 2014 22:56:52 -0600
Subject: [Openstack-security] Security Anti-Patterns
In-Reply-To: <EE6FFF4F6C34C84C8C98DD2414EEA47E724216D8@fmsmsx117.amr.corp.intel.com>
References: <EE6FFF4F6C34C84C8C98DD2414EEA47E724216D8@fmsmsx117.amr.corp.intel.com>
Message-ID: <5386BE14.10907@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/28/2014 09:55 PM, Bhandaru, Malini K wrote:
> Hello Everyone!
> 
> 
> 
> Can you think of a security anti-pattern? Share them and help make 
> OpenStack more secure.
> 
> 
> 
> Below is an excerpt from the wiki under development  -- 
> https://wiki.openstack.org/wiki/Security/OpenStack_Security_Impact_Checks
>
> 
> 
> 
> 
> 
> OpenStack security is getting greater scrutiny as adoption
> increases. At the Icehouse summit during an OSSG design session we
> floated the idea of incorporating automated tests to capture some
> security anti-patterns.
> 
> For instance, consider cinder file permissions bug 
> <https://bugs.launchpad.net/cinder/+bug/1260679>; the extent of the
> bug, namely affected drivers, was determined with a grep, a check
> for "*chmod" with promiscuous file* settings for group and world.
> It transpired that several of the drivers were setting volume file 
> permissions to 777 and 666!
> 
> Yet another test possible is checing for shell command executions 
> as *root*. Occasionally these cannot be avoided but alerting to
> these helps the developer re-think the code and at the very least
> justify its need.
> 
> 
> 
> Hope to hear from you!
> 
> Malini

So I find this.. I dunno. So 20 years ago when I started doing
information security the pattern of "least privilege" was well
established. Now 20 years later everyone is discovering it yet again
(for about the, well, 20th time).

Rather then going with the easy "let's make code that works" resulting
in abuse of privileges (e.g. file modes that are 666/777), you need to
spend time and effort dialling down the privileges and testing. Not
documenting "don't use mode 666/777" (if documenting this stuff
worked, it would have worked by now!). In other words you need to
spend time auditing code (and then fixing it).

Sorry if this sounds grumpy but the fact is most people still get the
easy things wrong, to say nothing of the complicated things.

- -- 
Kurt Seifried - Red Hat - Product Security - Cloud stuff and such
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJThr4UAAoJEBYNRVNeJnmTTtQP/0xfA3YwsLZudl4Cl1DcVcKq
um9oHSQgCVnCLB6MC+/f1v44429fpj1zzc8uCaBHzabHDbX1PGPfqzTAJKwQFmpL
gM+uvtnYlbDMqwLrhVtaUyZ6yDnWXQRr0ZswZHKz3p81DWHyZpg7K71P/rx4Kr3B
cTx+DJFru5HDCl1MiJyNt+bzDTtu3Wzcudg78vK/w/mkDiAaAFmZuTidL2c2DiRN
16th1b6GfDZQk8vx9N9sv9MRiezvdjIlJ3WwjIIHJv63/FWwHKwafkjRSQr6DS+3
oCLN9MeCIla1RAaOCn8dXVYwz9m2SWoIEMkWKdpJ00Ulv3DJDZ0J86mT3fl2Yyqw
SaXDJoDJKO3AsLvmox+5MznGxhvv5Gc9h6ctAPubTHKx6kRjzYeXwry1Fws66Kh7
ACDCfv8hSEpjgUCIHBbCKZXaw1xd4k5VbuvkGybSranUNpOB6ua6tfA5qNvnrA6m
8Q0ygzo/0mdATkLWXJAQJvuDD8uFW+9vGwqzIRVihatlgwygWCNAS/9ik64bkZAx
wFvQnU4EeH8fWxrNU4+R2HPhjrmjtCvd448za5HJbkfWe0vlfgp6SQdmuxoVKUNa
BdFVY1qYZF/iBeMUdc9SHbbjHRNwrIrUSkigdY3rfhnL6jKbklw9YRtRBAq7W8/A
dCLwAIjc9K/Fldnlifd/
=p9sD
-----END PGP SIGNATURE-----



From robert.clark at hp.com  Thu May 29 06:47:39 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Thu, 29 May 2014 06:47:39 +0000
Subject: [Openstack-security] Security Anti-Patterns
In-Reply-To: <5386BE14.10907@redhat.com>
References: <EE6FFF4F6C34C84C8C98DD2414EEA47E724216D8@fmsmsx117.amr.corp.intel.com>
 <5386BE14.10907@redhat.com>
Message-ID: <CFAC95C7.F8BC%robert.clark@hp.com>



On 29/05/2014 05:56, "Kurt Seifried" <kseifried at redhat.com> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 05/28/2014 09:55 PM, Bhandaru, Malini K wrote:
>> Hello Everyone!
>> 
>> 
>> 
>> Can you think of a security anti-pattern? Share them and help make
>> OpenStack more secure.
>> 
>> 
>> 
>> Below is an excerpt from the wiki under development  --
>> 
>>https://wiki.openstack.org/wiki/Security/OpenStack_Security_Impact_Checks
>>
>> 
>> 
>> 
>> 
>> 
>> OpenStack security is getting greater scrutiny as adoption
>> increases. At the Icehouse summit during an OSSG design session we
>> floated the idea of incorporating automated tests to capture some
>> security anti-patterns.
>> 
>> For instance, consider cinder file permissions bug
>> <https://bugs.launchpad.net/cinder/+bug/1260679>; the extent of the
>> bug, namely affected drivers, was determined with a grep, a check
>> for "*chmod" with promiscuous file* settings for group and world.
>> It transpired that several of the drivers were setting volume file
>> permissions to 777 and 666!
>> 
>> Yet another test possible is checing for shell command executions
>> as *root*. Occasionally these cannot be avoided but alerting to
>> these helps the developer re-think the code and at the very least
>> justify its need.
>> 
>> 
>> 
>> Hope to hear from you!
>> 
>> Malini
>
>So I find this.. I dunno. So 20 years ago when I started doing
>information security the pattern of "least privilege" was well
>established. Now 20 years later everyone is discovering it yet again
>(for about the, well, 20th time).
>
>Rather then going with the easy "let's make code that works" resulting
>in abuse of privileges (e.g. file modes that are 666/777), you need to
>spend time and effort dialling down the privileges and testing. Not
>documenting "don't use mode 666/777" (if documenting this stuff
>worked, it would have worked by now!). In other words you need to
>spend time auditing code (and then fixing it).
>
>Sorry if this sounds grumpy but the fact is most people still get the
>easy things wrong, to say nothing of the complicated things.
>
>- -- 
>Kurt Seifried - Red Hat - Product Security - Cloud stuff and such
>PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

I certainly share your frustration, I think the idea with the
anti-patterns is to document the things that get done badly most often in
OpenStack and format them in a way that¹s easily consumable by core devs
and PTLs. The list should be short enough that they can refer back to it
while reviewing new features.

It¹s not going to fix anything on it¹s own but anything we can do to help
developers not make the same mistakes which, as you point out, have been
made for the last 20 years - is a good thing.

-Rob




From thierry.carrez+lp at gmail.com  Thu May 29 08:53:16 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 29 May 2014 08:53:16 -0000
Subject: [Openstack-security] [Bug 1322766] Re: Cinder wipe/shred fails open
References: <20140523222522.10305.61680.malonedeb@gac.canonical.com>
Message-ID: <20140529085316.15944.18868.launchpad@soybean.canonical.com>

** 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 the bug report.
https://bugs.launchpad.net/bugs/1322766

Title:
  Cinder wipe/shred fails open

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

Bug description:
  Previously, lvm_type=default signified a volume should be zero'd or
  wiped when deleting the volume. Zeroization could be avoided with
  lvm_type=thin. At
  https://github.com/openstack/cinder/commit/bb06ebd0f6a75a6ba55a7c022de96a91e3750d20,
  the following was added:

      volume_clear = none, zero, shred
      volume_clear_size = size_in_MiB

  Looking at the code from the commit, the default behavior of wiping
  was changed, and the change resulted in a "fail open". That is, no
  wipe occurs on configuration errors or typos:

  +        LOG.info(_("Performing secure delete on volume: %s") % volume['id'])
  +
  +        if FLAGS.volume_clear == 'zero':
  +            if size_in_m == 0:
  +                return self._copy_volume('/dev/zero', vol_path, size_in_g)
  +            else:
  +                clear_cmd = ['shred', '-n0', '-z', '-s%dMiB' % size_in_m]
  +        elif FLAGS.volume_clear == 'shred':
  +            clear_cmd = ['shred', '-n3']
  +            if size_in_m:
  +                clear_cmd.append('-s%dMiB' % size_in_m)
  +        else:
  +            LOG.error(_("Error unrecognized volume_clear option: %s"),
  +                      FLAGS.volume_clear)
  +            return

  Perhaps previous behavior should be restored:

      * default = one pass of 0's
      * a valid config changes the behavior
      * an invalid config still uses default behavior

  I think it s important to ensure cinder serves zero'ized block among
  tenants in the common case to ensure no data leaks of sensitive or
  highly sensitive data. Its going to be an important safeguard,
  especially in industries like US Financial and US Federal.

  Operators that don't handle sensitive or highly sensitive data can
  'volume_clear = none'.

  And the unexpected case of a configuration error or typo ensures the
  system fails safe. In fact, specifying 'volume_clear = 1' or
  'volume_clear = true' or 'volume_clear = yes' should trigger the
  unexpected fail open.

  From the low hanging fruit department.... Feel free to release it at
  any time. The "security vulnerability" was checked to ensure the
  security folks had an opportunity to provide feedback.

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



From 885165 at bugs.launchpad.net  Thu May 29 10:44:00 2014
From: 885165 at bugs.launchpad.net (Tom Fifield)
Date: Thu, 29 May 2014 10:44:00 -0000
Subject: [Openstack-security] [Bug 885165] Re: Add option to do remote host
 SSL cert verification in nova-objectstore
References: <20111102113112.3867.46165.malonedeb@soybean.canonical.com>
Message-ID: <20140529104400.563.25571.malone@gac.canonical.com>

This is now solved with CONF.s3_use_ssl

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

Title:
  Add option to do remote host SSL cert verification in nova-objectstore

Status in OpenStack Compute (Nova):
  Fix Released

Bug description:
  This bug is related to another bug which I am about to report.
  In nova/image/s3.py the _conn static method of the S3ImageService class passes in  is_secure=False,
  when creating a new boto.s3.connection.S3Connection.

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



From tristan.cacqueray at enovance.com  Thu May 29 14:59:41 2014
From: tristan.cacqueray at enovance.com (Tristan Cacqueray)
Date: Thu, 29 May 2014 10:59:41 -0400
Subject: [Openstack-security] Security Anti-Patterns
In-Reply-To: <EE6FFF4F6C34C84C8C98DD2414EEA47E724216D8@fmsmsx117.amr.corp.intel.com>
References: <EE6FFF4F6C34C84C8C98DD2414EEA47E724216D8@fmsmsx117.amr.corp.intel.com>
Message-ID: <53874B5D.7090805@enovance.com>

On 05/28/2014 11:55 PM, Bhandaru, Malini K wrote:
> Hello Everyone!
> 
> Can you think of a security anti-pattern? Share them and help make OpenStack more secure.
> 
> Below is an excerpt from the wiki under development  -- https://wiki.openstack.org/wiki/Security/OpenStack_Security_Impact_Checks
> 

Thank you Malini!
I added some classic anti-pattern to the list.

Now I wonder how to verify those automatically.
I'm afraid grep won't be enough, we might want to look at a simple ast
representation that we can use to inspect dangerous function call.

Would a PoC that highlight subprocess call with shell=True still be
useful or do we already have something in mind ?

Best regards,
Tristan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140529/0677d832/attachment.sig>

From robert.clark at hp.com  Thu May 29 15:06:17 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Thu, 29 May 2014 15:06:17 +0000
Subject: [Openstack-security] Security Anti-Patterns
In-Reply-To: <53874B5D.7090805@enovance.com>
References: <EE6FFF4F6C34C84C8C98DD2414EEA47E724216D8@fmsmsx117.amr.corp.intel.com>
 <53874B5D.7090805@enovance.com>
Message-ID: <CFAD0B38.FDBE%robert.clark@hp.com>


>On 05/28/2014 11:55 PM, Bhandaru, Malini K wrote:
>> Hello Everyone!
>> 
>> Can you think of a security anti-pattern? Share them and help make
>>OpenStack more secure.
>> 
>> Below is an excerpt from the wiki under development  --
>>https://wiki.openstack.org/wiki/Security/OpenStack_Security_Impact_Checks
>> 
>
>Thank you Malini!
>I added some classic anti-pattern to the list.
>
>Now I wonder how to verify those automatically.
>I'm afraid grep won't be enough, we might want to look at a simple ast
>representation that we can use to inspect dangerous function call.
>
>Would a PoC that highlight subprocess call with shell=True still be
>useful or do we already have something in mind ?
>
>Best regards,
>Tristan

Including Jamie (who some of you know as chair6) as he¹s been looking into
AST for exactly this purpose.

-Rob





From paul.montgomery at RACKSPACE.COM  Thu May 29 15:11:38 2014
From: paul.montgomery at RACKSPACE.COM (Paul Montgomery)
Date: Thu, 29 May 2014 15:11:38 +0000
Subject: [Openstack-security] Security Anti-Patterns
In-Reply-To: <53874B5D.7090805@enovance.com>
References: <EE6FFF4F6C34C84C8C98DD2414EEA47E724216D8@fmsmsx117.amr.corp.intel.com>
 <53874B5D.7090805@enovance.com>
Message-ID: <CFACB752.1DF1C%paul.montgomery@rackspace.com>

https://wiki.openstack.org/wiki/Security/Guidelines
Š has some good recommendations that may be of use.  I plan to tackle at
least one of the items (probably logging as that is a common issue) more
deeply this week.

Also, the OWASP top 10 might be a good place for input as well:
https://www.owasp.org/index.php/Top_10_2013-Top_10



On 5/29/14 9:59 AM, "Tristan Cacqueray" <tristan.cacqueray at enovance.com>
wrote:

>On 05/28/2014 11:55 PM, Bhandaru, Malini K wrote:
>> Hello Everyone!
>> 
>> Can you think of a security anti-pattern? Share them and help make
>>OpenStack more secure.
>> 
>> Below is an excerpt from the wiki under development  --
>>https://wiki.openstack.org/wiki/Security/OpenStack_Security_Impact_Checks
>> 
>
>Thank you Malini!
>I added some classic anti-pattern to the list.
>
>Now I wonder how to verify those automatically.
>I'm afraid grep won't be enough, we might want to look at a simple ast
>representation that we can use to inspect dangerous function call.
>
>Would a PoC that highlight subprocess call with shell=True still be
>useful or do we already have something in mind ?
>
>Best regards,
>Tristan
>




From 1315556 at bugs.launchpad.net  Thu May 29 16:51:27 2014
From: 1315556 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 29 May 2014 16:51:27 -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: <20140529165128.323.5372.launchpad@gac.canonical.com>

** Changed in: keystone
     Assignee: Guang Yee (guang-yee) => Morgan Fainberg (mdrnstm)

-- 
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):
  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 1287301 at bugs.launchpad.net  Thu May 29 16:52:53 2014
From: 1287301 at bugs.launchpad.net (Dolph Mathews)
Date: Thu, 29 May 2014 16:52:53 -0000
Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache
 doesn't respect revoked tokens
References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com>
Message-ID: <20140529165255.524.40324.launchpad@gac.canonical.com>

** Changed in: python-keystoneclient
    Milestone: None => 0.9.0

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

Title:
  Keystone client token cache doesn't respect revoked tokens

Status in OpenStack Security Advisories:
  Invalid
Status in Python client library for Keystone:
  Fix Committed

Bug description:
  If we'll enable caching for keystoneclient tokens we'll be able to use
  tokens that are already revoked if they are present in cache:

  https://github.com/openstack/python-
  keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831

  steps to recreate:
  1) get a token
  2) use it to make a request via keystoneclient using default properties (thus it will be cached)
  3) delete the token
  4) use the token to make another request via keystoneclient

  expected result: the token should not work (HTTP 401)
  actual result: the token still works

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



From 1174499 at bugs.launchpad.net  Thu May 29 16:53:54 2014
From: 1174499 at bugs.launchpad.net (Dolph Mathews)
Date: Thu, 29 May 2014 16:53:54 -0000
Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140529165356.16723.34944.launchpad@wampee.canonical.com>

** Changed in: python-keystoneclient
    Milestone: None => 0.9.0

-- 
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 OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (Keystone):
  Fix Committed
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  Fix Committed

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/horizon/+bug/1174499/+subscriptions



From 1287301 at bugs.launchpad.net  Thu May 29 17:04:19 2014
From: 1287301 at bugs.launchpad.net (Dolph Mathews)
Date: Thu, 29 May 2014 17:04:19 -0000
Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache
 doesn't respect revoked tokens
References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com>
Message-ID: <20140529170421.32424.84366.launchpad@gac.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/1287301

Title:
  Keystone client token cache doesn't respect revoked tokens

Status in OpenStack Security Advisories:
  Invalid
Status in Python client library for Keystone:
  Fix Released

Bug description:
  If we'll enable caching for keystoneclient tokens we'll be able to use
  tokens that are already revoked if they are present in cache:

  https://github.com/openstack/python-
  keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831

  steps to recreate:
  1) get a token
  2) use it to make a request via keystoneclient using default properties (thus it will be cached)
  3) delete the token
  4) use the token to make another request via keystoneclient

  expected result: the token should not work (HTTP 401)
  actual result: the token still works

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



From kseifried at redhat.com  Thu May 29 17:13:40 2014
From: kseifried at redhat.com (Kurt Seifried)
Date: Thu, 29 May 2014 11:13:40 -0600
Subject: [Openstack-security] Security Anti-Patterns
In-Reply-To: <CFAC95C7.F8BC%robert.clark@hp.com>
References: <EE6FFF4F6C34C84C8C98DD2414EEA47E724216D8@fmsmsx117.amr.corp.intel.com>
 <5386BE14.10907@redhat.com> <CFAC95C7.F8BC%robert.clark@hp.com>
Message-ID: <53876AC4.3030002@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/29/2014 12:47 AM, Clark, Robert Graham wrote:
> I certainly share your frustration, I think the idea with the 
> anti-patterns is to document the things that get done badly most
> often in OpenStack and format them in a way that¹s easily
> consumable by core devs and PTLs. The list should be short enough
> that they can refer back to it while reviewing new features.
> 
> It¹s not going to fix anything on it¹s own but anything we can do
> to help developers not make the same mistakes which, as you point
> out, have been made for the last 20 years - is a good thing.
> 
> -Rob

So a concrete example, I wrote this in 2012? Nothing new, all this
goes back a few decades:

https://kurt.seifried.org/2012/03/14/creating-temporary-files-securely/

Then I checkout all the source code:

http://git.openstack.org/cgit

find ./ -name "*.py" -o -name "*.sh" | xargs grep "/tmp/" | grep -v
test | grep -v "#"

344 results, some of the more severe ones that probably need CVE's:

./neutron/neutron/plugins/openvswitch/agent/xenapi/contrib/build-rpm.sh:rm
- -rf /tmp/$PACKAGE
./neutron/neutron/plugins/openvswitch/agent/xenapi/contrib/build-rpm.sh:mkdir
/tmp/$PACKAGE
./neutron/neutron/plugins/openvswitch/agent/xenapi/contrib/build-rpm.sh:cp
- -r ../etc/xapi.d /tmp/$PACKAGE

and then trove:

./trove/trove/guestagent/datastore/redis/service.py:TMP_REDIS_CONF =
'/tmp/redis.conf.tmp'
./trove/trove/guestagent/datastore/cassandra/system.py:CASSANDRA_TEMP_CONF
= "/tmp/cassandra.yaml"
./trove/trove/guestagent/datastore/cassandra/system.py:CASSANDRA_TEMP_DIR
= "/tmp/cassandra"
./trove/trove/guestagent/datastore/cassandra/system.py:CASSANDRA_STATUS =
"""echo "use system;" > /tmp/check; cqlsh -f /tmp/check"""
./trove/trove/guestagent/datastore/mysql/service.py:TMP_MYCNF =
"/tmp/my.cnf.tmp"
./trove/trove/guestagent/datastore/mysql/service.py:MYCNF_OVERRIDES_TMP =
"/tmp/overrides.cnf.tmp"
./trove/trove/guestagent/datastore/mongodb/system.py:TMP_CONFIG =
"/tmp/mongodb.conf.tmp"
./trove/trove/guestagent/strategies/restore/mysql_impl.py:
            ' --ibbackup xtrabackup 2>/tmp/innoprepare.log')
./trove/trove/guestagent/strategies/restore/mysql_impl.py:
            ' 2>/tmp/innoprepare.log')
./trove/trove/guestagent/strategies/backup/mysql_impl.py:
'2>/tmp/mysqldump.log' %
./trove/trove/guestagent/strategies/backup/mysql_impl.py:
  ' /var/lib/mysql 2>/tmp/innobackupex.log'
./trove/trove/guestagent/strategies/backup/mysql_impl.py:        with
open('/tmp/innobackupex.log', 'r') as backup_log:
./trove/trove/guestagent/strategies/backup/mysql_impl.py:        with
open('/tmp/innobackupex.log', 'r') as backup_log:
./trove/trove/guestagent/strategies/backup/mysql_impl.py:
  ' 2>/tmp/innobackupex.log')

Here's an amusing one:

./sahara/sahara/plugins/vanilla/v1_2_1/run_scripts.py:        'sudo su
- - -c "mkdir /tmp/oozielib && '
./sahara/sahara/plugins/vanilla/v1_2_1/run_scripts.py:        'tar zxf
/opt/oozie/oozie-sharelib-4.0.0.tar.gz -C /tmp/oozielib && '
./sahara/sahara/plugins/vanilla/v1_2_1/run_scripts.py:        'hadoop
fs -put /tmp/oozielib/share share && '
./sahara/sahara/plugins/vanilla/v1_2_1/run_scripts.py:        'rm -rf
/tmp/oozielib" hadoop')
./sahara/sahara/plugins/vanilla/v1_2_1/run_scripts.py:
remote.execute_command("mysql -u root < /tmp/create_oozie_db.sql")
./sahara/sahara/plugins/vanilla/v1_2_1/run_scripts.py:
remote.execute_command("mysql -u root < /tmp/create_hive_db.sql")

So in total there's about 100-300 of these that qualify as LOW
security vulns.

So yeah we can tell people not to do this, but apparently it's not
working. Plus there's a huge technical debt that needs to be cleared out.

Oh and for mode 666/777 stuff:

./nodepool/nodepool/nodepool.py:        host.ssh("chmod config dir",
"sudo chmod 0777 /etc/nodepool")
./trove/trove/guestagent/strategies/restore/mysql_impl.py:
utils.execute_with_timeout("chmod", "-R", "0777",
./anvil/anvil/distros/rhel.py:
sh.chmod(sh.joinpths(base_dir, fn), 0o666)
./sahara/sahara/plugins/hdp/versions/version_2_0_6/services.py:
     r.execute_command('su -c "hadoop fs -chmod -R 777 '
./sahara/sahara/plugins/hdp/versions/version_1_3_2/services.py:
     r.execute_command('su -c "hadoop fs -chmod -R 777 '
./manila/manila/share/drivers/generic.py:        command = ['sudo',
'chmod', '777', mount_path]
./manila/manila/share/drivers/lvm.py:
self._execute('chmod', '777', mount_path,
./cinder/cinder/volume/drivers/scality.py:        os.chmod(path, 0o666)
./cinder/cinder/volume/drivers/huawei/rest_common.py:
utils.execute('chmod', '777', filepath, run_as_root=True)
./cinder/cinder/volume/drivers/huawei/ssh_common.py:
utils.execute('chmod', '777', filepath, run_as_root=True)
./compass-core/bin/manage_db.py:
os.chmod(setting.DATABASE_FILE, 0o777)
./compass-core/install/cobbler.sh:sudo chmod 777 /var/lib/cobbler/snippets
./compass-core/install/cobbler.sh:sudo chmod -R 666
/var/lib/cobbler/snippets/*
./compass-core/install/cobbler.sh:sudo chmod 666
/var/lib/cobbler/kickstarts/default.ks
./compass-core/install/cobbler.sh:sudo chmod 666
/var/lib/cobbler/kickstarts/default.seed
./compass-core/install/compass.sh:sudo chmod -R 777 /opt/compass/db
./compass-core/install/compass.sh:sudo chmod -R 777 /var/log/compass

With advance apologies to Garth/Grant in case we end up with 100+ CVE's =)

- -- 
Kurt Seifried - Red Hat - Product Security - Cloud stuff and such
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJTh2rEAAoJEBYNRVNeJnmTemMQAJoh0YGmncufT3yNQSGpG2IW
DCuLWMqyIOOVtD8gO0pfeytEHIo83870ZbzsNXeLPzFsfTBUSWdq3APRklttNS3M
1KPfKopw4K2NRAjX4f6n+F8iY3opE9ytm8nm8uAvCC3GvSOYOOxHr/ixtsLdU47R
kZSJuasDUjLST2nipFI9zYkNZBy3aVtsYlHXhuy8giT4UAb3Sq/kIArFOADJkhPg
+RtwqA92KVE/ytLfYu/uBWU99/sUrDD1FvmljJE6mUDRi36eOZdc4hmvS9GVthBW
78upxZeWEgVUan7nA7mPe3etnG6xaLMFusD1hegmH9rUeO7XDDAKByaAqLYYN/7f
OyJ+9zVib8wklIdasQiGi7LBx9CGJrynl7/eWJoWjRI9JLR9esjhxS/GOp9AtNUM
4pxY1UUr3La+YmXRxPfqcO0XRMSRwHLO73an2ALbMbatVORuHlSq+oYRvWXDijb+
jC9uYKXUhTyj/AkVe2YBVLSCZX5lQ7kc62ivPkhfz2XmmTB2GJuYAulUMu/9lYG7
ALEKoj8AhWF8c4IWb87j/x0Vx+sc9siOtrArr5biMmNILZlAyjbRvgu4j7HVV0TL
+pBGYkbQahOSzW/2l7EjKxtM9CFTT97YQgSVFwwsD50BlPfvBxYNwa2JYGdtHnJt
RJ1lR3TeVKpaRm0jiU6O
=/xzE
-----END PGP SIGNATURE-----



From Travis_McPeak at symantec.com  Thu May 29 17:18:41 2014
From: Travis_McPeak at symantec.com (Travis McPeak)
Date: Thu, 29 May 2014 10:18:41 -0700
Subject: [Openstack-security] Automated detection of anti patterns
Message-ID: <CFACB98E.3A19%travis_mcpeak@symantec.com>

I¹ve been working on a tool that will look through Python code instances
of something.  Right now it is a simple case and I¹m using it to look for
crypto library imports and calls, but I¹m envisioning expanding
functionality to be more versatile eventually.  This might be a good place
to automatically scan for anti patterns.

Thanks,
  -Travis




On 5/29/14, 10:13 AM, "openstack-security-request at lists.openstack.org"
<openstack-security-request at lists.openstack.org> wrote:

>Thank you Malini!
>I added some classic anti-pattern to the list.
>
>Now I wonder how to verify those automatically.
>I'm afraid grep won't be enough, we might want to look at a simple ast
>representation that we can use to inspect dangerous function call.
>
>Would a PoC that highlight subprocess call with shell=True still be
>useful or do we already have something in mind ?
>
>Best regards,
>Tristan




From 1174499 at bugs.launchpad.net  Thu May 29 17:18:47 2014
From: 1174499 at bugs.launchpad.net (Dolph Mathews)
Date: Thu, 29 May 2014 17:18:47 -0000
Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140529171849.740.2741.launchpad@gac.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/1174499

Title:
  Keystone token hashing is MD5

Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (Keystone):
  Fix Committed
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/horizon/+bug/1174499/+subscriptions



From dstanek at dstanek.com  Thu May 29 17:45:04 2014
From: dstanek at dstanek.com (David Stanek)
Date: Thu, 29 May 2014 13:45:04 -0400
Subject: [Openstack-security] Automated detection of anti patterns
In-Reply-To: <CFACB98E.3A19%travis_mcpeak@symantec.com>
References: <CFACB98E.3A19%travis_mcpeak@symantec.com>
Message-ID: <CAO69Nd=z_EfFBm9z0KaO6VDApOZ=0VbY+z9wdJwo8J0MLg0vCA@mail.gmail.com>

Hi Travis,

That sounds like a great idea. Are you able to publish it somewhere?


On Thu, May 29, 2014 at 1:18 PM, Travis McPeak <Travis_McPeak at symantec.com>
wrote:

> I¹ve been working on a tool that will look through Python code instances
> of something.  Right now it is a simple case and I¹m using it to look for
> crypto library imports and calls, but I¹m envisioning expanding
> functionality to be more versatile eventually.  This might be a good place
> to automatically scan for anti patterns.
>
> Thanks,
>   -Travis
>
>
>
>
> On 5/29/14, 10:13 AM, "openstack-security-request at lists.openstack.org"
> <openstack-security-request at lists.openstack.org> wrote:
>
> >Thank you Malini!
> >I added some classic anti-pattern to the list.
> >
> >Now I wonder how to verify those automatically.
> >I'm afraid grep won't be enough, we might want to look at a simple ast
> >representation that we can use to inspect dangerous function call.
> >
> >Would a PoC that highlight subprocess call with shell=True still be
> >useful or do we already have something in mind ?
> >
> >Best regards,
> >Tristan
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>



-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140529/3aa118e5/attachment.html>

From gerrit2 at review.openstack.org  Thu May 29 21:19:35 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 29 May 2014 21:19:35 +0000
Subject: [Openstack-security] [openstack/ironic] SecurityImpact review
 request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e
Message-ID: <E1Wq7jb-0006hv-Il@review.openstack.org>


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

Log:
commit 76ffc9376ea99939e9ac6be1ece84fb708d1e737
Author: Josh Gachnang <josh at pcsforeducation.com>
Date:   Wed Mar 19 16:47:38 2014 -0700

    Adding swift temp url support
    
    This patch will allow properly configured Glance servers to return a temporary
    URL for an object hosted on Swift. It will require Glance to use Swift
    as its backend. A temporary URL will let the agent download an image from
    Glance without requiring an auth_token, which gives access more than just
    Glance. The easiest way to use it is to enable direct_url in Glance, but
    you can set the appropriate config options to avoid needing to enable it.
    
    We/I need to add a note in the docs about Swift being a possible dependency
    for Ironic deploys using IPA, along with how to set the Temp URL key.
    
    Swift perfomance concerns will be addressed in this blueprint:
    https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads
    
    SecurityImpact
    DocImpact
    
    Implements: blueprint swift-temp-urls
    Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e




From 1320056 at bugs.launchpad.net  Thu May 29 23:24:25 2014
From: 1320056 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 29 May 2014 23:24:25 -0000
Subject: [Openstack-security] [Bug 1320056] Change abandoned on cinder
	(stable/icehouse)
References: <20140516032022.25328.55432.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140529232426.16312.98649.malone@wampee.canonical.com>

Change abandoned by Jay Bryant (jsbryant at us.ibm.com) on branch: stable/icehouse
Review: https://review.openstack.org/94711
Reason: It was decided that we will not backport this.  A Blueprint is being created to get this fixed 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/1320056

Title:
  Cinder utils SSHPool should allow customized ssh host keys and missing
  policy

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

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 1315556 at bugs.launchpad.net  Thu May 29 23:37:38 2014
From: 1315556 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 29 May 2014 23:37:38 -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: <20140529233738.19312.92855.malone@soybean.canonical.com>

Reviewed:  https://review.openstack.org/94251
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=5db0ce63f33f6d4aec43143ae6e6fa62ad5c9025
Submitter: Jenkins
Branch:    master

commit 5db0ce63f33f6d4aec43143ae6e6fa62ad5c9025
Author: guang-yee <guang.yee at hp.com>
Date:   Mon May 19 12:14:38 2014 -0700

    Make sure scoping to the project of a disabled domain result in 401.
    
    Addresses the problem where we check for the validity of the scoped project,
    we did not subsequently making sure its domain is also enabled.
    
    Change-Id: I24e539aea9bb0ef0a22727fd9c1fb5d9d2ad1353
    Closes-Bug: 1315556


** Changed in: keystone
       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/1315556

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

Status in OpenStack Identity (Keystone):
  Fix Committed

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 nkinder at redhat.com  Fri May 30 00:14:09 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Thu, 29 May 2014 17:14:09 -0700
Subject: [Openstack-security] Outstanding Security Notes (OSSNs) - Any
	Volunteers?
Message-ID: <5387CD51.8080809@redhat.com>

Hi,

We have a few outstanding OpenStack Security Note bugs that are
unassigned.  The outstanding bugs are listed here

  https://bugs.launchpad.net/ossn/

I know we have a lot of group members who recently joined who are
hopefully looking for ways to contribute.  Writing a Security Note is a
great way to start!  The process is well outlined on the wiki, and I am
happy to help anyone through the process.  Details on the process are
available here:

  https://wiki.openstack.org/wiki/Security/Security_Note_Process

If you are not familiar with our overall Security Note effort, you might
want to watch the OSSG talk from the Juno Summit to learn what they are
all about:


https://www.openstack.org/summit/openstack-summit-atlanta-2014/session-videos/presentation/openstack-security-group-ossg-an-update-on-our-progress-and-plans

Please let me know if you are interested in writing one of the
outstanding Security Notes.

Thanks,
-NGK



From robert.clark at hp.com  Fri May 30 06:48:44 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Fri, 30 May 2014 06:48:44 +0000
Subject: [Openstack-security] Minutes from OSSG Meeting 29th May
Message-ID: <CFADE85A.1026D%robert.clark@hp.com>

============================================
#openstack-meeting: openstack security group
============================================


Meeting started by hyakuhei at 18:00:52 UTC.  The full logs are
available at
http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-05-29-18.00.log.html
.



Meeting summary
---------------

* logging  (hyakuhei, 18:04:08)
  * LINK:
    https://wiki.openstack.org/wiki/Security/Guidelines/logging_guidelines
    (hyakuhei, 18:04:24)

* OSSG Mid-Cycle Meetup  (hyakuhei, 18:10:43)
  * ACTION: bdpayne to create an etherpad and state his preference for
    dates for the OSSG meetup  (hyakuhei, 18:23:21)
  * LINK: https://etherpad.openstack.org/p/ossg-juno-meetup  (bdpayne,
    18:26:29)
  * LINK: https://etherpad.openstack.org/p/ossg-juno-meetup  (bdpayne,
    18:27:59)

* OSSN  (hyakuhei, 18:28:47)
  * LINK: here's the open OSSG tickets https://bugs.launchpad.net/ossn
    (bdpayne, 18:31:15)
  * LINK: https://wiki.openstack.org/wiki/Security_Notes  (nkinder,
    18:31:33)

* any other business  (hyakuhei, 18:32:23)



Meeting ended at 18:36:20 UTC.



Action items, by person
-----------------------

* bdpayne
  * bdpayne to create an etherpad and state his preference for dates for
    the OSSG meetup



People present (lines said)
---------------------------

* hyakuhei (96)
* bdpayne (43)
* nkinder (28)
* mxin (27)
* paulmo (20)
* tmcpeak (19)
* bknudson (8)
* openstack (3)
* CristianF (3)
* chair6 (2)




From thierry at openstack.org  Fri May 30 08:25:53 2014
From: thierry at openstack.org (Thierry Carrez)
Date: Fri, 30 May 2014 10:25:53 +0200
Subject: [Openstack-security] Security Anti-Patterns
In-Reply-To: <53876AC4.3030002@redhat.com>
References: <EE6FFF4F6C34C84C8C98DD2414EEA47E724216D8@fmsmsx117.amr.corp.intel.com>
 <5386BE14.10907@redhat.com> <CFAC95C7.F8BC%robert.clark@hp.com>
 <53876AC4.3030002@redhat.com>
Message-ID: <53884091.2040201@openstack.org>

Kurt Seifried wrote:
> On 05/29/2014 12:47 AM, Clark, Robert Graham wrote:
>> I certainly share your frustration, I think the idea with the 
>> anti-patterns is to document the things that get done badly most
>> often in OpenStack and format them in a way that¹s easily
>> consumable by core devs and PTLs. The list should be short enough
>> that they can refer back to it while reviewing new features.
> 
>> It¹s not going to fix anything on it¹s own but anything we can do
>> to help developers not make the same mistakes which, as you point
>> out, have been made for the last 20 years - is a good thing.
> 
>> -Rob
> 
> So a concrete example, I wrote this in 2012? Nothing new, all this
> goes back a few decades:
> 
> https://kurt.seifried.org/2012/03/14/creating-temporary-files-securely/
> 
> Then I checkout all the source code:
> [...]

Yes, it's frustrating. We run those greps from time to time, fix stuff,
but then some new are added, or some new component appears with its own
share.

Ideally we would write a hacking-style test that we would gate against
(to prevent reintroduction) and run those greps at incubation time (to
prevent new components from inserting them).

The problem is, to make it part of gating we'd have to come with an
automated detection that would be right most of the time (and that you
can actively disable in remaining cases). However we receive a lot of
automated reports at the VMT lately, and more than half of them are
actually shallow and do not represent a real vulnerability -- automated
detection is hard.

So this is not a simple problem.

-- 
Thierry Carrez (ttx)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140530/fdee9a20/attachment.sig>

From robert.clark at hp.com  Fri May 30 08:29:59 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Fri, 30 May 2014 08:29:59 +0000
Subject: [Openstack-security] Security Anti-Patterns
In-Reply-To: <53884091.2040201@openstack.org>
References: <EE6FFF4F6C34C84C8C98DD2414EEA47E724216D8@fmsmsx117.amr.corp.intel.com>
 <5386BE14.10907@redhat.com> <CFAC95C7.F8BC%robert.clark@hp.com>
 <53876AC4.3030002@redhat.com> <53884091.2040201@openstack.org>
Message-ID: <CFADFFB3.104CD%robert.clark@hp.com>

On 30/05/2014 09:25, "Thierry Carrez" <thierry at openstack.org> wrote:


>Kurt Seifried wrote:
>> On 05/29/2014 12:47 AM, Clark, Robert Graham wrote:
>>> I certainly share your frustration, I think the idea with the
>>> anti-patterns is to document the things that get done badly most
>>> often in OpenStack and format them in a way that¹s easily
>>> consumable by core devs and PTLs. The list should be short enough
>>> that they can refer back to it while reviewing new features.
>> 
>>> It¹s not going to fix anything on it¹s own but anything we can do
>>> to help developers not make the same mistakes which, as you point
>>> out, have been made for the last 20 years - is a good thing.
>> 
>>> -Rob
>> 
>> So a concrete example, I wrote this in 2012? Nothing new, all this
>> goes back a few decades:
>> 
>> https://kurt.seifried.org/2012/03/14/creating-temporary-files-securely/
>> 
>> Then I checkout all the source code:
>> [...]
>
>Yes, it's frustrating. We run those greps from time to time, fix stuff,
>but then some new are added, or some new component appears with its own
>share.
>
>Ideally we would write a hacking-style test that we would gate against
>(to prevent reintroduction) and run those greps at incubation time (to
>prevent new components from inserting them).
>
>The problem is, to make it part of gating we'd have to come with an
>automated detection that would be right most of the time (and that you
>can actively disable in remaining cases). However we receive a lot of
>automated reports at the VMT lately, and more than half of them are
>actually shallow and do not represent a real vulnerability -- automated
>detection is hard.
>
>So this is not a simple problem.
>
>-- 
>Thierry Carrez (ttx)

I think there’s a lot to be gained by having tests that just flag lines as
being interesting but give only a 0 score, an advisory note that something
fishy was noticed and core-devs should take that into consideration as
part of their review.

Such tests are very much on the OSSG roadmap and we hope to get some
written up at the mid-cycle meet up if not before.

-Rob


From thierry at openstack.org  Fri May 30 08:44:43 2014
From: thierry at openstack.org (Thierry Carrez)
Date: Fri, 30 May 2014 10:44:43 +0200
Subject: [Openstack-security] Security Anti-Patterns
In-Reply-To: <CFADFFB3.104CD%robert.clark@hp.com>
References: <EE6FFF4F6C34C84C8C98DD2414EEA47E724216D8@fmsmsx117.amr.corp.intel.com>
 <5386BE14.10907@redhat.com> <CFAC95C7.F8BC%robert.clark@hp.com>
 <53876AC4.3030002@redhat.com> <53884091.2040201@openstack.org>
 <CFADFFB3.104CD%robert.clark@hp.com>
Message-ID: <538844FB.9070003@openstack.org>

Clark, Robert Graham wrote:
> I think there’s a lot to be gained by having tests that just flag lines as
> being interesting but give only a 0 score, an advisory note that something
> fishy was noticed and core-devs should take that into consideration as
> part of their review.
> 
> Such tests are very much on the OSSG roadmap and we hope to get some
> written up at the mid-cycle meet up if not before.

Yes, line flagging would be a useful first step for awareness. "This
looks like you're creating a temporary file with a predictable name.
Read here for more information on that problem !" or "You required this
shell command to be run as root. Are you sure root is really necessary ?
Are you sure this is not covered by another already-allowed command ?"

-- 
Thierry Carrez (ttx)



From duncan.thomas at gmail.com  Fri May 30 10:30:00 2014
From: duncan.thomas at gmail.com (Duncan Thomas)
Date: Fri, 30 May 2014 10:30:00 -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: <20140530103000.19825.33419.malone@soybean.canonical.com>

I think it's technically a security vulnerability, but of the most
academic nature possible. We should (and will - fix on the way) fix it,
but it isn't worthy of special treatment or an OSSA.

-- 
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:
  Triaged
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 1319643 at bugs.launchpad.net  Fri May 30 11:58:38 2014
From: 1319643 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 30 May 2014 11:58:38 -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: <20140530115838.26268.33134.malone@wampee.canonical.com>

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

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

** Changed in: cinder
     Assignee: (unassigned) => Ollie Leahy (oliver-leahy-l)

-- 
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:
  In Progress
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 hornenj at ncbi.nlm.nih.gov  Fri May 30 12:38:37 2014
From: hornenj at ncbi.nlm.nih.gov (Nigel Horne)
Date: Fri, 30 May 2014 08:38:37 -0400
Subject: [Openstack-security] OSSN Advisories
Message-ID: <53887BCD.80405@ncbi.nlm.nih.gov>

I have a question about how advisories are publicised.

Is there a separate announce e-mail list, such as that at 
http://lists.centos.org/pipermail/centos-announce/2014-May/subject.html? 
If so it would help tremendously because I could write a program to 
automate parsing and create a Jira ticket when something is announced 
(which is what I do with the CentOS list).

Thanks.

-Nigel



From 1319643 at bugs.launchpad.net  Fri May 30 13:43:14 2014
From: 1319643 at bugs.launchpad.net (Ollie Leahy)
Date: Fri, 30 May 2014 13:43:14 -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: <20140530134314.20736.90441.malone@chaenomeles.canonical.com>

I just want to note here that implementing transfer expiry, as described
in the blueprint, would be a much more valuable patch, in case anyone
can take that on.

-- 
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:
  In Progress
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 robert.clark at hp.com  Fri May 30 14:01:11 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Fri, 30 May 2014 14:01:11 +0000
Subject: [Openstack-security] OSSN Advisories
In-Reply-To: <53887BCD.80405@ncbi.nlm.nih.gov>
References: <53887BCD.80405@ncbi.nlm.nih.gov>
Message-ID: <A0C170085C37664D93EE1604364858A1123225D1@G4W3300.americas.hpqcorp.net>

Hi Nigel,

There are two forms of security notification that come out of the
OpenStack project. OpenStack Security Advisories and OpenStack Security
Notes (OSSA and OSSN respectively).

An OSSA is a significant issue in the OpenStack code base and is
typically accompanied by the relevant patch for the vulnerability in the
supported releases that are affected. OSSAs are created by the VMT
https://wiki.openstack.org/wiki/Vulnerability_Management and are
announced on the openstack-announce mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce

OSSNs are 'security notes' - created by the OpenStack Security Group to
address security issues that didn't qualify for an OSSA - perhaps
because they relate to an issue that won't be fixed etc. They are
announced on openstack-dev and here on openstack-security.

Hope this helps
-Rob

> -----Original Message-----
> From: Nigel Horne [mailto:hornenj at ncbi.nlm.nih.gov]
> Sent: 30 May 2014 13:39
> To: openstack-security at lists.openstack.org
> Subject: [Openstack-security] OSSN Advisories
> 
> I have a question about how advisories are publicised.
> 
> Is there a separate announce e-mail list, such as that at
>
http://lists.centos.org/pipermail/centos-announce/2014-May/subject.html?
> If so it would help tremendously because I could write a program to
> automate parsing and create a Jira ticket when something is announced
> (which is what I do with the CentOS list).
> 
> Thanks.
> 
> -Nigel
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
-------------- 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/20140530/cf195e5b/attachment.bin>

From fungi at yuggoth.org  Fri May 30 14:48:37 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 30 May 2014 14:48:37 -0000
Subject: [Openstack-security] [Bug 1319640] Re: Console to instance persists
 even after logging out of Horizon
References: <20140515051902.16303.85738.malonedeb@gac.canonical.com>
Message-ID: <20140530144839.3953.7778.launchpad@soybean.canonical.com>

** Information type changed from Public Security to Public

** Tags added: security

** No longer affects: ossa

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

Title:
  Console to instance persists even after logging out of Horizon

Status in OpenStack Dashboard (Horizon):
  Incomplete
Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  Steps to Recreate the bug

  1. Log in through Horizon dashboard
  2. Create an instance and wait till it is running
  3. Console the VM from drop down menu for the instance
  4. Open Console on new window.
  5. Now log out of the dashboard
  6. Scenario 1 : Now you can see that Instance console session still persists
  7. Copy the URL of console window.
  8. Close the Console window
  9. Scenario 2 : Reopen the window (In my case CTRL+SHIFT+T) on the browser - Will get access to the Instance Console.
  10. Scenario 3: Pass on the copied URL to other LAN users and ask them to use it - Will get access to the Instance Console

  I assume it must have been like,
  Session for the console must exit once the console is closed.
  Must not allow multiple sessions (Refering to Scenario 3)

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



From thierry.carrez+lp at gmail.com  Fri May 30 15:17:39 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Fri, 30 May 2014 15:17:39 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140530151739.4143.74749.malone@soybean.canonical.com>

I think this falls into "hardening" -- it's not an exploitable
vulnerability per se, and fixing this would significantly alter behavior
and therefore can't really be backported.

It sounds like very welcome hardening though, so it would really be
great if (1) we had an OSSN to cover for this and maybe (2) we improved
the default situation in future releases.

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 robert.clark at hp.com  Fri May 30 15:25:07 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Fri, 30 May 2014 15:25:07 +0000
Subject: [Openstack-security] [OSSG] Meeting Time
Message-ID: <CFAE615B.10662%robert.clark@hp.com>

Hi All,

I think we’re all agreed that we could do with some extra time to have OSSG discussions, I’m glad to say that we now have more to say than we used to! - I’d like to extend the meeting out to an hour with the obvious caveat that we’ll end when possible.

I’d like to propose that we bring the meeting forward by an hour and extend it to an hour, making the meeting 1700-1800UTC this should mean that our west coast friends don’t have to get up too early while allowing our EMEA folks to finish work too late.

Looking at the availability on https://wiki.openstack.org/wiki/Meetings<https://wiki.openstack.org/wiki/Meetings#OpenStack_Project_.26_Release_Status_meeting> this should work just fine but we’ll have to move to holding the meeting #openstack-meeting-alt

So the proposal I’m making is:
Thursdays 1800 UTC in #openstack-meeting-alt

I’m more than happy to hear other proposals if there’s a better/more suitable time for everyone.

-Rob



From 1316271 at bugs.launchpad.net  Fri May 30 15:30:12 2014
From: 1316271 at bugs.launchpad.net (Robert Clark)
Date: Fri, 30 May 2014 15:30:12 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140530153012.25886.98122.malone@wampee.canonical.com>

Hmmm. The default behaviour of a compute system should be to isolate the
host from the guests, so I think this is a vulnerability. However if the
judgement of the VMT is that this isn't a vulnerability worth releasing
an OSSA for, we'd certainly like to keep users informed by issuing an
OSSN.

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 1322766 at bugs.launchpad.net  Fri May 30 15:54:44 2014
From: 1322766 at bugs.launchpad.net (Doug Chivers)
Date: Fri, 30 May 2014 15:54:44 -0000
Subject: [Openstack-security] [Bug 1322766] Re: Cinder wipe/shred fails open
References: <20140523222522.10305.61680.malonedeb@gac.canonical.com>
Message-ID: <20140530155446.4015.84465.launchpad@soybean.canonical.com>

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

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

Title:
  Cinder wipe/shred fails open

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

Bug description:
  Previously, lvm_type=default signified a volume should be zero'd or
  wiped when deleting the volume. Zeroization could be avoided with
  lvm_type=thin. At
  https://github.com/openstack/cinder/commit/bb06ebd0f6a75a6ba55a7c022de96a91e3750d20,
  the following was added:

      volume_clear = none, zero, shred
      volume_clear_size = size_in_MiB

  Looking at the code from the commit, the default behavior of wiping
  was changed, and the change resulted in a "fail open". That is, no
  wipe occurs on configuration errors or typos:

  +        LOG.info(_("Performing secure delete on volume: %s") % volume['id'])
  +
  +        if FLAGS.volume_clear == 'zero':
  +            if size_in_m == 0:
  +                return self._copy_volume('/dev/zero', vol_path, size_in_g)
  +            else:
  +                clear_cmd = ['shred', '-n0', '-z', '-s%dMiB' % size_in_m]
  +        elif FLAGS.volume_clear == 'shred':
  +            clear_cmd = ['shred', '-n3']
  +            if size_in_m:
  +                clear_cmd.append('-s%dMiB' % size_in_m)
  +        else:
  +            LOG.error(_("Error unrecognized volume_clear option: %s"),
  +                      FLAGS.volume_clear)
  +            return

  Perhaps previous behavior should be restored:

      * default = one pass of 0's
      * a valid config changes the behavior
      * an invalid config still uses default behavior

  I think it s important to ensure cinder serves zero'ized block among
  tenants in the common case to ensure no data leaks of sensitive or
  highly sensitive data. Its going to be an important safeguard,
  especially in industries like US Financial and US Federal.

  Operators that don't handle sensitive or highly sensitive data can
  'volume_clear = none'.

  And the unexpected case of a configuration error or typo ensures the
  system fails safe. In fact, specifying 'volume_clear = 1' or
  'volume_clear = true' or 'volume_clear = yes' should trigger the
  unexpected fail open.

  From the low hanging fruit department.... Feel free to release it at
  any time. The "security vulnerability" was checked to ensure the
  security folks had an opportunity to provide feedback.

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



From robert.clark at hp.com  Fri May 30 16:11:46 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Fri, 30 May 2014 16:11:46 +0000
Subject: [Openstack-security] Fixing errors in issued OSSNs
Message-ID: <CFAE6C51.106B8%robert.clark@hp.com>

Mark Washenberger has pointed out a mistake in OSSN-0013, we should fire whoever wrote that!
https://bugs.launchpad.net/ossn/+bug/1271426

Anyway, we have a few options.
Cut a completely new OSSN that supersedes 0013 and give it a normal number and add a reference to the no longer valid 0013
Cut a new OSSN with a number derived from 0013 such as OSSN-0013-1

Followed up with what would basically be a revised announcement on –dev and –security.

Thoughts?




From kseifried at redhat.com  Fri May 30 16:22:49 2014
From: kseifried at redhat.com (Kurt Seifried)
Date: Fri, 30 May 2014 10:22:49 -0600
Subject: [Openstack-security] Security Anti-Patterns
In-Reply-To: <53884091.2040201@openstack.org>
References: <EE6FFF4F6C34C84C8C98DD2414EEA47E724216D8@fmsmsx117.amr.corp.intel.com>
 <5386BE14.10907@redhat.com> <CFAC95C7.F8BC%robert.clark@hp.com>
 <53876AC4.3030002@redhat.com> <53884091.2040201@openstack.org>
Message-ID: <5388B059.7040901@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/30/2014 02:25 AM, Thierry Carrez wrote:
> Kurt Seifried wrote:
>> On 05/29/2014 12:47 AM, Clark, Robert Graham wrote:
>>> I certainly share your frustration, I think the idea with the 
>>> anti-patterns is to document the things that get done badly
>>> most often in OpenStack and format them in a way that¹s easily 
>>> consumable by core devs and PTLs. The list should be short
>>> enough that they can refer back to it while reviewing new
>>> features.
>> 
>>> It¹s not going to fix anything on it¹s own but anything we can
>>> do to help developers not make the same mistakes which, as you
>>> point out, have been made for the last 20 years - is a good
>>> thing.
>> 
>>> -Rob
>> 
>> So a concrete example, I wrote this in 2012? Nothing new, all
>> this goes back a few decades:
>> 
>> https://kurt.seifried.org/2012/03/14/creating-temporary-files-securely/
>>
>>
>> 
Then I checkout all the source code:
>> [...]
> 
> Yes, it's frustrating. We run those greps from time to time, fix
> stuff, but then some new are added, or some new component appears
> with its own share.
> 
> Ideally we would write a hacking-style test that we would gate
> against (to prevent reintroduction) and run those greps at
> incubation time (to prevent new components from inserting them).
> 
> The problem is, to make it part of gating we'd have to come with
> an automated detection that would be right most of the time (and
> that you can actively disable in remaining cases). However we
> receive a lot of automated reports at the VMT lately, and more than
> half of them are actually shallow and do not represent a real
> vulnerability -- automated detection is hard.
> 
> So this is not a simple problem.

If automated code analysis worked as well as people wanted ... yeah,
we'd have fixed a lot more bugs by now =).

One strategy to deal with the false positives is to simply add source
code comments before the offending line, e.g. with brakeman reports it
shows a few lines before/after the offending code, rather than build a
separate system to track false positives just fold that information
back into the code ("the following line triggers X, but don't worry
because Y"), the challenge of course is to keep these exceptions up to
date and correct in case the code changes in a way that does turn the
false positive into a real issue.

You can try to get code at check-in time but there may not be enough
context, another strategy is to integrate code checks (e.g. for Ruby
tying the brakeman scanner into Jenkins) at build time, and have a
strong feedback loop to ensure this stuff actually gets looked at and
fixed if needed (non trivial).

- -- 
Kurt Seifried - Red Hat - Product Security - Cloud stuff and such
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJTiLBYAAoJEBYNRVNeJnmTNw8P/3NLTX6GavN5M4Kjub/1/qpL
n76+s0ycz/BVlKaisuEB2qDf3GWB29/PkdKwSo2WTyrWuo9LWh8QT9bjjS01qBmY
q8UwbOKsgdEs/zwpU+yWRr02oQm2GSTKi3QgvJAdcvgo7bkwXLQVsdoxASGgDbwI
3TsxuU6QOYmdEB9BVP8/RDLEjHdUM/32KlZdy6c8yCLl1Zbjf65ILfMuj0iNmmdq
TvUGGfO4GySLEvApzeuq5YOPR19JUKaAmcYfN/Fcixd3BEE/4Tl/7cYLoFkfTAnE
6hb3PSCPGSHVA8Z+M0R6NigZ9LSpeEw4lSqzu4ZipzbemMmTgwJEYCIj8LrSRW/H
L5AdrkUQbXrHnCfL3BCKnDOrY8VaEpy0xRjX6KWyxTchztNUFyZyjxN62TabveK2
0x6htFKat3d2jw0vMrFLaNLV2g3tzA6Rg93du2RcJPgfBJEzrua1nZTKnC1mX3gW
qgakG64NoDxHE23JqSmCoQzXWE/0C6hy2PjHaMSjR1sk8kKchZuO1qml2AeGKEzQ
iP5q/8972ny+SNF8/NGxXft1Vt1gW/JR1atwak+O9HRP0CorHH7WbaWwqnoe57Uj
a+0JZZ/spJtHTHh1acI/pBRbEtI4F1vwpreuNcMbRvjQXa/C/lNLf0flkxGzWwAY
VBiGFlXzzNXvuMmyVAd2
=ox8g
-----END PGP SIGNATURE-----



From bdpayne at acm.org  Fri May 30 16:32:18 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Fri, 30 May 2014 09:32:18 -0700
Subject: [Openstack-security] [OSSG] Meeting Time
In-Reply-To: <CFAE615B.10662%robert.clark@hp.com>
References: <CFAE615B.10662%robert.clark@hp.com>
Message-ID: <CAFpPvXDVqLn8wjTUyqdyD8TjWJ2t07NCyRa1BbzVbxwxYtVm8A@mail.gmail.com>

I'm guessing you really mean:
Thursdays at 1700 - 1800 UTC in #openstack-meeting-alt ?

Personally... This isn't ideal for me, as I have a daily meeting from 1730
- 1800.  Having said that, I can make this work, if needed.

-bryan


On Fri, May 30, 2014 at 8:25 AM, Clark, Robert Graham <robert.clark at hp.com>
wrote:

> Hi All,
>
> I think we’re all agreed that we could do with some extra time to have
> OSSG discussions, I’m glad to say that we now have more to say than we used
> to! - I’d like to extend the meeting out to an hour with the obvious caveat
> that we’ll end when possible.
>
> I’d like to propose that we bring the meeting forward by an hour and
> extend it to an hour, making the meeting 1700-1800UTC this should mean that
> our west coast friends don’t have to get up too early while allowing our
> EMEA folks to finish work too late.
>
> Looking at the availability on https://wiki.openstack.org/wiki/Meetings<
> https://wiki.openstack.org/wiki/Meetings#OpenStack_Project_.26_Release_Status_meeting>
> this should work just fine but we’ll have to move to holding the meeting
> #openstack-meeting-alt
>
> So the proposal I’m making is:
> Thursdays 1800 UTC in #openstack-meeting-alt
>
> I’m more than happy to hear other proposals if there’s a better/more
> suitable time for everyone.
>
> -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/20140530/06380d27/attachment.html>

From bdpayne at acm.org  Fri May 30 16:36:35 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Fri, 30 May 2014 09:36:35 -0700
Subject: [Openstack-security] Fixing errors in issued OSSNs
In-Reply-To: <CFAE6C51.106B8%robert.clark@hp.com>
References: <CFAE6C51.106B8%robert.clark@hp.com>
Message-ID: <CAFpPvXD9FR_UnangqJkcp8J0EZoy1DCc42fSRCBfRkNQ54ObdQ@mail.gmail.com>

I vote for cutting OSSN-0013-1 and then, to the extent possible, ensuring
that this new one replaces the old one in all of our publication locations.

-bryan


On Fri, May 30, 2014 at 9:11 AM, Clark, Robert Graham <robert.clark at hp.com>
wrote:

> Mark Washenberger has pointed out a mistake in OSSN-0013, we should fire
> whoever wrote that!
> https://bugs.launchpad.net/ossn/+bug/1271426
>
> Anyway, we have a few options.
> Cut a completely new OSSN that supersedes 0013 and give it a normal number
> and add a reference to the no longer valid 0013
> Cut a new OSSN with a number derived from 0013 such as OSSN-0013-1
>
> Followed up with what would basically be a revised announcement on –dev
> and –security.
>
> Thoughts?
>
>
> _______________________________________________
> 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/20140530/3a9cd639/attachment.html>

From robert.clark at hp.com  Fri May 30 16:35:53 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Fri, 30 May 2014 16:35:53 +0000
Subject: [Openstack-security] [OSSG] Meeting Time
In-Reply-To: <CAFpPvXDVqLn8wjTUyqdyD8TjWJ2t07NCyRa1BbzVbxwxYtVm8A@mail.gmail.com>
References: <CFAE615B.10662%robert.clark@hp.com>
 <CAFpPvXDVqLn8wjTUyqdyD8TjWJ2t07NCyRa1BbzVbxwxYtVm8A@mail.gmail.com>
Message-ID: <CFAE71CA.106C0%robert.clark@hp.com>

Sorry, long week.

Yes the proposal is 1700-1800 UTC in #openstack-meeting-alt.


From: Bryan Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>>
Date: Friday, 30 May 2014 17:32
To: Robert Clark <robert.clark at hp.com<mailto:robert.clark at hp.com>>
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] Meeting Time

I'm guessing you really mean:
Thursdays at 1700 - 1800 UTC in #openstack-meeting-alt ?

Personally... This isn't ideal for me, as I have a daily meeting from 1730 - 1800.  Having said that, I can make this work, if needed.

-bryan


On Fri, May 30, 2014 at 8:25 AM, Clark, Robert Graham <robert.clark at hp.com<mailto:robert.clark at hp.com>> wrote:
Hi All,

I think we’re all agreed that we could do with some extra time to have OSSG discussions, I’m glad to say that we now have more to say than we used to! - I’d like to extend the meeting out to an hour with the obvious caveat that we’ll end when possible.

I’d like to propose that we bring the meeting forward by an hour and extend it to an hour, making the meeting 1700-1800UTC this should mean that our west coast friends don’t have to get up too early while allowing our EMEA folks to finish work too late.

Looking at the availability on https://wiki.openstack.org/wiki/Meetings<https://wiki.openstack.org/wiki/Meetings#OpenStack_Project_.26_Release_Status_meeting> this should work just fine but we’ll have to move to holding the meeting #openstack-meeting-alt

So the proposal I’m making is:
Thursdays 1800 UTC in #openstack-meeting-alt

I’m more than happy to hear other proposals if there’s a better/more suitable time for everyone.

-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




From bdpayne at acm.org  Fri May 30 16:34:26 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Fri, 30 May 2014 16:34:26 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140530163426.20301.48411.malone@chaenomeles.canonical.com>

It seems to me that people should be deploying nodes such that this
interface isn't used for anything other than the instance's dhcp
service.  I suspect that many people are already doing this, but perhaps
it isn't obvious that it is a necessary step for security reasons?

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 1316271 at bugs.launchpad.net  Fri May 30 16:43:37 2014
From: 1316271 at bugs.launchpad.net (Robert Clark)
Date: Fri, 30 May 2014 16:43:37 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140530164338.4583.51171.malone@soybean.canonical.com>

That would certainly put it square in OSSN territory.

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 brian.schott at nimbisservices.com  Fri May 30 17:14:29 2014
From: brian.schott at nimbisservices.com (Brian Schott)
Date: Fri, 30 May 2014 10:14:29 -0700 (PDT)
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM
 hosts can SSH to compute node
In-Reply-To: <20140530163426.20301.48411.malone@chaenomeles.canonical.com>
References: <20140530163426.20301.48411.malone@chaenomeles.canonical.com>
Message-ID: <1401470069088.07a1ccdf@Nodemailer>

Are there any downsides to enforcing that the interface can only be used for the dhcp service?—
Sent from Mailbox

On Fri, May 30, 2014 at 12:42 PM, Bryan D. Payne <bdpayne at acm.org> wrote:

> It seems to me that people should be deploying nodes such that this
> interface isn't used for anything other than the instance's dhcp
> service.  I suspect that many people are already doing this, but perhaps
> it isn't obvious that it is a necessary step for security reasons?
> -- 
> 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):
>   New
> Status in OpenStack Security Advisories:
>   Incomplete
> 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
> _______________________________________________
> 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/20140530/5ecc0238/attachment.html>

From nkinder at redhat.com  Fri May 30 17:15:03 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Fri, 30 May 2014 10:15:03 -0700
Subject: [Openstack-security] Fixing errors in issued OSSNs
In-Reply-To: <CAFpPvXD9FR_UnangqJkcp8J0EZoy1DCc42fSRCBfRkNQ54ObdQ@mail.gmail.com>
References: <CFAE6C51.106B8%robert.clark@hp.com>
 <CAFpPvXD9FR_UnangqJkcp8J0EZoy1DCc42fSRCBfRkNQ54ObdQ@mail.gmail.com>
Message-ID: <5388BC97.5040202@redhat.com>



On 05/30/2014 09:36 AM, Bryan D. Payne wrote:
> I vote for cutting OSSN-0013-1 and then, to the extent possible,
> ensuring that this new one replaces the old one in all of our
> publication locations.

+1.  This should replace the original published version everywhere.  The
only thing we can't do is to strike is the history from the mailing list
archive, but we can publish the new revision to the mailing lists.

To prevent this situation in the future, we need to test any workarounds
that we publish in an OSSN.  I added a brief section about testing to
the Process page after learning about the problems with OSSN-0013 yesterday:

  https://wiki.openstack.org/wiki/Security/Security_Note_Process#Testing

Anyone reviewing a pending OSSN should not hesitate to ask if a
workaround has actually been tested by the author.

I'm working on testing a new workaround for OSSN-0013.

Thanks,
-NGK

> 
> -bryan
> 
> 
> On Fri, May 30, 2014 at 9:11 AM, Clark, Robert Graham
> <robert.clark at hp.com <mailto:robert.clark at hp.com>> wrote:
> 
>     Mark Washenberger has pointed out a mistake in OSSN-0013, we should
>     fire whoever wrote that!
>     https://bugs.launchpad.net/ossn/+bug/1271426
> 
>     Anyway, we have a few options.
>     Cut a completely new OSSN that supersedes 0013 and give it a normal
>     number and add a reference to the no longer valid 0013
>     Cut a new OSSN with a number derived from 0013 such as OSSN-0013-1
> 
>     Followed up with what would basically be a revised announcement on
>     –dev and –security.
> 
>     Thoughts?
> 
> 
>     _______________________________________________
>     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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 



From 1322766 at bugs.launchpad.net  Fri May 30 17:13:18 2014
From: 1322766 at bugs.launchpad.net (Doug Chivers)
Date: Fri, 30 May 2014 17:13:18 -0000
Subject: [Openstack-security] [Bug 1322766] Re: Cinder wipe/shred fails open
References: <20140523222522.10305.61680.malonedeb@gac.canonical.com>
Message-ID: <20140530171319.27534.92475.launchpad@gac.canonical.com>

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

** 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 the bug report.
https://bugs.launchpad.net/bugs/1322766

Title:
  Cinder wipe/shred fails open

Status in Cinder:
  New
Status in OpenStack Security Notes:
  In Progress

Bug description:
  Previously, lvm_type=default signified a volume should be zero'd or
  wiped when deleting the volume. Zeroization could be avoided with
  lvm_type=thin. At
  https://github.com/openstack/cinder/commit/bb06ebd0f6a75a6ba55a7c022de96a91e3750d20,
  the following was added:

      volume_clear = none, zero, shred
      volume_clear_size = size_in_MiB

  Looking at the code from the commit, the default behavior of wiping
  was changed, and the change resulted in a "fail open". That is, no
  wipe occurs on configuration errors or typos:

  +        LOG.info(_("Performing secure delete on volume: %s") % volume['id'])
  +
  +        if FLAGS.volume_clear == 'zero':
  +            if size_in_m == 0:
  +                return self._copy_volume('/dev/zero', vol_path, size_in_g)
  +            else:
  +                clear_cmd = ['shred', '-n0', '-z', '-s%dMiB' % size_in_m]
  +        elif FLAGS.volume_clear == 'shred':
  +            clear_cmd = ['shred', '-n3']
  +            if size_in_m:
  +                clear_cmd.append('-s%dMiB' % size_in_m)
  +        else:
  +            LOG.error(_("Error unrecognized volume_clear option: %s"),
  +                      FLAGS.volume_clear)
  +            return

  Perhaps previous behavior should be restored:

      * default = one pass of 0's
      * a valid config changes the behavior
      * an invalid config still uses default behavior

  I think it s important to ensure cinder serves zero'ized block among
  tenants in the common case to ensure no data leaks of sensitive or
  highly sensitive data. Its going to be an important safeguard,
  especially in industries like US Financial and US Federal.

  Operators that don't handle sensitive or highly sensitive data can
  'volume_clear = none'.

  And the unexpected case of a configuration error or typo ensures the
  system fails safe. In fact, specifying 'volume_clear = 1' or
  'volume_clear = true' or 'volume_clear = yes' should trigger the
  unexpected fail open.

  From the low hanging fruit department.... Feel free to release it at
  any time. The "security vulnerability" was checked to ensure the
  security folks had an opportunity to provide feedback.

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



From 1316271 at bugs.launchpad.net  Fri May 30 17:14:29 2014
From: 1316271 at bugs.launchpad.net (Brian Schott)
Date: Fri, 30 May 2014 17:14:29 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM
 hosts can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
 <20140530163426.20301.48411.malone@chaenomeles.canonical.com>
Message-ID: <1401470069088.07a1ccdf@Nodemailer>

Are there any downsides to enforcing that the interface can only be used for the dhcp service?—
Sent from Mailbox

On Fri, May 30, 2014 at 12:42 PM, Bryan D. Payne <bdpayne at acm.org>
wrote:

> It seems to me that people should be deploying nodes such that this
> interface isn't used for anything other than the instance's dhcp
> service.  I suspect that many people are already doing this, but perhaps
> it isn't obvious that it is a necessary step for security reasons?
> -- 
> 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):
>   New
> Status in OpenStack Security Advisories:
>   Incomplete
> 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
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-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/1316271

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

Status in OpenStack Compute (Nova):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 robert.clark at hp.com  Fri May 30 17:28:13 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Fri, 30 May 2014 17:28:13 +0000
Subject: [Openstack-security] Fixing errors in issued OSSNs
In-Reply-To: <5388BC97.5040202@redhat.com>
References: <CFAE6C51.106B8%robert.clark@hp.com>
 <CAFpPvXD9FR_UnangqJkcp8J0EZoy1DCc42fSRCBfRkNQ54ObdQ@mail.gmail.com>
 <5388BC97.5040202@redhat.com>
Message-ID: <CFAE7D2D.10724%robert.clark@hp.com>

On 30/05/2014 18:15, "Nathan Kinder" <nkinder at redhat.com> wrote:


>
>
>On 05/30/2014 09:36 AM, Bryan D. Payne wrote:
>> I vote for cutting OSSN-0013-1 and then, to the extent possible,
>> ensuring that this new one replaces the old one in all of our
>> publication locations.
>
>+1.  This should replace the original published version everywhere.  The
>only thing we can't do is to strike is the history from the mailing list
>archive, but we can publish the new revision to the mailing lists.
>
>To prevent this situation in the future, we need to test any workarounds
>that we publish in an OSSN.  I added a brief section about testing to
>the Process page after learning about the problems with OSSN-0013
>yesterday:
>
>  https://wiki.openstack.org/wiki/Security/Security_Note_Process#Testing
>
>Anyone reviewing a pending OSSN should not hesitate to ask if a
>workaround has actually been tested by the author.
>
>I'm working on testing a new workaround for OSSN-0013.
>
>Thanks,
>-NGK
>
>> 
>> -bryan
>> 
>> 
>> On Fri, May 30, 2014 at 9:11 AM, Clark, Robert Graham
>> <robert.clark at hp.com <mailto:robert.clark at hp.com>> wrote:
>> 
>>     Mark Washenberger has pointed out a mistake in OSSN-0013, we should
>>     fire whoever wrote that!
>>     https://bugs.launchpad.net/ossn/+bug/1271426
>> 
>>     Anyway, we have a few options.
>>     Cut a completely new OSSN that supersedes 0013 and give it a normal
>>     number and add a reference to the no longer valid 0013
>>     Cut a new OSSN with a number derived from 0013 such as OSSN-0013-1
>> 
>>     Followed up with what would basically be a revised announcement on
>>     ­dev and ­security.
>> 
>>     Thoughts?
>> 
>> 
>>     _______________________________________________
>>     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
>> 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

I agree, we need testing to improve the quality of the OSSNs we produce.
However, we probably need guidance on how to do that properly. Many
authors of OSSNs won¹t be used to standing up devstack etc. We¹ve
previously held up OSSNs as a nice way to contribute to OpenStack
security, particularly for those starting up. We now require authors to
understand gerrit and the proposal is to spin up an OpenStack deployment
to perform testing too - I wonder if this will all be a bit too much for
your average author?

I suppose we could create a few reference deployments and
Grizzly,Havana,Icehouse and just try changes on the reference deployments?
After all we are typically only talking about configuration changes rather
than code changes, the reference deployments should stay relatively
stable. Once consideration would be to have someone other than the author
perform the test - thoughts?

-Rob




From 1316271 at bugs.launchpad.net  Fri May 30 17:32:22 2014
From: 1316271 at bugs.launchpad.net (David Hill)
Date: Fri, 30 May 2014 17:32:22 -0000
Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts
	can SSH to compute node
References: <20140505190222.27207.36590.malonedeb@gac.canonical.com>
Message-ID: <20140530173222.20766.24979.malone@chaenomeles.canonical.com>

We're enforcing it at the IPtables level and everything seems to be
working but we also implemented iptables rules for isolating further the
compute nodes in the network.

-- 
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):
  New
Status in OpenStack Security Advisories:
  Incomplete

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 nkinder at redhat.com  Fri May 30 17:44:35 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Fri, 30 May 2014 10:44:35 -0700
Subject: [Openstack-security] Fixing errors in issued OSSNs
In-Reply-To: <CFAE7D2D.10724%robert.clark@hp.com>
References: <CFAE6C51.106B8%robert.clark@hp.com>
 <CAFpPvXD9FR_UnangqJkcp8J0EZoy1DCc42fSRCBfRkNQ54ObdQ@mail.gmail.com>
 <5388BC97.5040202@redhat.com> <CFAE7D2D.10724%robert.clark@hp.com>
Message-ID: <5388C383.4060706@redhat.com>



On 05/30/2014 10:28 AM, Clark, Robert Graham wrote:
> On 30/05/2014 18:15, "Nathan Kinder" <nkinder at redhat.com> wrote:
> 
> 
>>
>>
>> On 05/30/2014 09:36 AM, Bryan D. Payne wrote:
>>> I vote for cutting OSSN-0013-1 and then, to the extent possible,
>>> ensuring that this new one replaces the old one in all of our
>>> publication locations.
>>
>> +1.  This should replace the original published version everywhere.  The
>> only thing we can't do is to strike is the history from the mailing list
>> archive, but we can publish the new revision to the mailing lists.
>>
>> To prevent this situation in the future, we need to test any workarounds
>> that we publish in an OSSN.  I added a brief section about testing to
>> the Process page after learning about the problems with OSSN-0013
>> yesterday:
>>
>>  https://wiki.openstack.org/wiki/Security/Security_Note_Process#Testing
>>
>> Anyone reviewing a pending OSSN should not hesitate to ask if a
>> workaround has actually been tested by the author.
>>
>> I'm working on testing a new workaround for OSSN-0013.
>>
>> Thanks,
>> -NGK
>>
>>>
>>> -bryan
>>>
>>>
>>> On Fri, May 30, 2014 at 9:11 AM, Clark, Robert Graham
>>> <robert.clark at hp.com <mailto:robert.clark at hp.com>> wrote:
>>>
>>>     Mark Washenberger has pointed out a mistake in OSSN-0013, we should
>>>     fire whoever wrote that!
>>>     https://bugs.launchpad.net/ossn/+bug/1271426
>>>
>>>     Anyway, we have a few options.
>>>     Cut a completely new OSSN that supersedes 0013 and give it a normal
>>>     number and add a reference to the no longer valid 0013
>>>     Cut a new OSSN with a number derived from 0013 such as OSSN-0013-1
>>>
>>>     Followed up with what would basically be a revised announcement on
>>>     ­dev and ­security.
>>>
>>>     Thoughts?
>>>
>>>
>>>     _______________________________________________
>>>     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
>>> 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
> 
> I agree, we need testing to improve the quality of the OSSNs we produce.
> However, we probably need guidance on how to do that properly. Many
> authors of OSSNs won¹t be used to standing up devstack etc. We¹ve
> previously held up OSSNs as a nice way to contribute to OpenStack
> security, particularly for those starting up. We now require authors to
> understand gerrit and the proposal is to spin up an OpenStack deployment
> to perform testing too - I wonder if this will all be a bit too much for
> your average author?

These are all very good points.  Some OSSNs are easy and require no
testing (there may be no workaround to document).  We've had a few of
these in the past 6 months that I can recall.  Other OSSNs simply
require more hands-on work.

> 
> I suppose we could create a few reference deployments and
> Grizzly,Havana,Icehouse and just try changes on the reference deployments?
> After all we are typically only talking about configuration changes rather
> than code changes, the reference deployments should stay relatively
> stable.

Where would these be hosted?

> Once consideration would be to have someone other than the author
> perform the test - thoughts?

Working with the developers from the original bug is one good route.
Given the size of the security group, there is likely a broad skill-set
including good writers, security researchers, and hands-on operators and
developers.  OSSG members can work together to produce a high-quality
validated OSSN.  I'm willing to bet that we have some members who would
be interested in testing that aren't necessarily interested in writing.

-NGK

> 
> -Rob
> 



From gerrit2 at review.openstack.org  Fri May 30 18:09:09 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 30 May 2014 18:09:09 +0000
Subject: [Openstack-security] [openstack/ironic] SecurityImpact review
 request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e
Message-ID: <E1WqREr-0007zU-W4@review.openstack.org>


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

Log:
commit 9f919de4f6776fbcc93fdc9d3ff5bb1fe6b24e85
Author: Josh Gachnang <josh at pcsforeducation.com>
Date:   Wed Mar 19 16:47:38 2014 -0700

    Adding swift temp url support
    
    This patch will allow properly configured Glance servers to return a temporary
    URL for an object hosted on Swift. It will require Glance to use Swift
    as its backend. A temporary URL will let the agent download an image from
    Glance without requiring an auth_token, which gives access more than just
    Glance. The easiest way to use it is to enable direct_url in Glance, but
    you can set the appropriate config options to avoid needing to enable it.
    
    We/I need to add a note in the docs about Swift being a possible dependency
    for Ironic deploys using IPA, along with how to set the Temp URL key.
    
    Swift perfomance concerns will be addressed in this blueprint:
    https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads
    
    SecurityImpact
    DocImpact
    
    Implements: blueprint swift-temp-urls
    Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e




From tristan.cacqueray at enovance.com  Fri May 30 20:42:22 2014
From: tristan.cacqueray at enovance.com (Tristan Cacqueray)
Date: Fri, 30 May 2014 20:42:22 -0000
Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in
	meter http.request
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140530204224.3922.11935.launchpad@soybean.canonical.com>

** Changed in: ossa
     Assignee: (unassigned) => Tristan Cacqueray (tristan-cacqueray)

-- 
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:
  auth token is exposed in meter http.request

Status in OpenStack Telemetry (Ceilometer):
  New
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in Oslo - a Library of Common OpenStack Code:
  Fix Committed
Status in OpenStack Security Advisories:
  Confirmed
Status in pyCADF:
  Fix Committed

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 tristan.cacqueray at enovance.com  Fri May 30 20:55:28 2014
From: tristan.cacqueray at enovance.com (Tristan Cacqueray)
Date: Fri, 30 May 2014 20:55:28 -0000
Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in
	meter http.request
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140530205528.26528.44553.malone@wampee.canonical.com>

It seems that this was introduced in Icehouse, thus we are still missing those patches:
* Ceilometer master and stable/icehouse
* Neutron stable/icehouse

Gordon, could you please propose Ceilometer fixes as well ?

-- 
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:
  auth token is exposed in meter http.request

Status in OpenStack Telemetry (Ceilometer):
  New
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in Oslo - a Library of Common OpenStack Code:
  Fix Committed
Status in OpenStack Security Advisories:
  Confirmed
Status in pyCADF:
  Fix Committed

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 1321080 at bugs.launchpad.net  Fri May 30 21:09:05 2014
From: 1321080 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 30 May 2014 21:09:05 -0000
Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in
	meter http.request
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140530210905.4213.14929.malone@soybean.canonical.com>

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

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

** Changed in: ceilometer
     Assignee: (unassigned) => gordon chung (chungg)

-- 
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:
  auth token is exposed in meter http.request

Status in OpenStack Telemetry (Ceilometer):
  In Progress
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in Oslo - a Library of Common OpenStack Code:
  Fix Committed
Status in OpenStack Security Advisories:
  Confirmed
Status in pyCADF:
  Fix Committed

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 1321080 at bugs.launchpad.net  Fri May 30 21:11:37 2014
From: 1321080 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 30 May 2014 21:11:37 -0000
Subject: [Openstack-security] [Bug 1321080] Fix proposed to ceilometer
	(stable/icehouse)
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140530211137.20799.89254.malone@chaenomeles.canonical.com>

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

-- 
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:
  auth token is exposed in meter http.request

Status in OpenStack Telemetry (Ceilometer):
  In Progress
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in Oslo - a Library of Common OpenStack Code:
  Fix Committed
Status in OpenStack Security Advisories:
  Confirmed
Status in pyCADF:
  Fix Committed

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 nkinder at redhat.com  Sat May 31 15:39:21 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Sat, 31 May 2014 15:39:21 -0000
Subject: [Openstack-security] [Bug 1260679] Re: Multiple drivers set
	insecure file permissions
References: <20131213105542.17101.92136.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140531153922.20634.22748.malone@chaenomeles.canonical.com>

Published as OSSN-0014 on the wiki and the openstack and openstack-dev
mailing lists:

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

** 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/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 gord at live.ca  Fri May 30 21:16:59 2014
From: gord at live.ca (gordon chung)
Date: Fri, 30 May 2014 21:16:59 -0000
Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in
	meter http.request
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140530211659.26461.19934.malone@wampee.canonical.com>

@Tristan, thanks for letting me know. i completely forgot we had
middleware module in Ceilometer.

-- 
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:
  auth token is exposed in meter http.request

Status in OpenStack Telemetry (Ceilometer):
  In Progress
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in Oslo - a Library of Common OpenStack Code:
  Fix Committed
Status in OpenStack Security Advisories:
  Confirmed
Status in pyCADF:
  Fix Committed

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 1320098 at bugs.launchpad.net  Sat May 31 03:42:22 2014
From: 1320098 at bugs.launchpad.net (OpenStack Infra)
Date: Sat, 31 May 2014 03:42:22 -0000
Subject: [Openstack-security] [Bug 1320098] Re: neutronclient debug logging
 includes keystone auth token
References: <20140516064420.2758.66631.malonedeb@wampee.canonical.com>
Message-ID: <20140531034223.27433.78233.launchpad@gac.canonical.com>

** Changed in: python-neutronclient
     Assignee: Xu Han Peng (xuhanp) => Feng Ju (jufeng)

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

Title:
  neutronclient debug logging includes keystone auth token

Status in Python client library for Neutron:
  In Progress

Bug description:
  neutronclient is logging the auth token in the nova logs. Since the
  logs are world-readable, this means anyone user on this system can see
  the auth token, which they can then use to get OpenStack administrator
  access.

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