[openstack-dev] [OSSN 0063] Nova and Cinder key manager for Barbican misuses cached credentials

[Nathan Kinder]

Nova and Cinder key manager for Barbican misuses cached credentials
---

### Summary ###
During the Icehouse release the Cinder and Nova projects added a feature
that supports storage volume encryption using keys stored in Barbican.
The Barbican key manager, that is part of Nova and Cinder, had a bug
that could cause an authorized user to lose access to an encryption key
or allow the wrong user to gain access to an encryption key.

### Affected Services / Software ###
Cinder: Icehouse, Juno, Kilo, Liberty
Nova: Juno, Kilo, Liberty

### Discussion ###
The Barbican key manager is a feature that is part of Nova and Cinder to
allow those projects to create and retrieve keys in Barbican. The key
manager includes a cache function that allows for a copy_key() operation
to work while only validating the token once with Keystone.

This cache function had a bug such that the cached token was used for
operations where it was no longer valid. The symptoms of this error
vary, but include a user not being able to access their key or the wrong
user being able to access a key.

An affected user would see an error similar to this in their cinder log:

 begin cinder.log sample snippet 
2015-12-03 09:09:03.648 TRACE cinder.volume.api Unauthorized: The
request you have made requires authentication. (Disable debug mode to
suppress these details.) (HTTP 401) (Request-ID:
req-d2c52e0b-c16d-43ec-a7a0-763f1270)
 end cinder.log sample snippet 

### Recommended Actions ###
Users wishing to use the Barbican key manager to provided keys for
volume encryption with Nova and Cinder should ensure they are using a
patched version.

A specification for a fix has been merged for the Mitaka release of both
Nova and Cinder. Additionally these patches have been backported to
stable/kilo and stable/liberty.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0063
Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1523646
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
Nova patch for Mitaka : https://review.openstack.org/254358/
Nova patch for stable/liberty: https://review.openstack.org/288490
Cinder patch for Mitaka : https://review.openstack.org/254357/
Cinder patch for stable/liberty: https://review.openstack.org/266678
Cinder patch for stable/kilo: https://review.openstack.org/266680
CVE : N/A



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-security] [Security]abandoned OSSNs?

[Nathan Kinder]

On 04/11/2016 08:04 AM, Clark, Robert Graham wrote:
> Thanks Matt, Michael,
> 
>  
> 
> To start with, lets look quickly at the more recent OSSNs that are
> marked as work in progress, namely 63,64,65 and 66 – these should all be
> published within a week or so.
> 
>  
> 
> Looking further back we have the more difficult OSSNs 50 and 51, I’m not
> 100% sure what the blockers are on these.  I believe
> https://wiki.openstack.org/wiki/OSSN/OSSN-0056 may supersede OSSN-0051
> and is rooted in bug https://bugs.launchpad.net/ossn/+bug/1435530 - it
> looks to me like OSSN-0056 was written during a mid-cycle and could be
> the right one.
> 
>  
> 
> I’m struggling to work out the story behind OSSN-0050 – I’m adding
> Nathan Kinder who might be able to shed more light on this.

It looks like that one was added to the wiki by 'Davewalker' in this
revision:


https://wiki.openstack.org/w/index.php?title=Security_Notes&direction=next&oldid=85312

I searched all open and closed OSSN bugs, and did not see one that
matches this issue.

-NGK

> 
>  
> 
> -Rob
> 
>  
> 
>  
> 
>  
> 
> *From:*Michael Xin [mailto:michael@rackspace.com]
> *Sent:* 11 April 2016 15:28
> *To:* Matt Fischer; OpenStack Development Mailing List (not for usage
> questions)
> *Subject:* Re: [openstack-dev] [Openstack-security] [Security]abandoned
> OSSNs?
> 
>  
> 
> Matt:
> 
> Thanks for asking this. I forwarded this email to the new email list so
> that folks with better knowledge can answer this. 
> 
>  
> 
>  
> 
> Thanks and have a great day. 
> 
>  
> 
> Yours,
> 
> Michael 
> 
>  
> 
>  
> 
> -
> 
> Michael Xin | Manager, Security Engineering - US 
> 
> Product Security  |Rackspace Hosting
> 
> Office #: 501-7341   or  210-312-7341
> 
> Mobile #: 210-284-8674 
> 
> 5000 Walzem Road, San Antonio, Tx 78218
> 
> 
> 
> Experience fanatical support
> 
>  
> 
> *From: *Matt Fischer mailto:m...@mattfischer.com>>
> *Date: *Monday, April 11, 2016 at 9:19 AM
> *To: *"openstack-secur...@lists.openstack.org
> <mailto:openstack-secur...@lists.openstack.org>"
>  <mailto:openstack-secur...@lists.openstack.org>>
> *Subject: *[Openstack-security] abandoned OSSNs?
> 
>  
> 
> Some folks from our security team here asked me to ensure them that our
> services were patched for all the OSSNs that are listed
> here: https://wiki.openstack.org/wiki/Security_Notes
> 
>  
> 
> Most of these are straight-forward, but there are some OSSNs that have
> been allocated an ID but then abandoned. There is no detailed wiki page
> and my best google efforts lead me to a possible IRC mention and maybe
> an abandoned review. The two specifically are OSSN-50/51.
> 
>  
> 
> So what am I to do with an "abandoned" OSSN? Has it been decided that
> there is no issue anymore? These are pretty old if I look at the dates
> framing the other OSSNs (49/52), so I assume they aren't urgent. Can we
> ignore these? They sound somewhat scary, for example,
> "keystonemiddleware can allow access after token revocation" but I have
> no means to say whether it affects us or how we can mitigate without
> more info.
> 
>  
> 
> Thoughts?
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0062] Potential reuse of revoked Identity tokens

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Potential reuse of revoked Identity tokens
- ---

### Summary ###
An authorization token issued by the Identity service can be revoked,
which is designed to immediately make that token invalid for future use.
When the PKI or PKIZ token providers are used, it is possible for an
attacker to manipulate the token contents of a revoked token such that
the token will still be considered to be valid.  This can allow
unauthorized access to cloud resources if a revoked token is intercepted
by an attacker.

### Affected Services / Software ###
Keystone, Icehouse, Juno, Kilo, Liberty

### Discussion ###
Token revocation is used in OpenStack to invalidate a token for further
use.  This token revocation takes place automatically in certain
situations, such as when a user logs out of the Dashboard.  If a revoked
token is obtained by another party, it should no longer be possible to
use it to perform any actions within the cloud.  Unfortunately, this is
not the case when the PKI or PKIZ token providers are used.

When a PKI or PKIZ token is validated, the Identity service checks it
by searching for a revocation by the entire token.  It is possible for
an attacker to manipulate portions of an intercepted PKI or PKIZ token
that are not cryptographically protected, which will cause the
revocation check to improperly consider the token to be valid.

### Recommended Actions ###
We recommend that you do not use the PKI or PKIZ token providers.  The
PKI and PKIZ token providers do not offer any significant benefit over
other token providers such as the UUID or Fernet.

If you are using the PKI or PKIZ token providers, it is recommended that
you switch to using another supported token provider such as the UUID
provider.  This issue might be fixed in a future update of the PKI and
PKIZ token providers in the Identity service.

To check what token provider you are using, you must look in the
'keystone.conf' file for your Identity service.  An example is provided
below:

-  begin keystone.conf sample snippet 
[token]
#provider = keystone.token.providers.pki.Provider
#provider = keystone.token.providers.pkiz.Provider
provider = keystone.token.providers.uuid.Provider
-  end keystone.conf sample snippet 

In the Liberty release of the Identity service, the token provider
configuration is different than previous OpenStack releases.  An
example from the Libery release is provided below:

-  begin keystone.conf sample snippet 
[token]
#provider = pki
#provider = pkiz
provider = uuid
-  end keystone.conf sample snippet 

These configuration snippets are using the UUID token provider.  If you
are using any of the commented out settings from these examples, your
cloud is vulnerable to this issue and you should switch to a different
token provider.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0062
Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/149080
4
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
CVE: CVE-2015-7546
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWcMVpAAoJEJa+6E7Ri+EVhSIIAKolZPY2bYBwtv1ORoWtOCS0
isXHF3Qpp81NCqmtF7m0CQaEKNBDTQSWxDtZ27jx8tu6ORRdrvktw7Nj2BC0blry
v+DwLh+yfrVMH/I+ynXE82tCYllW3t+1KleQvI2ivebQJrw/AfdfHKaN5D4pI/x9
GVBLj2O/OuZ/aC3dhdE7XvXzrHpCXrXVFMsg2DlZeFS0cC85xGowAZcsCBGMxe3o
ffypCaaT1mE2NONtWbQjfnaxBvlrk+4gLq6ztBxKdd8tscmPtMRtDPFXH0A6NZiM
VVGYGtWgKcUaD7uBkmY42KFd15dgi3fStiL9syFErSE6cKcfdirY6UL+30Gj6uM=
=Zplx
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0061] Glance image signature uses an insecure hash algorithm (MD5)

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Glance image signature uses an insecure hash algorithm (MD5)
- ---

### Summary ###
During the Liberty release the Glance project added a feature that
supports verifying images by their signature. There is a flaw in the
implementation that degrades verification by using the weak MD5
algorithm.

### Affected Services / Software ###
Glance, Liberty

### Discussion ###
A signature algorithm is typically created by hashing data and then
encrypting that hash in some way. In the case of the new Glance feature
the signature algorithm does not hash the image to be verified. It
rehashes the existing MD5 checksum that is used to locally verify the
integrity of image data stored in Glance.

The Glance image signature algorithm uses configurable hash algorithms.
No matter which algorithm is used, the overall security of the algorithm
is degraded to that of MD5 because instead of applying it to the image
data it's applied only to the MD5 checksum that already exists in
Glance.

The image signature algorithm is a relatively new feature, introduced in
the Liberty release.

### Recommended Actions ###
Users concerned with image security should be aware that the current
Glance signature algorithm is not secure by todays cryptographic
standards.

A specification for a fix has been proposed by the Glance development
team and is targeted for the Mitaka release.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0061
Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1516031
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
Glance Spec for fix : https://review.openstack.org/#/c/252462/
CVE : CVE-2015-8234
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEbBAEBCAAGBQJWcJc8AAoJEJa+6E7Ri+EVemwH9iG8NkbuIz6e6E3RH7mnIdKm
skmUfxhsHOTN2n+2lQlVtmNoNHYhTDqMmKiQSLuzq1AcMvF/EVuZU36GK/8VBHU5
q3YXqmvXZEM5YqnXNl3xLHlKCUWwgD5SpzGhR9lFrEmFlnT1ZLHwB+FG3JKzsMdm
jOukVVNjiFB6/NhmQQ1FN2pjd3Vkt7lzE1ydvTLpFk+aqx/SDGeW5lnzGxFTOVzr
peTwDdtwGa/fgxsboViT0OprkItmsSuCrXBarKPxgnqTFfhD2bcZ9y5j/7s9II+y
o84A+w/YAJwe8jJgvGChFCyp/7LeV2US8GoxnDsM5OyummMN05DBA06n4FB+9A==
=kl5s
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0059] Trusted VM can be powered on untrusted hosts

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Trusted VM can be powered on untrusted hosts
- ---

### Summary ###
A trusted VM that has been launched earlier on a trusted host can
still be powered on from the same host even after the trusted host is
compromised.

### Affected Services / Software ###
Nova, Trusted Computing Pools

### Discussion ###
Trusted Computing Pools aim to ensure the trustworthiness of the hosts
leveraging hardware-based security features. When an instance is
scheduled, the scheduler finds a trusted host by calling the remote
Attestation API for each host to check whether it is trusted or not.
Then, the scheduler calls the corresponding compute node to launch
the VM. Once the VM is launched, the scheduler is no longer involved
unless a migration, a resize or an evacuation is asked for that VM.

Malicious users can bypass the trust check by the Attestation API using
these steps: 1) Launch a trusted VM on a trusted host; 2) Stop the
VM on the trusted host; 3) Compromise the host; 4) Power on the VM from
the compromised host. There is no check by the Attestation API for
powering on the VM in this case.

### Recommended Actions ###
We recommend investigating further if the trust check by Attestation
API fails but the VM still boots. Another approach is to combine
secure boot with trusted boot. At the same time, Nova team has
discussed deprecating Trusted Filter.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0059
Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1456228
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
Nova Team Email Proposing Deprecation:
http://lists.openstack.org/pipermail/openstack-dev/2015-June/067766.html
CR Demoting TrustedFilter to "experimental":
https://review.openstack.org/#/c/194592
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWSkwBAAoJEJa+6E7Ri+EVu3YH/00Q2zKoTBh1DydSs9HNREJk
NCaQ+T7Imiwwb4AQzSVcyyQsr46RlQNL2d5J0/dS1+Xdv1i/agpPYhaM1tlHQETE
dM70JjJrBOnRlbMSLY2dleIQRdSatBAHD1XXyJGWU906GmUbY1WAmdMqFV5Xbg5A
GsIFmIQJJiH+ZsT0ByU1FeAgeIfAlPM75cy2estDSnsxuv4V36vrKCgAJ4jfHsfY
ZWl5v0S6FcEuygiwqDNSUmrR2iYiZGdyM20CATRSME/LH1JTWP+wNxLqJrcG2vIL
ztJOBduMAm/qdekeAu3aqFpWDq7n8fVlI2ma6XqE3Ygrb5dDbF6KYuCAwBafmSU=
=ZUVf
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0057] DoS attack on Glance service can lead to interruption or disruption

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

DoS attack on Glance service can lead to interruption or disruption
- ---

### Summary ###
The typical Glance workflow allows authenticated users to create an
image and upload the image content in a separate step. This can be
abused by malicious users to flood the Glance database with entries
for zero sized images.

### Affected Services / Software ###
Glance, Icehouse, Juno, Kilo, Liberty

### Discussion ###
Glance by default allows an authenticated user to create zero size
images. Those images do not consume resources on the storage backend
and do not hit any limits for size, but do take up space in the
database.

Malicious users can potentially cause database resource depletion with
an endless flood of 'image-create' requests.

### Recommended Actions ###
For current stable OpenStack releases, users can workaround this
vulnerability by using rate-limiting proxies to cover access to the
Glance API.  Rate-limiting is a common mechanism to prevent DoS and
Brute-Force attacks.  Rate limiting on the API requests allows a delay
in the consequences of the attack, but does not prevent it.

For example, if you are using a proxy such as Repose, enable the rate
limiting feature by following these steps:

  https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter

An alternative approach to mitigate this issue would be to restrict
image creates to trusted administrators within your deployed Glance
policy.json file.

  "add_image": "role:admin",

Another preventative action would be to monitor the logs to identify
excessive image create requests.  One example of such a log message
is as follows (single line, wrapped):

-  begin example glance-api.log snippet 
DEBUG glance.registry.client.v1.api
[req-da1cafc0-f41f-4587-a484-672ba7f3546e
admin 8b04efc28055428c940505838314f262 - - -]
Adding image metadata... add_image_metadata
/usr/lib/python2.7/dist-packages/glance/registry/client/v1/api.py:161
-  end example glance-api.log snippet 

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0057
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1401170
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWICPsAAoJEJa+6E7Ri+EVDUkIAKdQX8YTAQqMTy/zrt3CqPBW
8onT/6zHsg5c/CvuHZE3t/sL6ycpXfOwONMbf/IYrGwazKyiJHOMWAXiVCPN+Itj
EncL8fqpqzKHyqCimZft1umBntypsGzwObMXlYk+0AU3CoLsu6PALSdFZ6Oe34wx
4m/ukz28q7iRS90DsFfJG4Qq+LG60W9pO2emxlAUo+b9KvzcjJDcHywi6sqL18BM
IcjuDxWbRnJRMFlp8EvG0mAyA+LdIVQOAMG242EPURplGtpJhoxjS/iWA28fyWQk
U/T3omTAicgOnYmkq3fPRuXAePLFCm937CsLgNji3RjScW/iUItB55zjJV+UZKM=
=nL7g
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0053] Keystone token disclosure may result in malicious trust creation

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Keystone token disclosure may result in malicious trust creation
- ---

### Summary ###
Keystone tokens are the foundation of authentication and authorization
in OpenStack. When a service node is compromised, it is possible that
an attacker would have access to all tokens passing through that node.
With a valid token an attacker will be able to issue new tokens that
may be used to create trusts between the originating user and a new
user.

### Affected Services / Software ###
Keystone, Grizzly, Havana, Icehouse, Juno, Kilo

### Discussion ###
If a service node is compromised, an attacker now has access to every
token that passes through that node. By default, a Keystone token can
be exchanged for another token, and there is no restriction on scoping
of the new token. With the trust API, these tokens can be used to
delegate roles between the original user and a new user.

Trusts allow a user to set up a long term delegation that permits
another user to perform operations on their behalf. While tokens
created through trusts are limited in what they can do, the
limitations are only on things like changing passwords or creating
new tokens. This would grant an attacker access to all the operations
available to the originating user in their projects, and the roles that
are delegated through the trust.

There are other ways that a compromised token can be misused beyond the
methods described here. This note addresses one possible path for
vulnerabilities based on the unintended access that could be gained
from trusts created through intercepted tokens.

This behavior is intrinsic to the bearer token model used within
Keystone / OpenStack.

### Recommended Actions ###
The following steps are recommended to reduce exposure, based on the
granularity and accepted level of risk in a given environment:

1. Monitor and audit trust creation events within your environment.
Keystone emits notifications on trust creation and deletion that are
accessible through system logs or, if configured, the CADF
data/security/trust resource extension.

2. Offer roles that cannot create trusts / delegate permissions /
assign new roles via Keystone to users. This limits the vector of
attack to compromising Keystone directly or man-in-the-middle capture
of a separate token that has the authorization to create
trusts/delegate/assign roles.

3. Retain the default token lifespan of 1 hour.  Many workloads require
a single token for the whole workload, and take more than one hour, so
installations have increased token lifespans back to the old value of
24 hours - increasing their exposure to this issue.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0053
Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/145558
2
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
Hierarchical Roles : https://review.openstack.org/#/c/125704
Policy by URL : https://review.openstack.org/#/c/192422
Unified policy file : https://review.openstack.org/#/c/134656
Endpoint_ID from URL : https://review.openstack.org/#/c/199844
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWAv74AAoJEJa+6E7Ri+EV3IcH/jv2OGH4fcPz6ftTLbvDgS2T
+5j+Os43ME5KRPIzqgcsQwga3Vse8dSIf8OAiJehqsfuB5wt/nmooFikE56WA/ah
m7fn6g20KmHdGF9EVBaOwhSBFStN9bGDffmR1tEdJ4Z/9rGDYQCOl3/KbUdXyLMr
/WrrBPu2MgeM9XcnyxN+fXhRWp4W2t5MmQCsXky14grtyY1hPmC03wZ98qUZR9CE
KT3UEmtLqG7rfy6UN8msndNeHTj2ZdWiZUc5Og2F/DROIh3KHAbHxl+oi/AqkbXX
ABoVGY2g0PSI1par25mYpOMX1D5k/Pe1DAcMfG07f1xvYwSZfieTDTCSL6yuwq8=
=O6MG
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0056] Cached keystone tokens may be accepted after revocation

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cached keystone tokens may be accepted after revocation
- ---

### Summary ###
Keystone auth_token middleware token and revocation list caching is used
to reduce the load on the keystone service. The default token cache time
is set to 300 seconds and the default token revocation list cache time
is set to 10 seconds. This creates a misleading expectation that revoked
tokens will not be accepted more than 10 seconds after revocation,
however the maximum validity of a cached token must be assumed to be the
cache duration. System owners should make a risk based decision to
balance token lifespan with performance requirements and if the use of
revoked tokens is an unacceptable risk then caching should be disabled.

### Affected Services / Software ###
OpenStack Services that use Keystone middleware: Juno, Kilo, Liberty

### Discussion ###
There are multiple options for configuring token caching in the keystone
auth_token middleware. These options include token_cache_time,
revocation_cache_time and check_revocations_for_cached, with each option
affecting the different stages of token caching and revocation.
Depending on the configuration the previously mentioned options, an
attacker could use a compromised token for up to token_cache_time second
s
before the token becomes disabled. To mitigate this vulnerability, a
change was issued in Juno where the default Token Revocation List (TRL)
cache time was reduced to 10 seconds and the
check_revocations_for_cached option was added. The addition of a token
to a TRL does not guarantee that cached tokens will be rejected
considering the operational nature of token caching. For instance, if
the check_revocations_for_cached is disabled then tokens are valid after
caching token_cache_time or the designated expiration given to the
token. Otherwise (if check_revocations_for_cached is enabled) then
tokens are rejected after the revocation_cache_time.

System owners should weigh the risk of an attacker using a revoked token
versus the performance implications of reducing the token cache time.

### Recommended Actions ###
Review the implications of the default 300 second token cache time and
any risks associated with the use of revoked tokens for up to that cache
time. If this is unacceptable, reduce the cache time to reduce the
attack window or disable token caching entirely.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0056
Original LaunchPad Bug :
https://bugs.launchpad.net/python-keystoneclient/+bug/1287301
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJV+3VfAAoJEJa+6E7Ri+EVyUkH/iEcTFUsBrCPMm04vUtCXABj
lBT2QOGkpTj5rWC6Al5MsnrU4GeU/1hp3hQur1VJAxcro7w56N0eDQJvrpUc0PsP
yPePeiD9N6+WNVy1CTIYd852zepUlBBexOyBDt4k4g4vDn+xQppcm0QxYP3p3u2A
hp+Q6SfWsTpiPNsrMf/HngbGPtnoI92pGE/SGIXjDSMl/jaADmZzapQLEIaXbuXq
4G/3DbiS6oiGcC/Y5aB/Q7dl/baFoBc9wRxIQNEZQq9nhzOGUOshgrDciYMQcW4U
7hxDcs+W4Jnvdn2kvGPxJ8ZBq6z2pEUJf/7/qAUZtCwW7sGWeWvYs/84kZVH4Oo=
=FU3H
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0058] Cinder LVMISCIDriver allows possible unauthenticated mounting of volumes

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cinder LVMISCIDriver allows possible unauthenticated mounting of volumes
- ---

### Summary ###
When using the LVMISCSIDriver with Cinder, the credentials for CHAP
authentication are not formatted correctly in the tgtadm configuration
file. This leads to a condition where an operator will expect that
volumes can only be mounted with the authentication credentials when,
in fact, they can be mounted without the credentials.

### Affected Services / Software ###
Cinder, Icehouse

### Discussion ###
When requesting that LVMISCSIDriver based volumes use the CHAP
authentication protocol, Cinder will add the credentials for
authentication to the configuration file for the tgtadm
application. In pre-Juno versions of Cinder the key name for these
credentials is incorrect. This incorrect key name will cause tgtadm
to not properly parse those credentials.

With incorrect credentials in place, tgtadm will fail to authenticate
volume mounting when requested by Cinder. The failed setting of
credentials through the configuration file will also allow
unauthenticated access to these volumes. This can allow instances
on the same network as the volumes to mount them without providing the
credentials to the tgtadm application.

This behavior can be confirmed by displaying the accounts associated
with a volume. For volumes which have authentication enabled, you will
see an account listed in the output of the tgtadm application. The
account names created by Cinder will be randomly generated and will
appear as 20 character strings. To print the information for volumes
the following command can be run on nodes with attached volumes:

# tgtadm --lld iscsi --op show --mode target

User names will be found in the `Account information:` section.

### Recommended Actions ###
If possible, Cinder should be updated to the Juno release or newer. If
this is not possible, then the following guidance will help mitigate
unwanted traffic to the affected nodes.

1. Identify the nodes that will be exposing Cinder volumes with the
LVMISCSIDriver and the nodes that will need to attach those volumes.

2. Implement either security group port rules or iptables rules on
the nodes exposing the volumes to only allow traffic through port 3260
from nodes that will need to attach volumes.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0058
Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1329214
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJV+y3VAAoJEJa+6E7Ri+EVgg0IAILU1NC/FtRrbWNuEJg3Yryu
3lpxtYuAfVB9tEkJo9jTDeNjCY3Uz+iAMzI5ztjUrD7XVffR9PKB2X0IMTkGqxgT
l6KKPndmhtaD191yuomFQIn30H1cPaNg45ZTrqAJG4yR5ho4xgArQ9qhCtfOid8Q
gS85XraV56fB9Iw6helVGro6dCohz6S8rZksnSzw5rubHF2r56ZpzxgKQie8soOo
nh+XXNubUx8bY25TqCNEojtc7w2t2Ht6XxLHHq9e9JA13hmeO8t+OqzyyIduCOSl
tq42i+SEHACfn1zKoQw/02qNHsYbYtq94RTdavtZK6lkVdwc5DHPr9U7oAeU1Yw=
=9Kem
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0054] Potential Denial of Service in Horizon login

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Potential Denial of Service in Horizon login
- ---

### Summary ###
Horizon uses the Python based Django web framework. Older versions of
this framework allow an unauthorized user to fill up the session store
database causing a Horizon denial of service. A fix for Django is
available but works only with Kilo and later versions of Horizon.

### Affected Services / Software ###
Horizon, Django, Essex, Folsom, Grizzly, Havana, Icehouse, Juno

### Discussion ###
Django will record the session ID of web requests even when the request
is from an unauthorized user. This allows an attacker to populate the
session store database with invalid session information, potentially
causing a denial of service condition by filling the database with
useless session information.

### Recommended Actions ###
The Django developers have released a fix for this issue which is
included in software versions 1.4.21, 1.7.9 and 1.8.3. Horizon
administrators should ensure that they are using an up to date version
of Django to avoid being affected by this vulnerability.

Versions of Horizon prior to Kilo cannot run with the fixed version of
Django, and may require updating to a newer version of OpenStack.
Administrators can test if their deployment is affected by attempting to
inject invalid sessions into the session store database using the
following script and then querying the session store database to check
if multiple 'a' session ID's were recorded.

-  begin example 
for i in {1..100}
do
  curl -b "sessionid=a;" http://HORIZON__IP/auth/login/ &> /dev/null
done
-  end example 

If possible, affected users should upgrade to the Kilo or newer release
of Horizon, allowing them to use the fixed version of Django.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0054
Django fix :
https://www.djangoproject.com/weblog/2015/jul/08/security-releases/
Django CVE : CVE-2015-5143
Original LaunchPad Bug : https://bugs.launchpad.net/horizon/+bug/1457551
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJV+yvwAAoJEJa+6E7Ri+EVCREIAIcQLlU0SJeabkcJKy1tBa5A
lNrQzBG4t4XRal0lyOl27hPIJ5JYmTIopnix1mNpuuYFV39zzC2vvPk04Znhz2bX
Tqw07UXu18wN8iI+/nt6V4fCIBSrnBmNv87ilNvCug0CilgnJdjYiBJqnueHZCMR
bdNmHnhDiq3LdumKmtTumEQ2LH1iUx6YJJuoUjdbtA8oE2kQ3wiTkCV2hWZaoDQx
fBEzyGzJt5RfGouzDK4pp1oG5eOMZHx1rGNMwJbta6pt4Gc6NGNNQowBLusap9Ko
W2xRN3fHOFmrjNJi8dK+RDX4lPexVh7TDY4/Jox5fTTZFwMcrCU+1d9QajwhEcU=
=KHI6
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0055] Service accounts may have cloud admin privileges

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Service accounts may have cloud admin privileges
- ---

### Summary ###
OpenStack services (for example Nova and Glance) typically use a
service account in Keystone to perform actions.  In some cases this
service account has full admin privileges, may therefore perform any
action on your cloud, and should be protected appropriately.

### Affected Services / Software ###
Most OpenStack services / all versions

### Discussion ###
In many cases, OpenStack services require an OpenStack account to
perform API actions such as validating Keystone tokens.  Some
deployment tools grant administrative level access to these service
accounts, making these accounts very powerful.

A service account with administrator access could be used to:

  - destroy/modify/access data
  - create or destroy admin accounts
  - potentially escalate to undercloud access
  - log in to Horizon

### Recommended Actions ###
Service accounts can use the "service" role rather than admin.  You
can check what role the service account has by performing the following
steps:

1. List roles:

 openstack role list

2. Check the role assignment for the service user in question:

 openstack role assignment list --user 

3. Compare the ID listed in the "role" column from step 2 with the role
IDs listed in step 1.  If the role is listed as "admin", the service
account has full admin privileges on the cloud.

It is possible to change the role to "service" for some accounts but
this may have unexpected consequences for services such as Nova and
Neutron, and is therefore not recommended for inexperienced admins.

If a service account does have admin, it's advisable to closely
monitor login events for that user to ensure that it is not used
unexpectedly.  In particular, pay attention to unusual IPs using the
service account.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0055
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1464750
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJV+wq9AAoJEJa+6E7Ri+EVxgUH/2EEDXgPQn0TZpds9kK10mVC
jsi8Y/OEAJD2xnUS+ZkT0GbpopOJa3XRWKUmPCufYDz5Ay3ATyTfMuSdH519ZDK6
0sfZmSZK/AKXALFoUUBB1J2QckmrbH9tvMlr3NQ6f1a4MT0UIgkQvGZnduGSF9Gm
aglGWcuhL7TvzuuawwHoivDtWdNWEYOgrvG1779U6uSz9Dj23GvQQwn79y6JE7qt
N2D9dcxqXBlOV+hfcidJVzZ9FvEz7YY2yHZ9EK1apCinDhRin8CH+0W5Ukbur2K+
I1JtvIqMHddoKu6REqQCe3vyme7IHUuYYpiwJgT3yNBDlk+3nbjwRLcUpW4XNPk=
=cGtS
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0052] Python-swiftclient exposes raw token values in debug logs

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Python-swiftclient exposes raw token values in debug logs
- ---

### Summary ###
The password and authentication token configuration options for the
python-swiftclient are not marked as secret. The values of these options
will be logged to the standard logging output when the controller is run
in debug mode.

### Affected Services / Software ###
Python-swiftclient, Swift, Glance, Juno, Kilo

### Discussion ###
When using the python-swiftclient to connect to Glance, and the
:glance-api.conf: has set the value of the debug option to True, the
requests sent through the API, including user and token details, will be
captured in the local log mechanism.

### Recommended Actions ###
It is recommended to use the debug level in configurations only when
necessary to troubleshoot an issue. When the debug flag is set, the
resulting logs should be treated as having sensitive information and as
such should have strict permissions around the file and containing
directory set in the operating system. Additionally, the logs should
not be transported off the system in plaintext such as through syslog.

The debug level can be turned off by setting the following option in
the `glance-api.conf` file:

[DEFAULT]
debug = false

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0052
Original LaunchPad Bug :
https://bugs.launchpad.net/python-swiftclient/+bug/1470740
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJV+wY0AAoJEJa+6E7Ri+EVIDEH/jtjxXOMTiiGMVrlBCwRIbVj
qxqbe8ExtWxz21cMFHOvxxdZgeOerNegTxUqgil1MVQMC9DZuVmkyPt7NLwWhN9l
Xqul/Rrk4UNBlesGuCVlXPCmcaH6HXzZG1Jaty2QDok/0ev1QUynb1i4cktISUJm
Xo0TCt/R7CijyD/AHrLOxjHwh7NUyT+8v9dyD8wdalAA814wmyz31aFW/FCfunaP
v6yx89H0FjPbxksXcB9O+E1ZyGVGJBkU7GuzAGcr6Wa+9/dg14AzQmUb4/AbEyEt
udQ275vGkicGImGOrVANwEIHK7ooliede2sxgG1omhqAd3Ak/QsMcMpbw3gk1BE=
=w1KU
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0049] Nova ironic driver logs sensitive information while operating in debug mode

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nova ironic driver logs sensitive information while operating in debug
mode
- ---

### Summary ###
The password and authentication token configuration options for the
ironic driver in nova are not marked as secret. The values of these
options will be logged to the standard logging output when the
controller is run in debug mode.

### Affected Services / Software ###
Nova, Ironic, Juno, Kilo

### Discussion ###
When using nova with the ironic driver, an operator will need to specify
either the password or an authentication token for the ironic admin
user's keystone credentials. Under normal circumstances this is not an
issue, but when running the API server with logging levels set to
include the DEBUG message level these credentials will be exposed in
the logs.

Logging of configuration values is controlled by the `secret` flag for
any oslo configuration option. Without this flag set, the value for a
configuration option will be displayed in the logs. In the case of the
ironic credentials, these options are not marked as secret.

This presents a challenge to any operator who might have increased the
log verbosity for the purposes of debugging or extended log collection.
Depending on permissions and log storage location, these values could
be read by an intruder to the system. The credentials will provide
anyone who controls them access to the ironic API server's
administrative functions. Additionally, they could be used in
conjunction with OpenStack Identity functions to issue new
authentication tokens or perform further malicious activity depending
on the scope of the administrative account access (for example,
modifying account permissions).

All nova installations that have values defined for the
`admin_password` or `admin_auth_token` options in the `ironic` section,
and have set `debug=true` in the `DEFAULT` section of their
configuration file will be affected by this issue.

### Recommended Actions ###
As of the Liberty-1 release of nova, this issue has been resolved.
It has also been backported to the Kilo and Juno stable releases, which
can be expected in the 2015.1.1 and 2014.2.4 tags, respectively.

Where possible, nova deployments should be updated to one of these
releases: Liberty-1, 2015.1.1 (Kilo), or 2014.2.4 (Juno).

If updating the nova deployment is not feasible, operators should
turn off the debug logging level whenever it is not in use and ensure
that log files produced from those debug sessions are stored securely.
To disable the debug log level, the nova configuration file should be
editted as follows:

[DEFAULT]
debug = False

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0049
Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1451931
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
Oslo Config Special Handling Instructions:
http://docs.openstack.org/developer/oslo.config/cfg.html#special-handling-instructions
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVm9gBAAoJEJa+6E7Ri+EVkLAIAJhikdqb4vDycqO/1e1R8L1k
W6X/Et2NBGKkPSSMGI1MtJt/QxfqMPqJ/Y0pyyyhnoayvYBJVg12l3hPqTMSnM3N
UM4s15mbxJA0wPJrSM8OMVUEpoB30qkDftco/xBnzhC/ClknQwIH3M6G1iWE2Wwk
me82RTwta7F2t+u66pPoQ/ByM89YOyuiCSegCKpeCtw+O1qQa5z6zK7gcnhno487
vBPTywoWW/VgQn+zqZGXzXEVFVL0PQ74gXMyF7+6VgG3egJaGwQ9CFx5rmU9fiIr
6+ZSnQTOBhpKv9zVNkg0WGuFAdt/qwuYA9292tCe7xPrSEKtDVLt/Gx6APfRjbU=
=fdYf
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Security] Nominating Michael McCune for Security CoreSec

[Nathan Kinder]

On 06/15/2015 09:16 AM, McPeak, Travis wrote:
> I¹d like to propose Michael McCune for CoreSec membership.
> 
> I¹ve worked with Michael (elmiko) on numerous security tasks and
> bugs, and he has a great grasp on security concepts and is very active
> in the OpenStack security community.  I think he would be a natural
> choice for CoreSec.

+1

> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Security] Nominating Travis McPeak for Security CoreSec

[Nathan Kinder]

On 06/16/2015 02:28 AM, Clark, Robert Graham wrote:
> I’d like to nominate Travis for a CoreSec position as part of the
> Security project. - CoreSec team members support the VMT with extended
> consultation on externally reported vulnerabilities.
> 
>  
> 
> Travis has been an active member of the Security project for a couple of
> years he’s a part of the bandit subproject and has been very active in
> discussions over this time. He’s also found multiple vulnerabilities and
> has experience of the VMT process.

+1

> 
>  
> 
> -Rob**
> 
>  
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [security] Nominating Mike McCune as Security-Doc Core

[Nathan Kinder]

On 05/19/2015 05:20 PM, Dillon, Nathaniel wrote:
> To the Security and Docs groups as well as other interested parties, 
> 
> I would like to nominate Mike McCune to the Security Guide core. He has been 
> contributing to the Security Guide for about six months now, and he has been 
> a consistent participant improving content and helping new submittors. In 
> addition, he knows the inner workings of the guide, having created and merged 
> for the security guide the chapter on Sahara.
> 
> Please chime in with your agreement, or concerns.

+1!  Mike's work has been great.

-NGK

> 
> Thanks,
> 
> Nathaniel
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0046] Setting services to debug mode can also set Pecan to debug

[Nathan Kinder]

Setting services to debug mode can also set Pecan to debug
---

### Summary ###
When debug mode is set for a service using Pecan (via --debug or
CONF.debug=True) Pecan is also set to debug. This can result in
accidental information disclosures.

### Affected Services / Software ###
Blazar, Ceilometer, Cue, Gnocchi, Ironic, Kite, Libra, Pecan, Tuskar

### Discussion ###
Although it's best practice to run production environments with
debugging functionality disabled, experience shows us that many
deployers choose to run OpenStack with debugging enabled to aid with
administration and fault finding.

When Pecan is running in debug mode, the following capabilities are made
available to anyone who can interact with the API service:

* Retrieve a stack trace of failed Pecan calls
* Retrieve a full list of environment variables containing potentially
sensitive information such as API credentials, passwords etc.
* Set an execution breakpoint which hangs the service with a pdb shell,
resulting in a denial of service

### Recommended Actions ###
At time of writing, Ceilometer, Gnocchi and Ironic have released fixes.
Deployers are encouraged to apply these fixes (see launchpad bug in
References) in their clouds. For services that do not have a fix, or
where fixes cannot be applied in existing deployments, we advise not
using the debug configuration for affected services in production
environments.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0046
Original LaunchPad Bug : https://bugs.launchpad.net/ironic/+bug/1425206
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
Pecan : http://www.pecanpy.org/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0048] Glance method filtering does not work under certain conditions

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Glance method filtering does not work under certain conditions
- ---

### Summary ###
Glance is using the Python assert statement for validating the HTTP
method type in its caching middleware for some image endpoints. The
Python documentation states that when optimization is requested
(command line option -O), assert statements will not be evaluated.
This results in a condition where these method validations will not
occur and can allow a specific method to be called with a different
HTTP verb.

### Affected Services / Software ###
Glance, Icehouse, Juno, Kilo

### Discussion ###
Glance uses the Python assert statement to validate the HTTP method
for some of the image endpoints in the version 1 and 2 REST interfaces.
In circumstances where glance is being run with Python optimization
enabled (by using the -O command line option), these assert statements
will not be evaluated. In these cases, the HTTP verb is unchecked for
the requested endpoints.

The endpoints and methods affected by this are the following:

* GET on /v1/images/{image_id}
* DELETE on /v1/images/{image_id}
* GET on /v2/images/{image_id}/file
* DELETE on /v2/images/{image_id}

This can lead to access violations in some configurations. For
example, if filtering were occurring in front of the glance API to
restrict queries based on HTTP method and IP address, an attacker
could circumvent this filtering by matching the endpoint regular
expression and providing a different HTTP verb. In this example
an attacker would be able to download or delete images from glance.

Assuming a user were restricted by network filtering to only send
DELETE requests to the glance API endpoint. The user could attempt to
circumvent the filtering by sending a well crafted request to the
endpoint that would actually retrieve the named image. If an image ID
were known to be "12345", then a DELETE request sent to the glance API
endpoint "/v2/images/12345/file" would end up matching the GET URI
pattern. This would retrieve the image from glance, thus exploiting the
filtering.

### Recommended Actions ###
As of the Kilo-rc1 release of glance, this vulnerability has been
patched. It has also been backported to the stable branch of the Juno
release and will be officially updated in the 2014.2.4 tag of glance.
This will not be fixed for Icehouse.

Kilo deployments should be updated to the rc1 tag. Juno deployments
should be updated to the 2014.2.4 tag. Operators maintaining Icehouse
deployments of glance should consider upgrading to the Juno 2014.2.4
release.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0048
Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1414532
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
Python assert documentation:
https://docs.python.org/3/reference/simple_stmts.html#the-assert-statement
Python optimize documentation:
https://docs.python.org/2/using/cmdline.html#envvar-PYTHONOPTIMIZE
Glance v1 API: http://developer.openstack.org/api-ref-image-v1.html
Glance v2 API: http://developer.openstack.org/api-ref-image-v2.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVQkJYAAoJEJa+6E7Ri+EVwC8H/1uOJOMq1BXnauST+LJqIhSD
+GXNG40UyNzoL7Z5YAgB4w30DvrBybCNcg4En1vCC83icYj8zUaDnK7SafSL1SRS
InAnluJ4cNHXarXcZFqGItwMwnLmub20m0M14hhMNe+TGtMoggzUO1w/mqV9GCSb
YZF5AJhjKp8p8hHsbp5wwnKYeCp0QVj08FxT0HPx1M/jrQ2ZKQrzdvWiH70zHqVS
DZYREVv7zqzmNQ81/9iEgk9rLKMORHpUnonDrmWyaSdkXL86+2RRUQd1fusybeB3
IfmesiJlFudIPmm7CHT3fwjN6rdzmQKLPNEF+6n9PwRKy+Q3csRYxG9m5b0ArKs=
=b/fG
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0047] Keystone does not validate that identity providers match federation mappings

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Keystone does not validate that identity providers match federation
mappings
- ---

### Summary ###
Keystone's OS-FEDERATION extension does not enforce a link between an
identity provider and a federation mapping.  This can lead to assertions
or claims from one identity provider being used with mappings intended
for use with another identity provider, which could result in users
obtaining access to resources that they are not intended to have.

### Affected Services / Software ###
Keystone, Juno, Kilo

### Discussion ###
Keystone's OS-FEDERATION extension allows for a set of environment
variables provided by a trusted identity provider to be used as mapping
inputs to determine group membership (and ultimately role assignment).
Mapping rules are intended to be identity provider specific, as
different identity providers provide their assertions or claims in
different forms.

In the Juno release of Keystone, there is no ability within Keystone
itself to enforce that assertions or claims from an identity provider
are actually being used against a mapping that is associated with that
same identity provider.  A malicious user from one trusted identity
provider could access a Keystone federated authentication URL for a
different trusted identity provider.  Depending on the content of the
assertions or claims and the mapping rules, this could result in a user
gaining access to resources that they are not intended to access.

Consider an example deployment where Keystone is configured to trust two
identity providers ('idp1' and 'idp2').  The federation mapping for
'idp1' might result in users of the 'devops' group having the 'admin'
role on a specific project.  If a user with an assertion or claim from
'idp2' that says they are in the 'devops' group uses the authentication
URL that is associated with 'idp1', they could also be given the 'admin'
role just as if they were a 'devops' user from 'idp1'.  This access
should not be allowed.

### Recommended Actions ###
Even though the Juno release of Keystone does not have the ability to
enforce that an identity provider and a mapping match, it is possible to
configure the frontend webserver that is used to deploy Keystone to
perform this enforcement.  Each identity provider supported by Keystone
has its own authentication URL.  It is recommended that the webserver
configuration configures its underlying federation plug-ins to
cryptograhically enforce that an identity provider is only valid for
its associated authentication URL.

For example, the SAML protocol uses an asymmetric keypair to sign the
requests and responses that are transmitted between an identity provider
and a service provider (Keystone in our case).  When using Apache HTTPD
as a webserver for Keystone, a separate 'Location' directive can be used
for each federated authentication URL.  The directives that define the
certificate of the identity provider for the underlying HTTPD module
that is handling the SAML protocol can be defined within the identity
provider specific 'Location' directives.  This will ensure that a signed
SAML assertion from one trusted identity provider will only be
successfully validated when used against the appropriate authentication
URL.

Here is an example with the mod_auth_mellon HTTPD module:

- --- begin example httpd configuration snippet ---
  
AuthType "Mellon"
MellonEnable "auth"
...
MellonIdPMetadataFile /etc/httpd/mellon/idp1-metadata.xml
MellonEndpointPath
/v3/OS-FEDERATION/identity_providers/idp1/protocols/saml2/auth/mellon
  

  
AuthType "Mellon"
MellonEnable "auth"
...
MellonIdPMetadataFile /etc/httpd/mellon/idp2-metadata.xml
MellonEndpointPath
/v3/OS-FEDERATION/identity_providers/idp2/protocols/saml2/auth/mellon
  
- --- end example httpd configuration snippet ---

In the above example, we have two identity providers ('idp1' and
'idp2').  Each identity provider has their own 'Location' directive,
and the 'MellonIdPMetadataFile' directive that points to the metadata
that contains the certificate of the identity provider is specific to
each 'Location' directive.  This configuration will not allow a signed
assertion from 'idp1' to be used against the authentication URL for
'idp2'.  An attempt to do so would be rejected by mod_auth_mellon and
would never actually reach Keystone's OS-FEDERATION extention.

It is recommended to read the Keystone federation documentation as well
as the documentation for the HTTPD module that you are using for your
federation method of choice.  Some useful links to this documentation
are provided in the references section of this note.

In the Kilo release of Keystone, it is also possible to have Keystone
enforce that an assertion actually comes from the identity provider that
is associated with the authentication URL.  This is performed by
comparing an identity provider identifier value from the assertion or
claim with an identifier that is stored as a pa

[openstack-dev] [OSSN 0045] Vulnerable clients allow a TLS protocol downgrade (FREAK)

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Vulnerable clients allow a TLS protocol downgrade (FREAK)
- ---

### Summary ###
Some client-side libraries, including un-patched versions of OpenSSL,
contain a vulnerability which can allow a man-in-the-middle (MITM) to
force a TLS version downgrade. Even though this vulnerability exists in
the client side, an attack known as FREAK is exploitable when TLS
servers offer weak cipher choices. This security note provides guidance
to mitigate the FREAK attack on the server side, so that TLS provides
reasonable security for even un-patched clients.

### Affected Services / Software ###
Any service using TLS. Depending on the backend TLS library, this
can include many components of an OpenStack cloud:

- - OpenStack services
- - OpenStack clients
- - Web servers (Apache, Nginx, etc)
- - SSL/TLS terminators (Stud, Pound, etc)
- - Proxy services (HAProxy, etc)
- - Miscellaneous services (eventlet, syslog, ldap, smtp, etc)

### Discussion ###
TLS connections are established by a process known as a TLS handshake.
During this process a client first sends a message to the server known
as "HELLO", where among other things the client lists all of the TLS
encryption ciphers it supports. In the next step, the server responds
with its own "HELLO" packet, in which the server picks one of the cipher
options the client offered. After this the client and server continue on
to securely exchange a secret which becomes a master key.

The FREAK attack exploits a flaw in client logic in which vulnerable
clients don't actually check that the cipher which was selected by the
server was one they had offered in the first place. This creates the
possibility that an attacker on the network somewhere between the client
and server can alter the client's HELLO packet, removing all choices
except for really weak ciphers known as "export grade ciphers". If the
server supports these weak ciphers, it will (regretfully) chose it, as
it appears that this is the only option that the client supports, and
send it back in the server HELLO message.

Export grade ciphers are a legacy of a time when the US government
prohibited the export of cryptographic ciphers which were stronger than
512 bits for asymmetric ciphers and 40 bits for symmetric ciphers. Today
these ciphers are easily and quickly crackable using commodity hardware
or cloud resources.

### Recommended Actions ###
Since this is a vulnerability in client logic, the best option is to
ensure that all clients update to the latest version of the affected
library. For more details about upgrading OpenSSL please see the link to
the OpenSSL advisory in the "Further discussion" section below. Since it
is unfeasible to assume that all clients have updated, we should also
mitigate this on the TLS server-side.

To mitigate the FREAK attack on the server side, we need to remove
support for any ciphers which are weak. This is to prevent a MITM from
forcing the negotiation of a weak cipher. In particular we need to
remove support for any export grade ciphers, which are especially weak.

The first step is to find what versions your TLS server currently
supports.  Two useful solutions exist for this: SSL Server Test at
Qualys SSL Labs can be used to scan any web accessible endpoints, and
SSLScan is a command line tool which attempts a TLS connection to a
server with all possible cipher suites.  Please see "tools" below for
links to both.

The specific steps required to configure which cipher suites are
supported in a TLS deployment depend on the software and configuration,
and are beyond the scope of this note. Some good starting places are
provided below in the section: "Resources for configuring TLS options".

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0045
Original LaunchPad Bug : N/A
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
CVE: CVE-2015-0204 (OpenSSL)
Further discussion of the issue:

http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html
https://www.smacktls.com/
https://www.openssl.org/news/secadv_20150108.txt
Tools:
SSLScan: http://sourceforge.net/projects/sslscan/
SSL Server Test: https://www.ssllabs.com/ssltest/
Resources for configuring TLS options:
In OpenStack:
http://docs.openstack.org/security-guide/content/tls-proxies-and-http-services.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVAKEbAAoJEJa+6E7Ri+EV1zsH/3xbCGhalwARdommJ6hWhoMz
3L3LnkixTCjpapOX+oiGvob1PRr5fRkc9T0k0pNXgNIa2WSPrTCLFn7yNbwBV6pz
ZCtiiL9eyp9YqAMf5RMtnKM4jLuyoQuZfQ9NtlJoiqOLzgkhD2oY6FU9wAcA8M2D
7VmLfQtMEH4MBbERMEPwG6Rq6rMeoL/kbjN1aB4b3WDxrJx/1iNX0gJxaMPqERz6
oYiQxgRsInwEtT66/slDOc9R8vD8u40pSbm7TBMQUU/orwVzakkwwM5XA/5Q2cIU
IIRbXmxrwtTKIEBL1PmDldxBrXEQsLnKyzfquu1gEu0m8FGvdfgcXxZaMNwixbI=
=qgzB
-END PGP SIGNATURE-

___

Re: [openstack-dev] nominating Nathaniel Dillon for security-doc core

[Nathan Kinder]

On 03/05/2015 01:14 PM, Bryan D. Payne wrote:
> To security-doc core and other interested parties,
> 
> Nathaniel Dillon has been working consistently on the security guide
> since our first mid-cycle meet up last summer.  In that time he has come
> to understand the inner workings of the book and the doc process very
> well.  He has also been a consistent participant in improving the book
> content and working to define what the book should be going forward.
> 
> I'd like to bring him on as a core member of security-doc so that he can
> help with the review and approval process for new changes to the book. 
> Please chime in with your agreement or concerns.

+1 on making Nathaniel core!

-NGK

> 
> Cheers,
> -bryan

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0044] Older versions of noVNC allow session theft

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Older versions of noVNC allow session theft
- ---

### Summary ###
Commonly packaged versions of noVNC allow an attacker to hijack user
sessions even when TLS is enabled. noVNC fails to set the secure flag
when setting cookies containing an authentication token.

### Affected Services / Software ###
Nova, when embedding noVNC prior to v0.5

### Discussion ###
Versions of noVNC prior to October 28, 2013 do not properly set the
secure flag on cookies for pages served over TLS. Since noVNC stores
authentication tokens in these cookies, an attacker who can modify
user traffic can steal these tokens and connect to the VNC session.

Affected deployments can be identified by looking for the "secure"
flag on the token cookie set by noVNC on TLS-enabled installations. If
the secure flag is missing, the installation is vulnerable.

At the time of writing, Debian, Ubuntu and Fedora do not provide
versions of this package with the appropriate patch.

### Recommended Actions ###
noVNC should be updated to version 0.5 or later. If this is not
possible, the upstream patch should be applied individually.

Upstream patch:
https://github.com/kanaka/noVNC/commit/ad941faddead705cd611921730054767a0b32dcd

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0044
Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1420942
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
CVE: in progress-http://www.openwall.com/lists/oss-security/2015/02/17/1
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU9NFyAAoJEJa+6E7Ri+EV5soH/3xK10vI3I4CM8Uhyk8pZcgA
5+s7ukrcQWymExN4XGDRB5b2hwfmTpHjOJAkgLNvP7edNezE6QvXit6cBBNoXUo2
nW/iC7QKmu7oS56F+OpqFf+PZNmxDqCF40ec9pjt0id5V/1cvePH+Vc9Kuus6Lig
LwsIG4A8tRiCsN5d2OOdGULSBhCN/yCdDKbf2mdaB4Ebimb2+6c7Nfs1iskOIZAm
Me0jC2a0rPP07Fh5dnS+4uDkAk+BU5UIrs64Ua63AQuvC6evHnMF6uByrFdATxk7
DgDftsY/4ahexV6rTIBvjzbTngmOGWaegknH1dE2Peuv32fe6v3c68LD8lG6BgM=
=SUiL
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0043] glibc 'GHOST' vulnerability can allow remote code execution

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

glibc 'GHOST' vulnerability can allow remote code execution
- ---

### Summary ###
A serious vulnerability in the GNU C library (glibc) gethostbyname*
functions can allow an attacker to perform remote code execution with
the privileges of the application that calls the gethostbyname*
function. The vulnerable functions are used by a vast number of
programs, effectively any time a network socket is used in a linux
system, so the full exploitability of this vulnerability will not
become known immediately.

The publishers of this vulnerability, Qualys, have announced a proof of
concept exploit for the Exim mail server, which bypasses operating
system protections such as ASLR and DEP.


### Affected Services / Software ###
All versions running on Linux installations with a vulnerable glibc
library.

### Discussion ###
The GNU C library (glibc), from versions 2.2 to 2.17 inclusive, has
a group of vulnerable functions for hostname/address resolution. There
is a buffer overflow in the __nss_hostname_digits_dots() function which
is used by the gethostbyname*() group of functions. The maximum amount
of memory that can be overwritten is sizeof(char *), i.e. 4 bytes on
typical 32-bit systems and 8 bytes on typical 64-bit systems.

These low-level functions are linked by many other C/C++ programs and
interpreted languages like Python, Perl and Bash, so this vulnerability
is insidious and will appear in cases where it would not at first seem
obvious. There are many cases in a typical Linux installation where
these functions will be used, generally wherever a hostname is resolved
to an IP address, although in newer applications an IPv6 compatible
function, getaddinfo() may be used instead.

This vulnerability could let an attacker remotely execute code in cases
where they control the input to a function that performs hostname
resolution. There are no currently-known OpenStack-specific
exploitation paths associated with this vulnerability. However, the
Python socket library presents a gethostbyname() wrapper around the
glibc function, and there are various ways in which this could be
exposed.

### Recommended Actions ###
The glibc library is loaded into memory when a process that uses it
starts up, so to fix the vulnerability, glibc should be updated to a
non-vulnerable version (2.18 or newer) and all services which use glibc
should be restarted to replace the version in memory. Due to the number
of places where these vulnerable functions are used, this effectively
means that vulnerable systems must be restarted after updating glibc.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0043
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1415416
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
CVE: CVE-2015-0235
Source advisory:
https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU02eRAAoJEJa+6E7Ri+EVXu8IAIDuL3LbQKtSvLiyleAqF3nd
WUTiqdAIRc6cf7xJdMyVm8W0ISOE88YpscSeT55xbiaPVL7joro0vVP7CLhFg5E3
wRzT9W+abAj62EFU7SOjLGiKEWbIHa+Aa3W+r/bPXCJACP3V1XCEnZya+g6GuXT7
JbV9EYYeprAGWQNvSEA8g49YYq44aIxuGqDd6ti6pye3wTgf5e0emGP1BIS/i3TI
htQfp4F+zGtRukjWdg3HVoLOKtZYqLHEJT0EUEcq4hzTFKEFhk6x93zYIrRhil+d
+Jm70OeeKosS64Ebe+06sc2g1jTVNryvozxl95MYR09axkfgd2myjxDZMB5Ak+o=
=NlVl
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0038] Suds client subject to cache poisoning by local attacker

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Suds client subject to cache poisoning by local attacker
- ---

### Summary ###
Suds is a Python SOAP client for consuming Web Services. Its default
cache implementation stores pickled objects to a predictable path in
/tmp. This can be used by a local attacker to redirect SOAP requests via
symlinks or run a privilege escalation or code execution attack.

### Affected Services / Software ###
Cinder, Nova, Grizzly, Havana, Icehouse

### Discussion ###
The Python 'suds' package is used by oslo.vmware to interface with SOAP
service APIs and both Cinder and Nova have dependencies on oslo.vmware
when using VMware drivers. By default suds uses an on-disk cache that
places pickle files, serialised Python objects, into a known location
'/tmp/suds'. A local attacker could use symlinks or place crafted files
into this location that will later be deserialised by suds.

By manipulating the content of the cached pickle files, an attacker can
redirect or modify SOAP requests. Alternatively, pickle may be used to
run injected Python code during the deserialisation process. This can
allow the spawning of a shell to execute arbitrary OS level commands
with the permissions of the service using suds, thus leading to possible
privilege escalation.

At the time of writing, the suds package appears largely unmaintained
upstream. However, vendors have released patched versions that do not
suffer from the predictable cache path problem. Ubuntu is known to offer
one such patched version (python-suds_0.4.1-2ubuntu1.1).

### Recommended Actions ###
The recommended solution to this issue is to disable cache usage in the
configuration as shown:

  'client.set_options(cache=None)'

A fix has been released to oslo.vmware (0.6.0) that disables the use of
the disk cache by default. Cinder and Nova have both adjusted their
requirements to include this fixed version. Deployers wishing to
re-enable the cache should ascertain whether or not their vendor
shipped suds package is susceptible and consider the above advice.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0038
Original Launchpad Bug : https://bugs.launchpad.net/ossn/+bug/1341954
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
Suds: https://pypi.python.org/pypi/suds
CVE: CVE-2013-2217
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUkncTAAoJEJa+6E7Ri+EV4sQH/RUgDVqGRs5tdBGApTd3ljq0
ThqY8+5/3dqOYJ767/tTQ7WghGcPouFV8hXeco2ZS7oYS41kcBwQnvTRCol6bRqH
ayKjQIiNvaonHsSSwyhB1fMuUTjMzbTDg6w94xfy2Ibl+0XTskXkhQ2qqLB7yG4H
4sDWZNykE5sGcpn7zB2Xr+6IkODqNlPI5AAGmLBM9N1XB/Y98tQ+k8V7T3cvuF6+
77/o6WiyD5Q5g5s2/yaOuvOhZu4W3bxAXwKskYBvVIoxA90SPu66hQ2BQHPIzSIX
pZG0efK25s1slgY8yL8uNAG2GLIhhgvDk8aW5GkV9XJQ4jIh+15TILNmazSq9Q0=
=hEO/
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0042] Keystone token scoping provides no security benefit

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Keystone token scoping provides no security benefit
- ---

### Summary ###
Keystone provides "scoped" tokens that are constrained to use by a
single project. A user may expect that their scoped token can only be
used to perform operations for the project it is scoped to, which is not
the case. A service or other party who obtains the scoped token can use
it to obtain a token for a different authorized scope, which may be
considered a privilege escalation.

### Affected Services / Software ###
Keystone, Diablo, Essex, Folsom, Grizzly, Havana, Icehouse, Juno, Kilo

### Discussion ###
This is not a bug in keystone, it's a design feature that some users may
expect to bring security enhancement when it does not. The OSSG is
issuing this security note to highlight the issue.

Many operations in OpenStack will take a token from the user and pass it
to another service to perform some portion of the intended operation.
This token is very powerful and can be used to perform many actions for
the user. Scoped tokens appear to limit their use to the project and
roles they were granted for but can also be used to request tokens with
other scopes. It's important to note that this only works with currently
valid tokens. Once a token expires it cannot be used to gain a new
token.

Token scoping helps avoid accidental leakage of tokens because using
tokens with other services requires the extra step of requesting a new
re-scoped token from keystone. Scoping can help with audit trails and
promote good code practices. There's currently no way to create a
tightly scoped token that cannot be used to request a re-scoped token. A
scoped token cannot be relied upon to restrict actions to only that
scope.

### Recommended Action ###
Users and deployers of OpenStack must not rely on the scope of tokens
to limit what actions can be performed using them.

Concerned users are encouraged to read (OSSG member) Nathan Kinder's
blog post on this issue and some of the potential future solutions.

### Contacts / References ###
Nathan Kinder on Token Scoping : https://blog-nkinder.rhcloud.com/?p=101
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0042
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1341816
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUkazTAAoJEJa+6E7Ri+EVnj0H/jQWtbkVN+na2GzI3VbNSLsF
MPnGqO6tMcblKvI0m8okbyzhtpSDVAjPTCeoGY4PB5/AE31j1CDrlMT+bnm/Zk+O
rAXeYgBvyjw9FbP9/UeNZPjQPByWaxGr8L90kuSGiL7rBvgf8KoxFJ2Kb9zNDWLJ
bBAJ0A7QjOAri4RnyXoSINzKKawEJzM8va6R3iFtn6yF8Q/1ta3NBB5uWbgkS26M
jtIvTNU/wGxX4b2mQ6gOno/4TwTZIqX+qTdDRXE811NZqSwdNfGRTD1hUQPYYtRq
ioNBDrH/gXsmI4Lr/gXxki1zjPiSzWcbWOVu1PsnJTmFpYrI0FafguKwya4+YhI=
=w/r8
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] A mascot for Ironic

[Nathan Kinder]

On 11/16/2014 10:51 AM, David Shrewsbury wrote:
> 
>> On Nov 16, 2014, at 8:57 AM, Chris K > > wrote:
>>
>> How cute.
>>
>> maybe we could call him bear-thoven.
>>
>> Chris
>>
> 
> I like Blaze Bearly, lead singer for Ironic Maiden.  :)
> 
> https://en.wikipedia.org/wiki/Blaze_Bayley

Good call!  I never thought I'd see a Blaze Bayley reference on this
list. :) Just watch out for imposters...

http://en.wikipedia.org/wiki/Slow_Riot_for_New_Zer%C3%B8_Kanada#BBF3

> 
> 
>>
>> On Sun, Nov 16, 2014 at 5:14 AM, Lucas Alvares Gomes
>> mailto:lucasago...@gmail.com>> wrote:
>>
>> Hi Ironickers,
>>
>> I was thinking this weekend: All the cool projects does have a mascot
>> so I thought that we could have one for Ironic too.
>>
>> The idea about what the mascot would be was easy because the RAX guys
>> put "bear metal" their presentation[1] and that totally rocks! So I
>> drew a bear. It also needed an instrument, at first I thought about a
>> guitar, but drums is actually my favorite instrument so I drew a pair
>> of drumsticks instead.
>>
>> The drawing thing wasn't that hard, the problem was to digitalize it.
>> So I scanned the thing and went to youtube to watch some tutorials
>> about gimp and inkspace to learn how to vectorize it. Magic, it
>> worked!
>>
>> Attached in the email there's the original draw, the vectorized
>> version without colors and the final version of it (with colors).
>>
>> Of course, I know some people does have better skills than I do, so I
>> also attached the inkspace file of the final version in case people
>> want to tweak it :)
>>
>> So, what you guys think about making this little drummer bear the
>> mascot of the Ironic project?
>>
>> Ahh he also needs a name. So please send some suggestions and we can
>> vote on the best name for him.
>>
>> [1] http://www.youtube.com/watch?v=2Oi2T2pSGDU#t=90
>>
>> Lucas
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0039] Configuring OpenStack deployments to prevent POODLE attacks

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Configuring OpenStack deployments to prevent POODLE attacks
- ---

### Summary ###
POODLE (CVE-2014-3566) is a new attack on SSLv3 that allows an active
network-based attacker to recover the plaintext from a secure connection
using a CBC-mode cipher. Unfortunately, all other cipher modes in SSLv3
are also insecure. Therefore, the recommended solution is to disable
SSLv3. We also discuss an alternative option below. Proper mitigation
requires addressing this issue on SSLv3 clients and servers.


### Affected Services / Software ###
Any service using SSLv3. Depending on the backend SSL library, this
can include many components of an OpenStack cloud:

- - OpenStack services
- - OpenStack clients
- - Web servers (Apache, Nginx, etc)
- - SSL/TLS terminators (Stud, Pound, etc)
- - Proxy services (HAProxy, etc)
- - Miscellaneous services (eventlet, syslog, ldap, smtp, etc)


### Discussion ###
The POODLE attack was first announced on 14 Oct 2014 [1]. For a deeper
technical discussion on POODLE, we refer you to the security advisory
at openssl.org [2] and Daniel Franke's write-up [3]. POODLE affects any
SSL/TLS connection that can be downgraded to SSLv3. This requires both
the client and the server to support SSLv3. Due to the way the protocol
negotiations work, an attacker positioned on the network between the
client and the server can force a downgrade to SSLv3 by selectively
dropping network packets.

The best remediation for POODLE is to disable SSLv3 on all clients and
servers that you control. This will protect you regardless of the
mitigation status on the other end of the connection. An alternative
option is to deploy TLS_FALLBACK_SCSV, which will prevent the downgrade
attack, but could still allow SSLv3 connections if that is the only
supported protocol between the client and server. Any connection that
happens over SSLv3 using a CBC-mode cipher would still be vulnerable.

You can use the OpenSSL s_client tool to test if a server allows SSLv3
connections:

openssl s_client -connect : -ssl3

If the server does not support SSLv3, you will see a handshake failure
message. This indicates that the server does not accept SSLv3
connections. Assuming this server also has SSLv2 disabled, which is a
common default today, then no further configuration is needed. If
the handshake from s_client completes, then the server requires some
configuration. Note that you can perform this step for any service
that has SSL/TLS enabled including OpenStack API endpoints.

Testing clients is slightly more cumbersome because there are likely
many more clients than servers throughout the cloud. However, this
test follows a similar pattern. Using the OpenSSL s_server tool, you
can create an endpoint that only accepts SSLv3:

openssl s_server -cert  -key  -state \
 -ssl3 -no_ssl2 -no_tls1 -no_tls1_1 -no_tls1_2 \
 -tlsextdebug

If the client can connect to this endpoint, the client needs to update
their configuration as described below.


### Recommended Actions ###
We recommend disabling SSLv3 altogether and will provide additional
guidance on how to do this below.

If SSLv3 is still required on your system due to client compatibility
concerns, then TLS_FALLBACK_SCSV is your only choice. In this case you
will need an underlying library that supports TLS_FALLBACK_SCSV (such
as OpenSSL 1.0.1j). Applications using OpenSSL will automatically start
using TLS_FALLBACK_SCSV once OpenSSL is updated. You should perform an
audit in your cloud to verify that all SSL/TLS services do use this
new library:

ldd  | grep ssl

Review the output and ensure that it is linked to the new version of
OpenSSL that includes TLS_FALLBACK_SCSV support.

Disabling SSLv3 can be done at either the application level or the
library level. Doing it at the library level ensures consistency
throughout the cloud. However, if you are not already compiling
OpenSSL then this may not fit into your deployment workflow. In this
case, you must consider each application in turn.

If you are able to recompile your SSL/TLS library, then this is likely
the best option. Disabling SSLv3 at the library level ensures
consistency across the system. For OpenSSL, you can use the "no-ssl3"
build option. Then deploy that library to your cloud and verify that
all SSL/TLS services are using the library using the ldd command
discussed above.

If you are unable to recompile your SSL/TLS library, then you should
reconfigure each application that uses SSL/TLS. Each application has
a different way to handle this configuration. We provide the
configuration option for some of the more common applications below:

Apache:
SSLProtocol All -SSLv2 -SSLv3

Nginx:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Stud:
Requires code change, see [4].
After code change use --tls option.

Pound:
Requires code change, see [5].
After code change use DisableSSLv3 option.

HAProxy (only version 1.5+ supports SSL/TLS):
Depends 

[openstack-dev] [OSSN 0025] Possible Glance image exposure via Swift

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Possible Glance image exposure via Swift
- ---

### Summary ###
Glance is able to use Swift as a back end for storing virtual machine
images. When Glance is configured this way (in multi-tenant mode only),
it is possible for unauthenticated users to access "public" virtual
machine images directly from Swift, even though Glance restricts access
to those images to authenticated users.

### Affected Services / Software ###
Glance, Swift, Havana, Icehouse

### Discussion ###
The 'delay_auth_decision' Swift variable modifies the ACL's to either
require authentication via Keystone or allow unauthenticated access.
When 'delay_auth_decision' is set to '1' the Swift ACL uses a wildcard
(*) to accept all incoming responses.

When Glance is configured for multi-tenant mode, this will allow all
tenants as well as unauthenticated users to have access to the Swift
'public' images.

This can happen when Swift and Glance are configured in the following
fashion:

-  begin example Swift proxy-server.conf snippet 
  delay_auth_decision = 1
-  end example Swift proxy-server.conf snippet 

-  begin example glance-api.conf snippet 
  default_store = swift
  swift_store_multi_tenant = True
  swift_store_create_container_on_put = True
-  end example glance-api.conf snippet 

One way to discover the URL is to take a snapshot of a public image. The
URL for the snapshot combined with the owner ID of the public image will
allow for the Swift URL of the public image to be inferred. This URL
can then be utilized anonymously to download the image.

### Recommended Actions ###
If your Swift and Glance services are configured in such a way that they
are vulnerable, it is recommended that Swift image requests are audited
to determine if an unauthorized image request was made. By default when
images are accessed a message is logged to the Swift log file.

Setting the Swift 'delay_auth_decision' value to '0' (False) will
require Keystone authentication to access the Swift containers, and is
only recommended for environments using Keystone for authentication.

Modifying the Glance configuration to not use Swift in multi-tenant
mode will mitigate the issue, but may introduce other issues depending
on what configuration is used.

Implementing an alternative back end (such as Ceph) will also remove
the issue, however will require additional knowledge on how to securely
install and configure the new object storage service.

The Swift and Glance configuration items are specific to a given
environment, so test configurations before deploying them in a
production environment.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0025
Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1354512
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJURqfDAAoJEJa+6E7Ri+EVcoQH/ApkXEglyX4wYxk/9NQj2m32
aa/OiHlR3+WpUIxFAbEMIKx9vjF+9govJVIUUy4G4Z1OZZDtJ+JpvmVSqyDkgehe
4Y2RRyikmFoZMGlN+99RNwfMxI0Vve6/JmIf4WsAkCIhbxaydd9SUVI0UfnRfC8Z
ObCu76zulSpnpXOlXe1ljoaIRjANGcJXIXey2TY43JLCmZVPyLaTVy/Z76/L/yAi
pKKAQYQ9jrqEtdewAsFbauSk95m6Q0e4x8w6ZwAggmu0yQh+2Zb9ZJaPDnZT3/zi
rs4zTtiu444zG6o2r9G2h/vLCuWfsP8ovSb9nJc8abumV+XOAi4pKeBNdIcIE8U=
=g5o9
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Support for external authentication (i.e. REMOTE_USER) in Havana

[Nathan Kinder]

On 10/18/2014 08:43 AM, lohit.valleru wrote:
> Hello,
> 
> Thank you for posting this issue to openstack-dev. I had posted this on the
> openstack general user list and was waiting for response.
> 
> May i know, if we have any progress regarding this issue.
> 
> I am trying to use external HTTPD authentication with kerberos and LDAP
> identity backend, in Havana.
> 
> I think, few things have changed with Openstack Icehouse release and
> Keystone 0.9.0 on CentOS 6.5.
> 
> Currently I face a similar issue to yours : I get a full username with
> domain as REMOTE_USER from apache, and keystone tries to search LDAP  along
> with my domain name. ( i have not mentioned any domain information to
> keystone. i assume it is called 'default', while my domain is: example.com )
> 
> I see that - External Default and External Domain are no longer supported by
> keystone but intstead - 
> 
> keystone.auth.plugins.external.DefaultDomain or
> external=keystone.auth.plugins.external.Domain are valid as of now.
> 
> I also tried using keystone.auth.plugins.external.kerberos after checking
> the code, but it does not make any difference.
> 
> For example:
> 
> If i authenticate using kerberos with : lohit.vall...@example.com. I see the
> following in the logs.
> 
> DEBUG keystone.common.ldap.core [-] LDAP search:
> dn=ou=People,dc=example,dc=come, scope=1,
> query=(&(uid=lohit.vall...@example.com)(objectClass=posixAccount)),
> attrs=['mail', 'userPassword', 'enabled', 'uid'] search_s
> /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:807
> 2014-10-18 02:34:36.459 5592 DEBUG keystone.common.ldap.core [-] LDAP unbind
> unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:777
> 2014-10-18 02:34:36.460 5592 WARNING keystone.common.wsgi [-] Authorization
> failed. Unable to lookup user lohit.vall...@example.com from 172.31.41.104
> 
> Also, i see that keystone always searches with "uid", no matter what i enter
> as a mapping value for userid/username in keystone.conf . I do not
> understand if this is a bug or limitation. ( The above logs show that they
> are not able to find uid with lohit.vall...@example.com since LDAP contains
> uid without domain name)

Do you have more details on what your mapping is configured like?  There
have been some changes around this area in Juno, but it's still possible
that there is some sort of bug here.
> 
> May i know, how do i request keystone to split REMOTE_USER? Do i need to
> mention default domain and sync with database in order for this to work?

REMOTE_USER is set to the full user principal name, which incudes the
kerberos realm.  Are you using mod_auth_kerb?  If so, you can set the
following in your httpd config to split the realm off of the user principal:

  KrbLocalUserMapping On

> 
> Also, May i know - what modifications do i need to do to Havana to disable
> username and password authentication, but instead use external
> authentication such as Kerberos/REMOTE_USER.
> 
> Is anyone working on these scenarios? or do we have any better solutions?

There is work going on to make Kerberos a more pracitical solution,
including a Kerberos auth plugin for Keystone:

  https://review.openstack.org/123614
> 
> I have read about Federation and Shibboleth authentication, but i believe
> that is not the same as REMOTE_USER/Kerberos authentication.

SAML federation uses REMOTE_USER, but it's quite a bit different than
what you are tryign do do since you still need to look up user
information via LDAP (it's all provided as a part of the SAML assertion
in the federation case).  There are efforts going on in this area, but I
think it's still a release out (Kilo hopefully).

Thanks,
-NGK

> 
> Thank you,
> 
> Lohit
> 
> Thank you,
> 
> Lohit
> 
> 
> 
> 
> --
> View this message in context: 
> http://openstack.10931.n7.nabble.com/keystone-Support-for-external-authentication-i-e-REMOTE-USER-in-Havana-tp22185p55528.html
> Sent from the Developer mailing list archive at Nabble.com.
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] external AuthN Identity Backend

[Nathan Kinder]

On 10/16/2014 12:30 PM, Dave Walker wrote:
> Hi,
> 
> I think I considered the Federated plugin as a mismatch as it dealt
> with 'remote' auth rather than 'external' auth.  I thought it was for
> purely handling SSO / SAML2, and not being subordinate to auth with
> the webserver.
> 
> I'll dig into the federation plugin more, thanks.

There are some plans to be able to frontend the user/group lookup in
httpd like you ca do with external auth.  This is similar to the
federation approach.  I've written up some details here:

  https://blog-nkinder.rhcloud.com/?p=130

There is still work to do to tie in the mapping code from the
OS-FEDERATION extension, but I think the approach shows a lot of
promise.  Choose your auth module (mod_auth_kerb, mod_ssl, etc.) to set
REMOTE_USER, then use mod_lookup_identity to supply the user/group info
from LDAP.  This is an approach that should get some discussion time at
the Summit.

Thanks,
-NGK

> 
> --
> Kind Regards,
> Dave Walker
> 
> On 16 October 2014 19:58, David Chadwick  wrote:
>> Dave
>>
>> when federation is used, the user's group is stored in a mapping rule.
>> So we do have a mechanism for storing group memberships without using
>> LDAP or creating an entry for the user in the SQL backend. (The only
>> time this is kinda not true is if we have a specific rule for each
>> federated user, so that then each mapping rule is equivalent to an entry
>> for each user). But usually we might expect many users to use the same
>> mapping rule.
>>
>> Mapping rules should be usable for Kerberos logins. I dont know if the
>> current code does have this ability or not, but if it doesn't, then it
>> should be re-engineered to. (it was always in my design that all remote
>> logins should have a mapping capability)
>>
>> regards
>>
>> David
>>
>> On 16/10/2014 19:15, Dave Walker wrote:
>>> Hi,
>>>
>>> Currently we have two ways of doing Identity Auth backends, these are
>>> sql and ldap.
>>>
>>> The SQL backend is the default and is for situations where Keyston is
>>> the canonical Identity provider with username / password being
>>> directly compared to the Keystone database.
>>>
>>> LDAP is the current option if Keystone isn't the canonical Identity
>>> provider and passes the username and password to an LDAP server for
>>> comparison and retrieves the groups.
>>>
>>> For a few releases we have supported External auth (or Kerberos),
>>> where we authenticate the user at the edge and trust the REMOTE_USER
>>> is valid.  In these situations Keystone doesn't require the Username
>>> or Password to be valid.
>>>
>>> Particularly in Kerberos situations, no password is used to
>>> successfully authenticate at the edge.  This works well, but LDAP
>>> cannot be used as no password is passed through.  The other option is
>>> SQL, but that then requires a user to be created in Keystone first.
>>>
>>> We do not seem to cover the situation where Identity is provided by an
>>> external mechanism.  The only system currently available is Federation
>>> via SAML, which isn't always the best fit.
>>>
>>> Therefore, I'd like to suggest the introduction of a third backend.
>>> This would be the external identity provider.  This would seem to be
>>> pretty simple, as the current checks would simply return success (as
>>> we trust auth at the edge), and not store user_id in the database, but
>>> generate it at runtime.
>>>
>>> The issue I have, is that this doesn't cover Group membership.
>>>
>>> So, am I a:
>>>  - Barking totally up the wrong tree
>>>  - Add support to the current LDAP plugin to support external auth
>>> (but still use LDAP for groups)
>>>  - Write a standalone external plugin, but then do what for Groups?  I
>>> would be reasonably happy to just have 1:1 mapping of users to groups.
>>>
>>> Does this make sense?
>>>
>>> Thanks
>>>
>>> --
>>> Kind Regards,
>>> Daviey Walker
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][policy][keystone] Better Policy Model and Representing Capabilites

[Nathan Kinder]

On 10/14/2014 07:42 AM, Tim Hinrichs wrote:
> First, some truth in advertising: I work on Congress (policy as a service), 
> so I’ve mostly given thought to this problem in that context.
> 
> 1) I agree with the discussion below about creating a token that encodes all 
> the permitted actions for the user.  The cons seem substantial.  

+1

> 
> (i) The token will get stale, requiring us to either revoke it when 
> policy/roles change or to live with incorrect access control enforcement 
> until the token expires.

This is a very good point.

> 
> (ii) The token could become large, complex, or both.  Suppose the policy is 
> granular enough to put restrictions on the arguments a user is permitted to 
> provide to an action.  The token might end up encoding a significant portion 
> of the policy itself.  Checking if the token permits a given action could be 
> similar computationally to checking the original policy.json file.  
> 
> 
> 2) I like the idea of an out-of-band service that caches a copy of all the 
> policy.jsons and allows users to interrogate/edit them.  I’ve definitely 
> talked to operators who would like this kind of thing.  This would be a 
> low-risk, low-friction solution to the problem because nothing about 
> OpenStack today would need to change.  We’d just add an extra service and 
> tell people to use it—sort of a new UI for the policy.json files.  And we 
> could add interesting functionality, e.g. hypothetical queries such as “if I 
> were to add role X, what changes would that make in my rights?"
> 
> Perhaps some more context about why users want to know all of the actions 
> they are permitted to execute might help.

I think that there are two questions that a user may have here:

1) What actions can I perform using a particular token?

2) What role(s) do I need to perform a particular action?

For me, the second question is more interesting.  A user likely already
has an idea of a task that they want to perform.  With question number
1, what do I do as a user if the response says that I'm not allowed to
perform the task I'm trying to accomplish?  The answer really doesn't
give me a way to move forward and perform my task.

With question 2, I'm able to find out what exact roles are needed to
perform a specific action.  With this information, I could request a
Keystone token with a subset of my roles that is authorized to perform
the task while leaving out roles that might have a higher level of
authorization.  For instance, why should I need to send a token with the
'admin' role to Nova just to launch an instance if '_member_' is all
that's required?

Another real use case is determining what roles are needed when creating
a trust in Keystone.  If I want to use a trust to allow a service like
Heat or Neutron's LBaaS to perform an action on my behalf, I want to
minimize the authorization that I'm delegating to those services.
Keystone trusts already have the ability to explicitly define the roles
that will be present in the issues trust tokens, but I have no way of
knowing what roles are required to perform a particular action without
consulting the policy.

-NGK

> 
> Tim
> 
> 
>  
> On Oct 14, 2014, at 1:56 AM, David Chadwick  wrote:
> 
>>
>>
>> On 14/10/2014 01:25, Nathan Kinder wrote:
>>>
>>>
>>> On 10/13/2014 01:17 PM, Morgan Fainberg wrote:
>>>> Description of the problem: Without attempting an action on an
>>>> endpoint with a current scoped token, it is impossible to know what
>>>> actions are available to a user.
>>>>
>>
>> This is not unusual in the physical world. If you think about all the
>> authz tokens you carry around in your pocket (as plastic cards), very
>> few of them (if any) list what you are entitled to do with them. This
>> gives the issuers and SPs flexibility to dynamically change your
>> accesses rights without changing your authorisation. What you can do, in
>> general terms, may be written in policy documents that you can consult
>> if you wish. So you may wish to introduce a service that is equivalent
>> to this (i.e. user may optionally consult some policy advice service).
>>
>> If you introduce a service to allow a user to dynamically determine his
>> access rights (absolutely), you have to decide what to do about the
>> dynamics of this service compared to the lifetime of the keystone token,
>> as the rights may change more quickly than the token's lifetime.
>>
>>>>
>>>> Horizon makes some attempts to solve this issue by sourcing all of
>>>> the policy files from all of the services to determine what a user
>>>> can accomplish with a given role. T

Re: [openstack-dev] [all][policy][keystone] Better Policy Model and Representing Capabilites

[Nathan Kinder]

On 10/13/2014 01:17 PM, Morgan Fainberg wrote:
> Description of the problem: Without attempting an action on an endpoint with 
> a current scoped token, it is impossible to know what actions are available 
> to a user.
> 
> 
> Horizon makes some attempts to solve this issue by sourcing all of the policy 
> files from all of the services to determine what a user can accomplish with a 
> given role. This is highly inefficient as it requires processing the various 
> policy.json files for each request in multiple places and presents a 
> mechanism that is not really scalable to understand what a user can do with 
> the current authorization. Horizon may not be the only service that (in the 
> long term) would want to know what actions a token can take.

This is also extremely useful for being able to actually support more
restricted tokens as well.  If I as an end user want to request a token
that only has the roles required to perform a particular action, I'm
going to need to have a way of knowing what those roles are.  I think
that is one of the main things missing to allow the "role-filtered
tokens" option that I wrote up after the last Summit to be a viable
approach:

  https://blog-nkinder.rhcloud.com/?p=101

> 
> I would like to start a discussion on how we should improve our policy 
> implementation (OpenStack wide) to help make it easier to know what is 
> possible with a current authorization context (Keystone token). The key 
> feature should be that whatever the implementation is, it doesn’t require 
> another round-trip to a third party service to “enforce” the policy which 
> avoids another scaling point like UUID Keystone token validation.
> 
> Here are a couple of ideas that we’ve discussed over the last few development 
> cycles (and none of this changes the requirements to manage scope of 
> authorization, e.g. project, domain, trust, ...):
> 
> 1. Keystone is the holder of all policy files. Each service gets it’s policy 
> file from Keystone and it is possible to validate the policy (by any other 
> service) against a token provided they get the relevant policy file from the 
> authoritative source (Keystone).
> 
> Pros: This is nearly completely compatible with the current policy system. 
> The biggest change is that policy files are published to Keystone instead of 
> to a local file on disk. This also could open the door to having keystone 
> build “stacked” policies (user/project/domain/endpoint/service specific) 
> where the deployer could layer policy definitions (layering would allow for 
> stricter enforcement at more specific levels, e.g. users from project X can’t 
> terminate any VMs).

I think that there are a some additional advantages to centralizing
policy storage (not enforcement).

- The ability to centralize management of policy would be very nice.  If
I want to update the policy for all of my compute nodes, I can do it in
one location without the need for external configuration management
solutions.

- We could piggy-back on Keystone's signing capabilities to allow policy
to be signed, providing protection against policy tampering on an
individual endpoint.

> 
> Cons: This doesn’t ease up the processing requirement or the need to hold 
> (potentially) a significant number of policy files for each service that 
> wants to evaluate what actions a token can do.

Are you thinking of there being a call to keystone that answers "what
can I do with token A against endpoint B"?  This seems similar in
concept to the LDAP "get effective rights" control.  There would
definitely be some processing overhead to this though you could set up
multiple keystone instances and replicate the policy to spread out the
load.  It also might be possible to index the enforcement points by role
in an attempt to minimize the processing for this sort of call.

> 
> 
> 2. Each enforcement point in a service is turned into an attribute/role, and 
> the token contains all of the information on what a user can do (effectively 
> shipping the entire policy information with the token).
> 
> Pros: It is trivial to know what a token provides access to: the token would 
> contain something like `{“nova”: [“terminate”, “boot”], “keystone”: 
> [“create_user”, “update_user”], ...}`. It would be easily possible to allow 
> glance “get image” nova “boot” capability instead of needing to know the 
> roles for policy.json for both glance and nova work for booting a new VM.
> 
> Cons: This would likely require a central registry of all the actions that 
> could be taken (something akin to an IANA port list). Without a grouping to 
> apply these authorizations to a user (e.g. keystone_admin would convey 
> “create_project, delete_project, update_project, create_user, delete_user, 
> update_user, ...”) this becomes unwieldy. The “roles” or “attribute” that 
> convey capabilities are also relatively static instead of highly dynamic as 
> they are today. This could also contribute to token-bloat.

I think we really want

[openstack-dev] [OSSN 0028] Nova leaks compute host SMBIOS serial number to guests

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nova leaks compute host SMBIOS serial number to guests
- ---

### Summary ###
When Nova is using the libvirt virtualization driver, the SMBIOS
serial number supplied by libvirt is provided to the guest instances
that are running on a compute node. This serial number may expose
sensitive information about the underlying compute node hardware.

### Affected Services / Software ###
Nova, Icehouse, Havana

### Discussion ###
The 'serial' field in guest SMBIOS tables gets populated based on the
libvirt reported UUID of the host hardware. The rationale is to allow
correlation of guests running on the same host.

Unfortunately some hardware vendors use a subset of the host UUID as a
key for retrieving hardware support contract information without
requiring any authentication. In these cases, exposing the host UUID to
the guest is an information leak for those vendors.

The exposed host UUID could theoretically be leveraged by a cloud user
to get an approximate count of the number of unique hosts available to
them in the cloud by launching many short lived VMs.

### Recommended Actions ###
It is possible to override the use of the compute node's SMBIOS data by
libvirt in /etc/libvirt/libvirtd.conf by setting the 'host_uuid'
parameter. This allows setting an arbitrary UUID for identification
purposes that doesn't leak any information about the real underlying
hardware.  It is advised to make use of this override ability to prevent
potential exposure of information about the underlying compute node
hardware.

In the Juno release of OpenStack, Nova's libvirt driver allows the
source of the host UUID to be controlled via a new 'sysinfo_serial'
config parameter. This new parameter allows the following values:

  - 'auto' - try /etc/machine-id, fallback to libvirt reported
 host UUID (new default)
  - 'hardware' - always use libvirt host UUID (old default)
  - 'os' - always use /etc/machine-id, error if missing
  - 'none' - do not report any value to the guest

In general, it is preferrable to use the /etc/machine-id UUID instead
of the host hardware UUID. The former is a recent standard for Linux
distros introduced by systemd to provide a UUID that is unique per
operating system install. This means that even containers will see a
separate /etc/machine-id value. This /etc/machine-id can be expected to
be widely available in current and future distros. If this file is
missing, it is still possible to fallback to the libvirt reported host
UUID.

Administrators concerned about exposing the ability to identity an
underlying compute node by it's serial number may wish to disable
reporting of any sysinfo serial field at all by using the 'none' value.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0028
Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1337349
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJULvb7AAoJEJa+6E7Ri+EVJeUH/01GXn1cV7RHqzh1z9ybsJnY
4Cw5OYzjsSOjmkC1t4Y5llx0aSYCpF3CGdXUaN/fOIpn/yqcbzbq4lXt6rLWW4NI
k9NFgOxbqQKFhKUQ6HQZ8jaIhZm2FLzxk+9eV73DlE5kZ8y8o9T/IkmZbRFeWsx2
uzPTQy9P2BJ95XnpoKcsUJBY/3M+8++f6xRj0sU66KZNSjW7xN7MnalrRtwRxIcD
uugXv3iQ+e2ijXZvERw4NQonzSD+fcxBICxW0lUJrejnDn9ZfcJ4MmOGRYuN9sRC
Fr4lstLvBNLlyJ05JD9apusWFNdtbEp/c6gchwCGFZjmvPMXmkQCRMRrNr+H5hw=
=JjnC
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OSSN 0029] Neutron FWaaS rules lack port restrictions when using protocol 'any'

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

An update for this Security Note has been published to clarify that
Neutron's FWaaS extension is still experimental.  The updated version
of OSSN-0029 is available here:

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

Thanks,
- -NGK


On 09/24/2014 09:58 AM, Nathan Kinder wrote:
> Neutron FWaaS rules lack port restrictions when using protocol
> 'any' ---
> 
> ### Summary ### A bug in the Neutron FWaaS (Firewall as a Service)
> code results in iptables rules being generated that do not reflect
> desired port restrictions. This behaviour is triggered when a
> protocol other than 'udp' or 'tcp' is specified, e.g. 'any'.
> 
> The scope of this bug is limited to Neutron FWaaS and systems built
> upon it. Security Groups are not affected.
> 
> ### Affected Services / Software ### Neutron FWaaS, Grizzly,
> Havana, Icehouse
> 
> ### Discussion ### When specifying firewall rules using Neutron
> that should match multiple protocols, it is convenient to specify a
> protocol of 'any' in place of defining multiple specific rules.
> 
> For example, in order to allow DNS (TCP and UDP) requests, the
> following rule might be defined:
> 
> neutron firewall-rule-create --protocol any --destination-port 53
> \ --action allow
> 
> However, this rule results in the generation of iptables firewall
> rules that do not reflect the desired port restriction. An example
> generated iptables rule might look like the following:
> 
> -A neutron-l3-agent-iv441c58eb2 -j ACCEPT
> 
> Note that the restriction on port 53 is missing. As a result, the 
> generated rule will match and accept any traffic being processed by
> the rule chain to which it belongs.
> 
> Additionally, iptables arranges sets of rules into chains and
> processes packets entering a chain one rule at a time. Rule
> matching stops at the first matched exit condition (e.g. accept or
> drop). Since, the generated rule above will match and accept all
> packets, it will effectively short circuit any filtering rules
> lower down in the chain. Consequently, this can break other
> firewall rules regardless of the protocol specified when defining
> those rules with Neutron. They simply need to appear later in the
> generated iptables rule chain.
> 
> This bug is triggered when any protocol other than 'tcp' or 'udp'
> is specified in conjunction with a source or destination port
> number.
> 
> ### Recommended Actions ### Avoid the use of 'any' when specifying
> the protocol for Neutron FWaaS rules. Instead, create multiple
> rules for both 'tcp' and 'udp' protocols independently.
> 
> A fix has been submitted to Juno.
> 
> ### Contacts / References ### This OSSN :
> https://wiki.openstack.org/wiki/OSSN/OSSN-0029 Original LaunchPad
> Bug : https://bugs.launchpad.net/neutron/+bug/1365961 OpenStack
> Security ML : openstack-secur...@lists.openstack.org OpenStack
> Security Group : https://launchpad.net/~openstack-ossg
> 
> ___ OpenStack-dev
> mailing list OpenStack-dev@lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUKbWMAAoJEJa+6E7Ri+EVhn4H/3i6o52SNZQsE6eofCWJag1h
GK4rECMuCw1TTe1a8mT0zrA9vigxZFlnpjfb/mXfFprQG4365VuqxxOFN1gimN+Q
xG8oFrm32RhEGi45FAbJr5g00LbemfNCVrJO+GJMSRjv3WykClwXz2HN13OAvejO
KkTaTeLKJQoPjLP1qeAb0Ihce8wR+pgAE+2g0MuaWBbZUIVZXK5CVvfU6NpBzat7
QoFLI9G+mUAHN8faGm15NvslkH+s5wzm9PDhE0ASOUzjKcaSFgLBcNiMTG2dCvjX
7SLrsYQErQop3LwQOpVlfnmhgTA96m5QsN3DaF1RAeAKSf7WU2yeYSujGtBdpes=
=tPf/
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0030] Bash 'shellshock' bug can lead to code injection vulnerability

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bash 'shellshock' bug can lead to code injection vulnerability
- ---

### Summary ###
A bug in the GNU Bash shell (4.3 and lower) exposes a code injection
vulnerability via crafted environment variables (Shellshock,
CVE-2014-6271, CVE-2014-7169). Through network utilities such as SSH and
CGI enabled web servers, this vulnerability can become remotely
exploitable. Bash is universal to nearly all Linux distributions as well
as Apple OS X.

### Affected Services / Software ###
GNU Bash, Grizzly, Havana, Icehouse

### Discussion ###
The GNU Bash shell (4.3 and lower) is vulnerable to a code injection
attack via the setting of environment variables. This stems from a bug
in the way bash processes function definitions present in the
environment, an example might look like the following:

  env x='() { :;}; echo vulnerable' bash -c 'echo hello'

when executed, this command line will print:

  vulnerable
  hello

This behaviour occurs because bash continues to process the rest of the
variable string after the function definition, the name of the variable
is also unimportant.

Many programs on a Linux installation will 'shell out' to launch helper
commands. If a malicious user can set an environment variable in the
spawned shell they can execute arbitrary commands with the same user
permissions as the legitimate command. If these programs are network
connected then this vulnerability becomes remotely exploitable. To
illustrate how this might be accomplished, consider the OpenSSH forced
command mechanism. This mechanism allows commands run via SSH to be
restricted to a specific invocation, however OpenSSH will set an
environment variable 'SSH_ORIGINAL_COMMAND' to the command that was
requested by the user before executing the forced command. If
'SSH_ORIGINAL_COMMAND' contains a function definition of the form given
above, then this will be executed by bash regardless of the forced
command specified.

Note that there are many remotely accessible programs that may set one
or more environment variables before spawning a bash sub-processes,
known examples include but are not limited to:

- - CGI Enabled web servers (Apache mod_cgi, nginx, etc)
- - SSH (OpenSSH mechanisms as above)
- - DHCP (dhcpcd)

OpenStack software itself is not currently understood to be
directly affected, however deployments of OpenStack will very likely
be using GNU Bash in many places. While employed mechanisms such as
rootwrap filter environment variables, any variable that can be set via
user provided input becomes a potential security issue.

### Recommended Actions ###
Owing to the ubiquitous nature of the bash shell and its indirect use
via other programs it is highly recommended that all systems, guests and
virtual machine images update to a patched version of bash immediately.
Refer to guidance from the provider of your specific Linux distribution
for additional details.

Additionally, network filtering and IDS systems should be configured to
detect incoming requests containing bash function-like definitions.
System logs should also be interrogated for any such strings as an
indication of possible attacks.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0030
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1374055
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
Initial CVE:
  http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
Secondary CVE:
  http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUJcuYAAoJEJa+6E7Ri+EVxlwIAIsBE3MrgOFF9ZGnjTlDAiIy
VDMuj2APqn4N49cvWXURxa6R+TBYZ+lOeLH/ectgtg4UH8yDmoj5BP19beWZ0HFK
Wq/3go5GIaa60EDGIYlMJYNlDAfgDNlzKAZ0km0nICepR8l9vrd21BqN195LDfnY
ane3KjnpO9+yy30c2UGNvq9YydPWlqjO00wFEoOVKePnf8Z+0fyDgHKssxDX57dK
0UZTAMMgoXBS780mECVVuGMoCMYCKicYcJgx5ZMg610yu9QIdEC54A1qsQVYJBA3
Fi6FAeSje1ipVXsi5C/ME93emNurDR6z6MvLeM/1a/NH6QEV8i9U5++KoZrNQWg=
=Q+FJ
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0024] Sensitive data is exposed in log statements by python-keystoneclient

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sensitive data is exposed in log statements by python-keystoneclient
- ---

### Summary ###
Python-keystoneclient is a client tool for the OpenStack Identity API,
which is implemented by the Keystone project. Various OpenStack services
including the OpenStack Dashboard depend on python-keystoneclient to
consume the OpenStack Identity API service. A particular log level
setting in python-keystoneclient can lead to exposure of user sensitive
data (e.g., passwords or tokens) in log statements.

### Affected Services / Software ###
Python-keystoneclient=<0.10.0

### Discussion ###
Python-keystoneclient provides an interface for making Identity API
requests to the OpenStack Identity Service, Keystone.
Python-keystoneclient handles user sensitive data such as user passwords
and tokens when sending requests or receiving responses from a Keystone
server. Like all OpenStack projects, python-keystoneclient uses a python
logger to log request/response activities. When python-keystoneclient
runs with the DEBUG log level enabled, sensitive data such as user
passwords and tokens associated with requests/responses will be exposed
in log statements. For example:

-  begin example 
$ keystone --debug user-list
DEBUG:keystoneclient.session:REQ: curl -i -X POST
http://10.0.0.15:5000/v2.0/tokens -H "Content-Type:application/json"
-H "User-Agent: python-keystoneclient"
DEBUG:keystoneclient.session:REQ BODY: {"auth": {"tenantName": "admin",
"passwordCredentials": {"username": "admin", "password": "stack"
}}}
-  end example 

This sensitive data can potentially be exploited by an attacker with
access to the log statements.

Python-keystoneclient is used by Horizon and other Identity consuming
services to authenticate a user against the Identity API service,
Keystone. A user providing password or token for authentication to these
services could result in the capture of this sensitive data in the
respective services log statements.

### Recommended Actions ###
Version 0.10.1 of python-keystoneclient has addressed this issue by not
exposing user password and token information in log statements. Any
service using version 0.10.1 or later of python-keystoneclient is not
affected by this issue. Other services using old versions, should
upgrade to a fixed version of python-keystoneclient.

For a fresh installation of a service which depends on
pythone-keystoneclient, make sure it uses at least version 0.10.1 of
python-keystoneclient. One way to do this is to set a specific version
in the requirments.txt file. For example, in Horizon, update
horizon/requirements.txt file:

-  begin example 
python-keystoneclient>=0.10.1
-  end example 

For existing installations, upgrade python-keystoneclient to the
latest version. For example, python package manager (PIP) can be used
to upgrade the existing installations.

-  begin example 
$ pip install python-keystoneclient --upgrade
-  end example 

An alternate approach is to never run a production system with the log
level in DEBUG mode.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0024
Original Launchpad Bug:
https://bugs.launchpad.net/python-keystoneclient/+bug/1004114
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1004114
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUJM6iAAoJEJa+6E7Ri+EVnjYH+QEZ3xbe2ySu4Mf0jboLkpeb
HnKcXgC8FbL3f70fkFn054d7jnxqdN8qsFaXpxSwOpKBvg+IPxv/l7aC0foIiVUu
uH4cLC/ZUNJkbxp8eCZBH82E7KzhwUa/Eg/uvK6u/F2ilIlUTC5zfsgzE3wZh8q4
OGZ09YXwnT+d9lWwoK/DNoOlQVK+kQO11UpT+kdtgjtGgcR+DjGy7NFE9w5z8/jz
nk6APdZwFW9JAVbSVJg3jblIpUhtue5fkmZLP9u+AE9c7V1U/6/w5EaAoOQEnTkZ
BbnT65dS8Em6+zWk/+yvRQB+F2K5rs7RAw+sUDTszD86ntpBqn+CwY8AySJbNaY=
=QXYy
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0029] Neutron FWaaS rules lack port restrictions when using protocol 'any'

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Neutron FWaaS rules lack port restrictions when using protocol 'any'
- ---

### Summary ###
A bug in the Neutron FWaaS (Firewall as a Service) code results in
iptables rules being generated that do not reflect desired port
restrictions. This behaviour is triggered when a protocol other than
'udp' or 'tcp' is specified, e.g. 'any'.

The scope of this bug is limited to Neutron FWaaS and systems built upon
it. Security Groups are not affected.

### Affected Services / Software ###
Neutron FWaaS, Grizzly, Havana, Icehouse

### Discussion ###
When specifying firewall rules using Neutron that should match multiple
protocols, it is convenient to specify a protocol of 'any' in place of
defining multiple specific rules.

For example, in order to allow DNS (TCP and UDP) requests, the following
rule might be defined:

neutron firewall-rule-create --protocol any --destination-port 53 \
--action allow

However, this rule results in the generation of iptables firewall rules
that do not reflect the desired port restriction. An example generated
iptables rule might look like the following:

- -A neutron-l3-agent-iv441c58eb2 -j ACCEPT

Note that the restriction on port 53 is missing. As a result, the
generated rule will match and accept any traffic being processed by the
rule chain to which it belongs.

Additionally, iptables arranges sets of rules into chains and processes
packets entering a chain one rule at a time. Rule matching stops at the
first matched exit condition (e.g. accept or drop). Since, the generated
rule above will match and accept all packets, it will effectively short
circuit any filtering rules lower down in the chain. Consequently, this
can break other firewall rules regardless of the protocol specified when
defining those rules with Neutron. They simply need to appear later in
the generated iptables rule chain.

This bug is triggered when any protocol other than 'tcp' or 'udp' is
specified in conjunction with a source or destination port number.

### Recommended Actions ###
Avoid the use of 'any' when specifying the protocol for Neutron FWaaS
rules. Instead, create multiple rules for both 'tcp' and 'udp' protocols
independently.

A fix has been submitted to Juno.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0029
Original LaunchPad Bug : https://bugs.launchpad.net/neutron/+bug/1365961
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUIvg/AAoJEJa+6E7Ri+EV9bUH/RLDncR7tUCdz6jxDBECj/Uq
wGshhd0YiLaOIJ57tHQNNQedUSNOe0ErPgpSHQifb5nLYE5JvR+YK1QS3n+aM8vL
1teVJDpHU6hoJBmLD8MfB2ZodikSDT/Lfjm3SemfgVtAjHwKEzUE1vGWsq5z+8KB
I8HDffLQjPPbzgxhS0wwCoLouwP07trodg01j93uON6PwMnY4+8eRquiCpr8/dva
aqjT1eKuaTvfDKnXhiVcXDACH1uKKEgmeHKcqLYNKut8n/8F4WOSigAzwGlCDpre
9lpuTWpfIDDR6mDFgrrlanhdyQzo7SV9jupKvYnWHVr72x+E4OCSHtVXq7BLiVw=
=2m+Z
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0027] Neutron ARP cache poisoning vulnerability

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Neutron ARP cache poisoning vulnerability
- ---

### Summary ###
The Neutron firewall driver 'iptables_firewall' does not prevent ARP
cache poisoning, as this driver is currently only capable of MAC address
and IP address based anti-spoofing rules. However, ARP filtering
functionality is available in Nova Networking.

### Affected Services / Software ###
Neutron, Grizzly, Havana, Icehouse, Juno

### Discussion ###
In deployments using Nova Networking, the following anti-spoofing rules
are available through the libvirt network filter feature:

- - no-mac-spoofing
- - no-ip-spoofing
- - no-arp-spoofing
- - nova-no-nd-reflection
- - allow-dhcp-server

However, in deployments using Neutron, the 'iptables_firewall' driver
handles only MAC and IP anti-spoofing rules, leaving it vulnerable to
ARP poisoning and associated attacks. This feature disparity is a
security vulnerability, especially on networks shared with other tenants
or services.

ARP poisoning can lead to denial of service attacks as well as man in
the middle attacks that can compromise tenant separation on shared
networks. A malicious host on the shared network can send crafted ARP
packets designed to manipulate the ARP table of another host on the same
network. This manipulation can be engineered such that the malicious
host will receive traffic from the target host in place of the network
gateway. The malicious host has a number of options once traffic has
been intercepted. It may interrogate it for sensitive information,
manipulate if before passing it on to the real gateway, or drop it to
create a denial of service attack.

This can be demonstrated as follows:

- - Create a private network/subnet 10.0.0.0/24
- - Start 2 VMs attached to that private network:
  VM1 IP 10.0.0.3, VM2 IP 10.0.0.4
- - Log on to VM1 and install the ettercap tool (see references)
- - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output' on
  VM1. This will cause traffic from VM2 to pass through VM1 before it is
  forwarded on to the gateway.
- - Log on to VM2 and ping any valid internet site, the ping should
  succeed.
- - The ICMP traffic generated by VM2's ping will be visible on VM1.
- - Checking the ARP table on VM2 will show that the MAC address
  associated with the gateway is the MAC address of VM1.

This technique can be used to cause a denial of service attack if VM1
drops packets from VM2 rather than forwarding them on to the gateway.

### Recommended Actions ###
Pay close attention to networks where Neutron-based VLANs are in use.
Install appropriate IDS and traffic monitoring tools with a particular
focus on ARP packet monitoring.

The Neutron development team plan to address this issue in a future
version

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0027
Original LaunchPad Bug : https://bugs.launchpad.net/neutron/+bug/1274034
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
Ettercap: http://ettercap.github.io/ettercap
ARP Poisoning: http://en.wikipedia.org/wiki/ARP_spoofing
   http://www.watchguard.com/infocenter/editorial/135324.asp
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUGGHcAAoJEJa+6E7Ri+EVUpQIAJRVI3GjI/PpAz3fGGOGbIWo
YoYM25S8sprI45aWeJZq2t7d9fHK3vY1Tub6E2gOFqT1iHn1/X/kNBiiZ+D5BfTw
/hwRTR7VG0QousvpoR+OZgnDZ8Ub3OiW2WH5km4tHiV+pMBIW/ktux4yA/NsgG04
01iKXnVcVkTDI5LuPrICfFFWgnlEr18f+bfLqKeQz+TGaLtqBavZSniTcuuFct6h
Dn6bU8zjoGXoCq/5LTU/fxQnnHk3+vf5UoKP+SfEpCZeJs3Drzdc/W/YfhS01o1b
K2tZduPDAX2jKQxi3WYqpq+9Aae5U0AiRHZl08zozGuVhCcGezTkFG81y2c3QBE=
=A7BJ
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [clients] [keystone] lack of retrying tokens leads to overall OpenStack fragility

[Nathan Kinder]

On 09/12/2014 12:46 AM, Angus Lees wrote:
> On Thu, 11 Sep 2014 03:21:52 PM Steven Hardy wrote:
>> On Wed, Sep 10, 2014 at 08:46:45PM -0400, Jamie Lennox wrote:
>>> For service to service communication there are two types.
>>> 1) using the user's token like nova->cinder. If this token expires there
>>> is really nothing that nova can do except raise 401 and make the client
>>> do it again. 2) using a service user like nova->neutron. This should
>>> allow automatic reauthentication and will be fixed/standardied by
>>> sessions.
>> (1) is the problem I'm trying to solve in bug #1306294, and (for Heat at
>> least) there seems to be two solutions, neither of which I particularly
>> like:
>>
>> - Require username/password to be passed into the service (something we've
>>   been trying to banish via migrating to trusts for deferred
>>   authentication)
>> - Create a trust, and impersonate the user for the duration of the request,
>>   or after the token expires until it is completed, using the service user
>>   credentials and the trust_id.
>>
>> It's the second one which I'm deliberating over - technically it will work,
>> and we create the trust anyway (e.g for later use to do autoscaling etc),
>> but can anyone from the keystone team comment on the legitimacy of the
>> approach?
>>
>> Intuitively it seems wrong, but I can't see any other way if we want to
>> support token-only auth and cope with folks doing stuff which takes 2 hours
>> with a 1 hour token expiry?
> 
> A possible 3rd option is some sort of longer lived, but limited scope 
> "capability token".
> 
> The user would create a capability token that represents "anyone possessing 
> this token is (eg) allowed to write to swift as $user".  The token could be 
> created by keystone as a trusted 3rd party or by swift (doesn't matter 
> which), 
> in response to a request authenticated as $user.  The client then includes 
> that token in the request *to cinder*, so cinder can pass it back to swift 
> when doing the writes.
> This capability token would be of much longer duration (long enough to 
> complete the cinder->swift task), which is ok because it is of a much more 
> limited scope (ideally as fine grained as we can bother implementing).

With UUID tokens, it would even be possible to implement a "one-time
use" sort of token.  Since Keystone needs to be asked to validate a UUID
token, the token could be invalidated by Keystone after the first
verification.  Since the token is limited based off of number of times
of usage, there should be less concerns about a long validity period
(though it would make sense to use something sane still).  This approach
wouldn't be possible with PKI tokens since Keystone is not in the
validation path.

Your idea of passing the "capability token" in the request would work
well with this, as the token only needs to be extracted and used once
instead of being passed from service to service and validated at each
hop (user>cinder->swift in your example).

The idea would be to leave normal tokens with a smaller validity period
(like the current default of an hour), but also allow one-time use
tokens to be requested.

> 
> (I like this option)
> 
> 
> A 4th option is to have much longer lived tokens everywhere (long enough for 
> this backup), but the user is able to expire it early via keystone whenever 
> they feel it might be compromised (aiui this is exactly how things work now - 
> we just need to increase the timeout).  Greater exposure to replay attacks, 
> but if detected they can still be invalidated quickly.
> 
> (This is the easiest option, it's basically just formalising what the 
> operators are already doing)
> 
> 
> A 5th option (wow) is to have the end user/client repeatedly push in fresh 
> tokens during long-running operations (and heat is the uber-example since it 
> basically wants to impersonate the user forever).  Those tokens would then 
> need to be refreshed all the way down the stack for any outstanding 
> operations 
> that might need the new token.
> 
> (This or the 4th option seems ugly but unavoidable for "forever" services 
> like 
> heat.  There has to be some way to invalidate their access if they go rogue, 
> either by time (and thus needs a refresh mechanism) or by invalidation-via-
> keystone (which implies the token lasts forever unless invalidated))

I think Keystone trusts are better for "forever" services, though I see
no reason why a trust token also couldn't have a limited number of uses
with a longer validity period.  The trust itself doesn't need an
expiration, so the trust can be executed at some future point in time to
get a limited use trust token.

> 
> 
> However we do it:  the "permission" to do the action should come from the 
> original user - and this is expressed as tokens coming from the original 
> client/user in some form.   By allowing services to create something without 
> the original client/user being involved, we're really just bypassing the 
> token 
> authen

[openstack-dev] [OSSN 0020] Disassociating floating IPs does not terminate NAT connections with Neutron L3 agent

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Disassociating floating IPs does not terminate NAT connections with
Neutron L3 agent
- ---

### Summary ###
Every virtual instance is automatically assigned a private IP address.
You may optionally assign public IP addresses to instances. OpenStack
uses the term "floating IP" to refer to an IP address (typically
public) that can be dynamically added to a running virtual instance.
The Neutron L3 agent uses Network Address Translation (NAT) to assign
floating IPs to virtual instances. Floating IPs can be dynamically
released from a running virtual instance but any active connections are
not terminated with this release as expected when using the Neutron L3
agent.

### Affected Services / Software ###
Neutron, Icehouse, Havana, Grizzly, Folsom

### Discussion ###
When creating a virtual instance, a floating IP address is not
allocated by default. After a virtual instance is created, a user can
explicitly associate a floating IP address to that instance. Users can
create connections to the virtual instance using this floating IP
address. Also, this floating IP address can be disassociated from any
running instance without shutting that instance down.

If a user initiates a connection using the floating IP address, this
connection remains alive and accessible even after the floating IP
address is released from that instance. This potentially violates
restrictive policies which are only being applied to new connections.
These policies are ignored for pre-existing connections and the virtual
instance remains accessible from the public network.

This issue is only known to affect Neutron when using the L3 agent.
Nova networking is not affected.

### Recommended Actions ###
There is unfortunately no easy way to detect which connections were
made over a floating IP address from a virtual instance, as the NAT is
performed at the Neutron router. The only safe way of terminating all
connections made over a floating IP address is to terminate the virtual
instance itself.

The following recommendations should be followed when using the Neutron
L3 agent:

- - Only attach a floating IP address to a virtual instance when that
instance should be accessible from networks outside the cloud.
- - Terminate or stop the instance along with disassociating the floating
IP address to ensure that all connections are closed.

The Neutron development team plans to address this issue in a future
version of Neutron.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0020
Original LaunchPad Bug : https://bugs.launchpad.net/neutron/+bug/1334926
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUF3r6AAoJEJa+6E7Ri+EVo+AH/i4GhZsFD3OJWlasq+XxkqqO
W7g/6YQuKgRndl63UjnWAfpvJCA8Bl1msryb2K0tTZpDByVpgupPAf6+/NMZXvCT
37YF236Ig/a/iLNjAdHRNHzq8Bhxe7tIikm1ICUH+Hyhob7soBlAC52lEJz9cFwb
Hazo2K0jjt4TEyxAae06KsIuOV/n+tO7ginYxxv2g8DkhKik5PMi4x8j//DYFz92
+SwPvUKeWiZ3JmD1M84Yj4VgPxah6fKDtCYKdTdcv7pYJGlcac8DTXbJkoFVd6H/
v+XbBGWjg7+M7WlZJmDlC2XfWLVKBsREs3BAN/hagE6aKAyImT/gfyT0WxLpVIU=
=Gk3u
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kesytone][multidomain] - Time to leave LDAP backend?

[Nathan Kinder]

On 09/01/2014 01:43 AM, Marcos Fermin Lobo wrote:
> Hi all,
> 
>  
> 
> I found two functionalities for keystone that could be against each other.
> 
>  
> 
> Multi-domain feature (This functionality is new in Juno.)
> 
> ---
> 
> Link:
> http://docs.openstack.org/developer/keystone/configuration.html#domain-specific-drivers
> 
> 
> Keystone supports the option to specify identity driver configurations
> on a domain by domain basis, allowing, for example, a specific domain to
> have its own LDAP or SQL server. So, we can use different backends for
> different domains. But, as Henry Nash said “it has not been validated
> with multiple SQL drivers”
> https://bugs.launchpad.net/keystone/+bug/1362181/comments/2
> 
>  
> 
> Hierarchical Multitenancy
> 
> 
> 
> Link:
> https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy
> 
> This is nested projects feature but, only for SQL, not LDAP.
> 
>  
> 
> So, if you are using LDAP and you want “nested projects” feature, you
> should to migrate from LDAP to SQL but, I you want to get multi-domain
> feature too you can’t use 2 SQL backends (you need at least one LDAP
> backend) because is not validated for multiple SQL drivers…
> 
>  
> 
> Maybe I’m losing something, please, correct me if I’m wrong.
> 
>  
> 
> Here my questions:
> 
>  
> 
> -  If I want Multi-domain and Hierarchical Multitenancy
> features, which are my options? What should I do (migrate or not migrate
> to SQL)?
> 
> -  Is LDAP going to deprecated soon?

I think you need to keep in mind that there are two separate backends
that support LDAP: identity and assignment.

>From everyone I have talked to on the Keystone team, SQL is preferred
for the assignment backend.  Storing assignment information in LDAP
seems to be a non-standard use case.

For the identity backend, LDAP is preferred.  Many people have users and
groups already in an LDAP server, and Keystone should be able to take
advantage of those existing users and credentials for centralized
authentication.  In addition, every LDAP server I know have has better
security features than the SQL identity backend offers, such as password
policies and account lockout.

The multiple domain support for multiple LDAP servers was really
designed to allow for separate groups of users from separate identity
LDAP servers to be usable in a single Keystone instance.

Given that the Keystone team considers SQL as the preferred assignment
backend, the hierarchical project blueprint was targeted against it.
The idea is that you would use LDAP server(s) for your users and have
hierarchical projects in SQL.

My personal feeling is that the LDAP assignment backend should
ultimately be deprecated.  I don't think the LDAP assignment backend
really offers any benefit of SQL, and you have to define some
non-standard LDAP schema to represent projects, roles, etc., or you end
up trying to shoehorn the data into standard LDAP schema that was really
meant for something else.

It would be interesting to create a poll like Morgan did for the
Keystone token format to see how widely the LDAP assignments backend is.
 Even more interesting would be to know the reasons why people are using
it over SQL.

Thanks,
-NGK

> 
>  
> 
> Thanks.
> 
>  
> 
> Cheers,
> 
> Marcos.
> 
>  
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0026] Unrestricted write permission to config files can allow code execution

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Unrestricted write permission to config files can allow code execution
- ---

### Summary ###
In numerous places throughout OpenStack projects, variables are read
directly from configuration files and used to construct statements
which are executed with the privileges of the OpenStack service.  Since
configuration files are trusted, the input is not checked or sanitized.
If a malicious user is able to write to these files, they may be able
to execute arbitrary code as the OpenStack service.

### Affected Services / Software ###
Nova / All versions, Trove / Juno, possibly others

### Discussion ###
Some OpenStack services rely on operating system commands to perform
certain actions.  In some cases these commands are created by appending
input from configuration files to a specified command, and passing the
complete command directly to the operating system shell to execute.
For example:

- --- begin example example.py snippet ---
  command='ls -al ' + config.DIRECTORY
  subprocess.Popen(command, shell=True)
- --- end example example.py snippet ---

In this case, if config.DIRECTORY is set to something benign like
'/opt' the code behaves as expected.  If, on the other hand, an
attacker is able to set config.DIRECTORY to something malicious such as
'/opt ; rm -rf /etc', the shell will execute both 'ls -al /opt' and 'rm
- -rf /etc'.  When called with shell=True, the shell will blindly execute
anything passed to it.  Code with the potential for shell injection
vulnerabilities has been identified in the above mentioned services and
versions, but vulnerabilities are possible in other services as well.

Please see the links at the bottom for a couple of examples in Nova and
Trove.

### Recommended Actions ###
Ensure permissions for configuration files across all OpenStack
services are set so that only the owner user can read/write to them.
In cases where other processes or users may have write access to
configuration files, ensure that all settings are sanitized and
validated.

Additionally the principle of least privilege should always be observed
- - files should be protected with the most restrictive permissions
possible.  Other serious security issues, such as the exposure of
plaintext credentials, can result from permissions which allow
malicious users to view sensitive data (read access).

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0026
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1343657
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
Shell Injection:

https://docs.python.org/2/library/subprocess.html#frequently-used-arguments
Additional LaunchPad Bugs:
https://bugs.launchpad.net/trove/+bug/1349939
https://bugs.launchpad.net/nova/+bug/1192971
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUCho0AAoJEJa+6E7Ri+EV/+MH/0Eoy8lIT5geQ541HJ/RTsn1
MVqXRvJK1wH/+OJaNKqvPjbn5ig/2t4IFdbnCpRzRJ2OxMpsX8zoSzBdYzYi7gAi
E1NczYbONk4JNn3fc4tzobWrq9hDWLgO5U57IhiAMjm6Q9vdsWK0SUqy5ZTZT/bG
+xgf+muriBBC0pdUKMpjaQdXeVJlTctix+RhZjOuGace4ioS4Dyn/ND4YIr+bRmk
cQqEgoPKHjFq+IoppNY1OgOJNs9FzUjOCtrUFBqyNrCmt34eSGs+z39Jh5Uf2ym6
W04+yw7zbdGwVcCVReZ+UYTDH+mPnrHDCdppTHe4M8eqe6e0eieL3dxlaBMP4lc=
=wxy3
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0023] Keystone logs auth tokens in URLs at the INFO log level

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Keystone logs auth tokens in URLs at the INFO log level
- ---

### Summary ###
When a client accesses Keystone using the Identity API version 2, the
tokens will be logged as part of some request URLs. Specifically all
requests to the tokens resource will be logged at the INFO level.

### Affected Services / Software ###
Keystone, Grizzly, Havana, Icehouse, Juno

### Discussion ###
Tokens are used to authorize users when making API requests against
OpenStack services. This allows previously authenticated users to make
API requests without providing their authentication information again,
such as their username and password.  This makes them very sensitive
when stored and transmitted on the wire. Ideally tokens should never be
stored on the disk to avoid the possibility of an attacker obtaining
local storage access and reusing them in the system.

Keystone logs the request URLs at the INFO level in order to make the
system operations and support easier. Unfortunately when the tokens
resource is accessed, the URLs include the user's secret token, like
in this case: (single line, wrapped)

-  begin example keystone.log snippet 
INFO eventlet.wsgi.server [-] 10.0.0.66 - - [22/Aug/2014 12:39:01]
  "GET /v2.0/tokens/ HTTP/1.1" 403 325 0.006539
-  end example keystone.log snippet 

Large systems often use remote logging mechanisms, which may use
unencrypted protocols such as syslog/udp. This could lead to
distributing the logfile entries containing tokens in plaintext over
untrusted networks. The target log collection systems may also use
different authorization rules than the local log files, which could
enable access to the tokens by support staff, or to third parties
storing the logs.

Additionally any load balancers and proxies processing the same request
may be logging the URL on their own. Their configuration and solution to
this problem is out of scope of this note and they should be checked
separately.

Version 3 of the Identity API does not pass the tokens in the URLs
anymore. This information is sent using the request headers or POST data
instead.

### Recommended Actions ###
Where possible, users and services interacting with the Keystone service
should be using the Identity API v3 endpoint. If that's not possible,
restricting the Keystone's logging level to WARN will fix the immediate
problem at the cost of removing potentially useful log information. Due
to various ways Keystone may be deployed and configured, interaction of
the 'debug', 'verbose', 'default_log_levels' and any wsgi server options
should be considered for this change. Keystone deployed via servers
other than eventlet will need their own solution.

If logging of all requests is required, this may be achieved by using a
third-party proxy, like Apache or Nginx with a configuration that does
not write the complete URL into the logs. For example Nginx can be
configured to switch to a customised log format using directive
'access_log' only for requests matching location '/v2.0/tokens/...'.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0023
Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1348844
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUCLr5AAoJEJa+6E7Ri+EVvagH+QFVLJz4jX8y5Eyj40pIPZOB
2CtgJbDsozItl5pJzvNQ7Zm/s4aETS3ScRvbjPjS3n1Qfu3K5j7ODakJoYE8FS+X
Nj7vfwHMhBQAZI00WlSRXzkt2PAbLUpMukmH+qftOHY/oq6Fi8LbUGgdf8v7DY4c
5SQOMX6G1kjoNKs4GX/oNyzyP068MJMnoaxFSDlfrd/a+S330xTaImJygIXFpRnp
yjsZz7mfU54KluRs9AHT1JrSyCNT5wcI05huo8JLpGGby0lOv0hLetGjxVUPYeK0
qgSgHA12tj9fwE9nSP8O62CPv9/Gr2ylt95MdK0Qwvg0oG2bDfBTLe5+APYZ13Q=
=FkjN
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-stable-maint] stable/havana jobs failing due to keystone bug 1357652

[Nathan Kinder]

On 08/17/2014 05:40 PM, Nathan Kinder wrote:
> 
> 
> On 08/17/2014 01:58 PM, Matt Riedemann wrote:
>>
>>
>> On 8/17/2014 3:36 PM, Alan Pevec wrote:
>>> 2014-08-17 22:25 GMT+02:00 Matt Riedemann :
>>>> The other thing I thought was we could cap the version of
>>>> python-keystoneclient in stable/havana, would that be bad?
>>>> stable/havana is
>>>> going to be end of life pretty soon anyway.
>>>
>>> No, we had cap on some clients and it was creating situations with
>>> conflicting requirements, last example was swiftclient<2.
>>> Another alternative was to start stable/* from clients but that was
>>> rejected in the past.
>>> Theory is that *clients are backward compatible but I'm not sure if
>>> addition of new dependencies was considered when decision to go with
>>> master-only clients was made.
>>>
>>> I think it's fine to add new test-requirements on stable, we should
>>> just somehow get an early warning that client change is going to break
>>> stable branch and update test-req preemptively.
>>>
>>> Cheers,
>>> Alan
>>>
>>
>> OK, so here is where we appear to be:
>>
>> 1. We need the oslo.utils changes in python-keystoneclient reverted on
>> master to get the stable/havana backports for global-requirements to
>> pass Jenkins.  The revert is here:
>>
>> https://review.openstack.org/#/q/status:open+project:openstack/python-keystoneclient+branch:master+topic:bug/1357652,n,z
>>
>>
>> 2. The backports for oslo.i18n and oslo.utils to stable/havana are here:
>>
>> https://review.openstack.org/#/q/status:open+project:openstack/requirements+branch:stable/havana+topic:bug/1357652,n,z
> 
> Jenkins is failing for stable/icehouse because of oslo.utils too:
> 
> https://review.openstack.org/113744
> 
> What seems odd is that oslo.utils was already added to
> global-requirements.txt for stable/icehouse:
> 
> https://review.openstack.org/#/c/112337/
> 
> Despite the above global-requirements.txt change, the tests are still
> failing.  It seems like something more will be needed to get the tests
> passing for both stable/icehouse and stable/havana.

I see that Brant has already proposed adding oslo.utils to
test-requirements.txt for keystone in stable/havana and stable/icehouse,
which should take care of these failures:

  havana - https://review.openstack.org/#/c/114846/
  icehouse - https://review.openstack.org/#/c/114845/

> 
>>
>>
>> 3. Once 1 and 2 are done, we can restore the changes to
>> python-keystoneclient on master.
>>
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-stable-maint] stable/havana jobs failing due to keystone bug 1357652

[Nathan Kinder]

On 08/17/2014 01:58 PM, Matt Riedemann wrote:
> 
> 
> On 8/17/2014 3:36 PM, Alan Pevec wrote:
>> 2014-08-17 22:25 GMT+02:00 Matt Riedemann :
>>> The other thing I thought was we could cap the version of
>>> python-keystoneclient in stable/havana, would that be bad?
>>> stable/havana is
>>> going to be end of life pretty soon anyway.
>>
>> No, we had cap on some clients and it was creating situations with
>> conflicting requirements, last example was swiftclient<2.
>> Another alternative was to start stable/* from clients but that was
>> rejected in the past.
>> Theory is that *clients are backward compatible but I'm not sure if
>> addition of new dependencies was considered when decision to go with
>> master-only clients was made.
>>
>> I think it's fine to add new test-requirements on stable, we should
>> just somehow get an early warning that client change is going to break
>> stable branch and update test-req preemptively.
>>
>> Cheers,
>> Alan
>>
> 
> OK, so here is where we appear to be:
> 
> 1. We need the oslo.utils changes in python-keystoneclient reverted on
> master to get the stable/havana backports for global-requirements to
> pass Jenkins.  The revert is here:
> 
> https://review.openstack.org/#/q/status:open+project:openstack/python-keystoneclient+branch:master+topic:bug/1357652,n,z
> 
> 
> 2. The backports for oslo.i18n and oslo.utils to stable/havana are here:
> 
> https://review.openstack.org/#/q/status:open+project:openstack/requirements+branch:stable/havana+topic:bug/1357652,n,z

Jenkins is failing for stable/icehouse because of oslo.utils too:

https://review.openstack.org/113744

What seems odd is that oslo.utils was already added to
global-requirements.txt for stable/icehouse:

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

Despite the above global-requirements.txt change, the tests are still
failing.  It seems like something more will be needed to get the tests
passing for both stable/icehouse and stable/havana.

> 
> 
> 3. Once 1 and 2 are done, we can restore the changes to
> python-keystoneclient on master.
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] stable/havana jobs failing due to keystone bug 1357652

[Nathan Kinder]

On 08/17/2014 09:18 AM, Nathan Kinder wrote:
> 
> 
> On 08/17/2014 09:08 AM, Matt Riedemann wrote:
>> I'm seeing some nova stable/havana patches failing consistently on
>> keystone bug 1357652 [1], keystone won't start due to an import error.
>>
>> I'm not seeing any recent changes for keystone in stable/havana so not
>> sure if this is an infra issue or something else.
> 
> I saw this too on Friday.  I believe that it's related to a new
> keystoneclient requirement for oslo.utils, which isn't in
> requirements.txt for keystone.  The change either needs to be reverted,
> or a requirement needs to be added  to satisfy the dependency (which may
> not be appropriate for stable releases).

This requirement change was backported for stable/icehouse:

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

It seems like the right thing to do is to propose a similar change for
stable/havana instead of reverting the keystoneclient change.

> 
> -NGK
> 
>>
>> I'm also not seeing the hits in logstash for some reason, which is odd.
>>
>> [1] https://bugs.launchpad.net/keystone/+bug/1357652
>>
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] stable/havana jobs failing due to keystone bug 1357652

[Nathan Kinder]

On 08/17/2014 09:08 AM, Matt Riedemann wrote:
> I'm seeing some nova stable/havana patches failing consistently on
> keystone bug 1357652 [1], keystone won't start due to an import error.
> 
> I'm not seeing any recent changes for keystone in stable/havana so not
> sure if this is an infra issue or something else.

I saw this too on Friday.  I believe that it's related to a new
keystoneclient requirement for oslo.utils, which isn't in
requirements.txt for keystone.  The change either needs to be reverted,
or a requirement needs to be added  to satisfy the dependency (which may
not be appropriate for stable releases).

-NGK

> 
> I'm also not seeing the hits in logstash for some reason, which is odd.
> 
> [1] https://bugs.launchpad.net/keystone/+bug/1357652
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0022] Nova Networking does not enforce security group rules following a soft reboot of an instance

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nova Networking does not enforce security group rules following a soft
reboot of an instance
- ---

### Summary ###
In deployments using Nova Networking, security group rules associated
with an instance may not be enforced after a soft reboot. Nova is
designed to apply the configured security group rules to an instance
when certain operations are performed, such as a normal boot operation.
If an operation has been performed that results in the clearing of
security group rules, such as restarting the nova compute service, then
performing a soft reboot of that instance will cause it to be
started without security group rules being applied.

Deployments using Neutron are not impacted.

### Affected Services / Software ###
Nova, Havana, Grizzly

### Discussion ###
In Nova deployments using Nova Networking, security groups are
implemented using iptables, which is used to configure and control
network traffic into Nova instances. When an instance is first booted
using the normal boot method (nova boot ), the security
group rules are applied to that instance.

When an instance is rebooted using the soft reboot method (nova reboot
), the security group rules are not reapplied since they
should have been already applied when the instance was initially
booted. If the security group rules have not been applied following an
event that resulted in their clearing, such as restarting the compute
service, the instance will be brought up without security group
enforcement. This situation is most likely to arise in cases where the
Nova compute service has been terminated or restarted, which removes
all iptables rules. If a stopped instance is then started by using a
soft reboot, it will not have any security group rules applied. A hard
reboot (nova reboot --hard ) reapplies the security group
rules, so it is not susceptible to this issue.

Depending on the deployment architecture, this could breach security
assumptions and leave an instance vulnerable to network based attacks.

This issue only affects the Havana and Grizzly releases. The Icehouse
release does not allow a stopped instance to be started using a soft
reboot, therefore this issue does not affect the Icehouse release.

### Recommended Actions ###
Do not to use the soft reboot method to start instances from the
stopped state. If instances are in the stopped state, boot using "nova
boot " or reboot using "nova reboot --hard "
to force the security group rules to be applied.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0022
Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1316822
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJT6MtUAAoJEJa+6E7Ri+EV2t4H/RwM5auF4ik9tdZuRNVLI/Rv
Si1SBx+EZA5QOksJ1r476mm2nA9+OnhCZRVnz8bHGiKtzC7eRV82c1OO1q0R/w1/
zHuTd6ZsZaAyBshfv6YoEVoRn6I2duYiR6gRHz/+hfrItt5E+SYBXqFskJazJ6dF
PZBA16qrIPmeir1eDpDvFnpbMEkAMUDKGZNba/DXwEZgdKVdFaWPI3cNIsHVP6bL
fsqMX+7bldB8kBDKfyFleFYqBUI5Anonzrq1tu6TS0vXl4gsfD2LE5LphPTYaiC+
EMypsACSafd19RhpeHS7/I1iVhf/Xa26Bvne0T8HWMLuDd1M5TT9E7nnas45k24=
=1x8I
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSN 0021] Owners of compromised accounts should verify Keystone trusts

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Owners of compromised accounts should verify Keystone trusts
- ---

### Summary ###
The Keystone 'trusts' API allows for delegation of privileges to one
user on behalf of another. This API can allow for an attacker of a
compromised account to set up backdoor access into the account. This
backdoor may not be easily detected, even if the account compromise is
detected.

### Affected Services / Software ###
Keystone, Grizzly, Havana, Icehouse

### Discussion ###
The Keystone trusts system allows for delegation of roles to Keystone
users without disclosing the main token, or sharing the account secret
key with those users. That means, after an account is compromised, the
change of the secret key and the invalidation of existing tokens may not
be enough to prevent future access from an attackers.

If an attacker obtains access to the account (via stolen credentials or
service exploitation), they can create a new Keystone trust. This new
trust may grant access not dependent on any knowledge of the compromised
user's secret key and can also be set to never expire. In this case, the
trust has to be manually found and removed by the account owner.

Information about using trusts can be found at:

https://wiki.openstack.org/wiki/Keystone/Trusts

### Recommended Actions ###
If the account has been compromised, or is being audited, the owner
should check the list of active trusts and verify that:

- - all the active trusts are needed
- - all the active trusts have the expected roles and delegation depth
- - all the active trusts have appropriate expiration lifetimes

At the time of writing this OSSN, trusts can be listed by using the
Keystone API directly:

-  begin CLI example 
# get ENDPOINT from the last field of the output
keystone endpoint-get --service identity --attr versionId \
  --value 3.0
# get TOKEN from the last field of the output
keystone token-get
# list the trusts by running:
curl -i -X GET "ENDPOINT/trusts/" -H "X-Auth-Token: TOKEN" \
  -H "Content-Type: application/json" -H "Accept: application/json"
-  end CLI example 

If some trust (with id TRUST_ID) is identified as invalid, it can be
deleted using:

-  begin CLI example 
curl -i -X DELETE "ENDPOINT/trusts/TRUST_ID" \
  -H "X-Auth-Token: TOKEN" -H "Content-Type: application/json" \
  -H "Accept: application/json"
-  end CLI example 

In the future, operators will be able to use keystoneclient for a more
convenient method of accessing and updating this information.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0021
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1341849
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJT0sTLAAoJEJa+6E7Ri+EVQpYIAJHSUsW4V1h6xD3Uvi+8sYVU
rc5+rDuOqoNwWmRw19qf0fuLPsBmoB/HvG/hfgdgazcrcBK6I/hR74bdH3CLE7Ew
dCFabstGUexNBDp84RchqDyu6vjB6oNGI3325fwgZcTq9WFTr5Jbc6gw1xov3gPC
0BForhceXpwVj3y7im2xtkId23wQwwB/AYerRnuZ8DsvFy9xPWiFub7w6WmzwpHj
BM38MTLS4GJZ3cDCXchp9u+z7rh6Jb34PHMKeXWzka+LasK0A+RqamvfC8OYB2rv
9Tmrt0GxbfSb/ereB3EEpu6LPkMtepjJtBxE+cv6PekfDLdri7+wHZUDXVYTtZ4=
=l08k
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] Feasibility of adding global restrictions at trust creation time

[Nathan Kinder]

On 07/22/2014 06:55 PM, Steven Hardy wrote:
> On Tue, Jul 22, 2014 at 05:20:44PM -0700, Nathan Kinder wrote:
>> Hi,
>>
>> I've had a few discussions recently related to Keystone trusts with
>> regards to imposing restrictions on trusts at a deployment level.
>> Currently, the creator of a trust is able to specify the following
>> restrictions on the trust at creation time:
>>
>>   - an expiration time for the trust
>>   - the number of times that the trust can be used to issue trust tokens
>>
>> If an expiration time (expires_at) is not specified by the creator of
>> the trust, then it never expires.  Similarly, if the number of uses
>> (remaining_uses) is not specified by the creator of the trust, it has an
>> unlimited number of uses.  The important thing to note is that the
>> restrictions are entirely in the control of the trust creator.
>>
>> There may be cases where a particular deployment wants to specify global
>> maximum values for these restrictions to prevent a trust from being
>> granted indefinitely.  For example, Keystone configuration could specify
>> that a trust can't be created that has >100 remaining uses or is valid
>> for more than 6 months.  This would certainly cause problems for some
>> deployments that may be relying on indefinite trusts, but it is also a
>> nice security control for deployments that don't want to allow something
>> so open-ended.
>>
>> I'm wondering about the feasibility of this sort of change, particularly
>> from an API compatibility perspective.  An attempt to create a trust
>> without an expires_at value should still be considered as an attempt to
>> create a trust that never expires, but Keystone could return a '403
>> Forbidden' response if this request violates the maximum specified in
>> configuration (this would be similar for remaining_uses).  The semantics
>> of the API remain the same, but the response has the potential to be
>> rejected for new reasons.  Is this considered as an API change, or would
>> this be considered to be OK to implement in the v3 API?  The existing
>> API docs [1][2] don't really go to this level of detail with regards to
>> when exactly a 403 will be returned for trust creation, though I know of
>> specific cases where this response is returned for the create-trust request.
> 
> FWIW if you start enforcing either of these restrictions by default, you
> will break heat, and every other delegation-to-a-service use case I'm aware
> of, where you simply don't have any idea how long the lifetime of the thing
> created by the service (e.g heat stack, Solum application definition,
> Mistral workflow or whatever) will be.
> 
> So while I can understand the desire to make this configurable for some
> environments, please leave the defaults as the current behavior and be
> aware that adding these kind of restrictions won't work for many existing
> trusts use-cases.

I fully agree.  In no way should the default behavior change.

> 
> Maybe the solution would be some sort of policy defined exception to these
> limits?  E.g when delegating to a user in the service project, they do not
> apply?

Role-based limits seem to be a natural progression of the idea, though I
didn't want to throw that out there from the get-go.

-NGK

> 
> Steve
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Keystone] Feasibility of adding global restrictions at trust creation time

[Nathan Kinder]

Hi,

I've had a few discussions recently related to Keystone trusts with
regards to imposing restrictions on trusts at a deployment level.
Currently, the creator of a trust is able to specify the following
restrictions on the trust at creation time:

  - an expiration time for the trust
  - the number of times that the trust can be used to issue trust tokens

If an expiration time (expires_at) is not specified by the creator of
the trust, then it never expires.  Similarly, if the number of uses
(remaining_uses) is not specified by the creator of the trust, it has an
unlimited number of uses.  The important thing to note is that the
restrictions are entirely in the control of the trust creator.

There may be cases where a particular deployment wants to specify global
maximum values for these restrictions to prevent a trust from being
granted indefinitely.  For example, Keystone configuration could specify
that a trust can't be created that has >100 remaining uses or is valid
for more than 6 months.  This would certainly cause problems for some
deployments that may be relying on indefinite trusts, but it is also a
nice security control for deployments that don't want to allow something
so open-ended.

I'm wondering about the feasibility of this sort of change, particularly
from an API compatibility perspective.  An attempt to create a trust
without an expires_at value should still be considered as an attempt to
create a trust that never expires, but Keystone could return a '403
Forbidden' response if this request violates the maximum specified in
configuration (this would be similar for remaining_uses).  The semantics
of the API remain the same, but the response has the potential to be
rejected for new reasons.  Is this considered as an API change, or would
this be considered to be OK to implement in the v3 API?  The existing
API docs [1][2] don't really go to this level of detail with regards to
when exactly a 403 will be returned for trust creation, though I know of
specific cases where this response is returned for the create-trust request.

Thanks,
-NGK

[1]
http://docs.openstack.org/api/openstack-identity-service/3/content/create-trust-post-os-trusttrusts.html
[2]
http://docs.openstack.org/api/openstack-identity-service/3/content/forbidden.html

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone][devstack] Keystone is now gating (Juno and beyond) on Apache + mod_wsgi deployed Keystone

[Nathan Kinder]

On 07/11/2014 08:43 AM, Morgan Fainberg wrote:
> The Keystone team is happy to announce that as of yesterday (July 10th 2014), 
> with the merge of https://review.openstack.org/#/c/100747/ Keystone is now 
> gating on Apache + mod_wsgi based deployment. This also has moved the default 
> for devstack to deploy Keystone under apache. This is in-line with the 
> statement that Apache + mod_wsgi is the recommended deployment for Keystone, 
> as opposed to using “keystone-all”.

Great work in getting this accomplished!

-NGK

> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] [Swift] Question re. keystone domains

[Nathan Kinder]

On 07/01/2014 12:15 PM, Dolph Mathews wrote:
> 
> On Tue, Jul 1, 2014 at 11:20 AM, Coles, Alistair  > wrote:
> 
> We have a change [1] under review in Swift to make access control
> lists compatible with migration to keystone v3 domains. The change
> makes two assumptions that I’d like to double-check with keystone
> folks:
> 
> __ __
> 
> __1.  __That a project can never move from one domain to another.
> 
> We're moving in this direction, at least. In Grizzly and Havana, we made
> no such restriction. In Icehouse, we introduced such a restriction by
> default, but it can be disabled. So far, we haven't gotten any
> complaints about adding the restriction, so maybe we should just add
> additional help text to the option in our config about why you would
> never want to disable the restriction, citing how it would break swift?
> 
> 
> 
> __2.  __That the underscore character cannot appear in a valid
> domain id – more specifically, that the string ‘_unknown’ cannot be
> confused with a domain id.
> 
> That's fairly sound. All of our domain ID's are system-assigned as
> UUIDs, except for the "default" domain which has an explicit
> id='default'. We don't do anything to validate the assumption, though.

I don't like the idea of making this assumption without explicit
validation.  If there is a need for a blacklisted domain id space, we
should enforce it to prevent problems down the road.

-NGK

> 
> 
> 
> __ __
> 
> Are those safe assumptions?
> 
> __ __
> 
> Thanks,
> 
> Alistair
> 
> __ __
> 
> [1] https://review.openstack.org/86430
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone] HTTP Get and HEAD requests mismatch on resulting HTTP status (proposed REST API Response Status Changes)

[Nathan Kinder]

On 07/01/2014 07:48 PM, Robert Collins wrote:
> Wearing my HTTP fanatic hat - I think this is actually an important
> change to do. Skew like this can cause all sorts of odd behaviours in
> client libraries.

+1.  The current behavior of inconsistent response codes between the two
recommended methods of deploying Keystone should definitely be
considered as a bug IMHO.  Consistency in responses is important
regardless of how Keystone is deployed, and it seems obvious that we
should modify the responses that are out of spec to achieve consistency.

-NGK
> 
> -Rob
> 
> On 2 July 2014 13:13, Morgan Fainberg  wrote:
>> In the endeavor to move from the default deployment of Keystone being 
>> eventlet (in devstack) to Apache + mod_wsgi, I noticed that there was an odd 
>> mis-match on a single set of tempest tests relating to trusts. Under 
>> eventlet a HTTP 204 No Content was being returned, but under mod_wsgi an 
>> HTTP 200 OK was being returned. After some investigation it turned out that 
>> in some cases mod_wsgi will rewrite HEAD requests to GET requests under the 
>> hood; this is to ensure that the response from Apache is properly built when 
>> dealing with filtering. A number of wsgi applications just return nothing on 
>> a HEAD request, which is incorrect, so mod_wsgi tries to compensate.
>>
>> The HTTP spec states: "The HEAD method is identical to GET except that the 
>> server must not return any Entity-Body in the response. The metainformation 
>> contained in the HTTP headers in response to a HEAD request should be 
>> identical to the information sent in response to a GET request. This method 
>> can be used for obtaining metainformation about the resource identified by 
>> the Request-URI without transferring the Entity-Body itself. This method is 
>> often used for testing hypertext links for validity, accessibility, and 
>> recent modification.”
>>
>> Keystone has 3 Routes where HEAD will result in a 204 and GET will result in 
>> a 200.
>>
>> * /v3/auth/tokens
>> * /v2.0/tokens/{token_id}
>> * /OS-TRUST/trusts/{trust_id}/roles/{role_id} <--- This is the only one 
>> tested by Tempest.
>>
>> The easiest solution is to correct the case where we are out of line with 
>> the HTTP spec and ensure these cases return the same status code for GET and 
>> HEAD methods. This however changes the response status of a public REST API. 
>> Before we do this, I wanted to ensure the community, developers, and TC did 
>> not have an issue with this correction. We are not changing the class of 
>> status (e.g. 2xx to 4xx or vice-versa). This would simply be returning the 
>> same response between GET and HEAD requests. The fix for this would be to 
>> modify the 3 tempest tests in question to expect HTTP 200 instead of 204.
>>
>> There are a couple of other cases where Keystone registers a HEAD route but 
>> no GET route (these would be corrected at the same time, to ensure 
>> compatibility). The final correction is to enforce that Keystone would not 
>> send any data on HEAD requests (it is possible to do so, but we have not had 
>> it happen).
>>
>> You can see a proof-of-concept review that shows the tempest failures here: 
>> https://review.openstack.org/#/c/104026
>>
>> If this change (even though it is in violation of 
>> https://wiki.openstack.org/wiki/APIChangeGuidelines#Generally_Not_Acceptable 
>> is acceptable, it will unblock the last of a very few things to have 
>> Keystone default deploy via devstack under Apache (and gate upon it). Please 
>> let me know if anyone has significant issues with this change / concerns as 
>> I would like to finish up this road to mod_wsgi based Keystone as early in 
>> the Juno cycle as possible.
>>
>> Cheers,
>> Morgan Fainberg
>>
>>
>> —
>> Morgan Fainberg
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSG][OSSN] Cinder SSH Pool will auto-accept SSH host signatures by default

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cinder SSH Pool will auto-accept SSH host signatures by default
- ---

### Summary###
In OpenStack releases prior to Juno, the SSH connection pool used by
Cinder drivers to control SAN hosts will silently auto-accept SSH host
fingerprints. This potentially allows for a man in the middle attack
through the impersonation of a legitimate storage host.

### Affected Services / Software ###
Cinder, Icehouse, Havana, Grizzly, Folsom

### Discussion ###
Cinder drivers for controlling SAN hardware communicate with storage
hosts over SSH. To facilitate creation of these drivers, Cinder provides
a utility mechanism to manage pooled SSH connections. This connection
pool is using a policy that will silently accept the SSH fingerprint
of any unknown host when it first connects. However, it is not properly
maintaing the list of known hosts and will thus permit connections to a
host regardless of the SSH fingerprint presented. This impacts all
drivers built using the utility. At the time of writing these drivers
include, but may not be limited to:

- - Solaris ISCSI driver
- - HP LeftHand SAN ISCSI driver
- - Huawei OceanStor T series and Dorado series storage arrays
- - Dell EqualLogic Storage
- - IBM Storwize SVC

In the event that a malicious adversary has a point of presence on the
storage network, they could undermine network communications between
Cinder and the SAN host. Should an adversary manage to impersonate the
storage host, Cinder will silently accept the newly presented
fingerprint of the bogus host and allow the connection. This behaviour
constitutes a typical Man in the Middle attack that could intercept and
manipulate communications with the storage host, possibly leaking login
credentials.

If login credentials can be acquired, then direct interaction with the
legitimate storage host becomes possible. This could result in Cinder
volumes being accessed or modified to export compromised code and data
to other services.

The presence of this defect can be detected by initially connecting to a
storage host and then re-generating that hosts local SSH details. Cinder
will still allow connections to the host despite its now modified
fingerprint. This is the default configuration.

### Recommended Actions ###
Deployers should pay attention to the SSH interface between the Cinder
driver and the SAN host and take appropriate measures to defend the
storage network. These measures could include physical network isolation
or placing an Intrusion Detection System on the network. The IDS should
detect attacks such as ARP table poisoning, DHCP spoofing or DNS forgery
that could be used to impersonate a SAN host and enact an Man in the
Middle attack.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0019
Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1320056
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTsbC4AAoJEJa+6E7Ri+EVK44IAKmfcak6QIBtd9QT4bC013/8
083WqUa6rnhX7jGtRkwm6lELVDw5Vk8jUpNYqnu7W7X+7+q24S4R/52UrxJBE8f7
dkxIcTS6Nx9qxGeoVVWFa4QLEuuG82K0PYhyEasbn7m8e672QeqLVHxUzAH7L1Yg
hyXyZvxpN3bz38PpOKjf2Sj4lG3g1DZkZTL1cW2HIla9ZFiqZ9IMa5f2FItrgLEJ
epLtsEhkhM/M/Nk9Qqbvvn0Ir3WTFN0l43hGJP4iF+frEsSewZqDXwNafVXl8k9v
4He6I1gpR2bpmYGIv4Bd+9jnjuiujFUfIIZKQg4LvNpH0FB+DqvCGUS5A0D1WjU=
=SGiN
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Barebones CA

[Nathan Kinder]

On 06/25/2014 02:42 PM, Clark, Robert Graham wrote:
> 
> Ok, I’ll hack together a dev plugin over the next week or so, other work
> notwithstanding. Where possible I’ll probably borrow from the dog tag
> plugin as I’ve not looked closely at the plugin infrastructure in Barbican
> recently.

My understanding is that Barbican's plugin interface is currently in the
midst of a redesign, so be careful not to copy something that will be
changing shortly.

-NGK

> 
> Is this something you’d like a blueprint for first?
> 
> -Rob
> 
> 
> 
> 
> On 25/06/2014 18:30, "Ade Lee"  wrote:
> 
>> I think the plan is to create a Dogtag instance so that integration
>> tests can be run whenever code is checked in (both with and without a
>> Dogtag backend).
>>
>> Dogtag isn't that difficult to deploy, but being a Java app, it does
>> bring in a set of dependencies that developers may not want to deal with
>> for basic/ devstack testing.
>>
>> So, I agree that a simple OpenSSL CA may be useful at least initially as
>> a 'dev' plugin.
>>
>> Ade
>>
>> On Wed, 2014-06-25 at 16:31 +, Jarret Raim wrote:
>>> Rob,
>>>
>>> RedHat is working on a backend for Dogtag, which should be capable of
>>> doing something like that. That's still a bit hard to deploy, so it
>>> would
>>> make sense to extend the 'dev' plugin to include those features.
>>>
>>>
>>> Jarret
>>>
>>>
>>> On 6/24/14, 4:04 PM, "Clark, Robert Graham"  wrote:
>>>
 Yeah pretty much.

 That¹s something I¹d be interested to work on, if work isn¹t ongoing
 already.

 -Rob





 On 24/06/2014 18:57, "John Wood"  wrote:

> Hello Robert,
>
> I would actually hope we have a self-contained certificate plugin
> implementation that runs 'out of the box' to enable certificate
> generation orders to be evaluated and demo-ed on local boxes.
>
> Is this what you were thinking though?
>
> Thanks,
> John
>
>
>
> 
> From: Clark, Robert Graham [robert.cl...@hp.com]
> Sent: Tuesday, June 24, 2014 10:36 AM
> To: OpenStack List
> Subject: [openstack-dev] [Barbican] Barebones CA
>
> Hi all,
>
> I¹m sure this has been discussed somewhere and I¹ve just missed it.
>
> Is there any value in creating a basic ŒCA¹ and plugin to satisfy
> tests/integration in Barbican? I¹m thinking something that probably
> performs OpenSSL certificate operations itself, ugly but perhaps
>>> useful
> for some things?
>
> -Rob
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSG][OSSN] Nova Network configuration allows guest VMs to connect to host services

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nova Network configuration allows guest VMs to connect to host services
- ---

### Summary ###
When using Nova Network to manage networking for compute instances,
instances are able to reach network services running on the host
system. This may be a security issue for the operator.

### Affected Services / Software ###
Nova, Folsom, Grizzly, Havana, Icehouse

### Discussion ###
OpenStack deployments using Nova Network, rather than Neutron for
network configuration will cause the host running the instances to be
reachable on the virtual network. Specifically, booted instances can
check the address of their gateway and try to connect to it. Any host
service which listens on the interfaces created by OpenStack and does
not apply any additional filtering will receive such traffic.

This is a security issue for deployments where the OpenStack service
users are not trusted parties, or should not be allowed to access
underlying services of the host system.

Using a specific example of devstack in default configuration, the
instance spawned inside of it will see the following routing table:

$ ip r s
default via 172.16.1.1 dev eth0
172.16.1.0/24 dev eth0  src 172.16.1.2

The instance can then use the gateway's address (172.16.1.1) to connect
to the sshd service on the host system (if one is running and listening
on all interfaces). The host system will see the connection coming from
interface `br100`.

### Recommended Actions ###
Connections like this can be stopped at various levels (libvirt filters,
specific host's iptables entries, ebtables, network service
configuration). The recommended way to protect against the incoming
connections is to stop the critical services from binding to the
Nova-controlled interfaces.

Using the sshd service as an example, the default configuration on most
systems is to bind to all interfaces and all local addresses
("ListenAddress :22" in sshd_config).  In order to configure it only on
a specific interface, use "ListenAddress a.b.c.d:22" where a.b.c.d is
the address assigned to the chosen interface. Similar settings can be
found for most other services.

The list of services listening on all interfaces can be obtained by
running command 'netstat -ltu', where the '*:port' in the "Local
Address" field means the service will likely accept connections from the
local Nova instances.

If filtering of the traffic is chosen instead, care must be taken to
allow traffic coming from the running instances to services controlled
by Nova - DHCP and DNS providers.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0018
Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1316271
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTqt1vAAoJEJa+6E7Ri+EVxxcH/jKHpZOebKKwEpj6EqwNQQeV
o1atUb7zvqhSUUYHIBbAgc51bSlWtdvUVq+fH5w1O/PU+C1OMMtDZK7lvQnZDYrA
j5XfEItjon1wAIyaZm96OOlq39PW5gQJN6q1A+/3sV6tpeVsX6VhucJH4tOAillL
vOyuGcBZeWDbf38IZXHulALvkJ6ReNcZzrzSrbpA3n2d7dGhtBiYXV2DMjxvOjDE
qLy+Fe3KAeZWtYgqK6NPKUfNGzIxtoKgvgoOJugp1EWIr9HdwIjTOndsI4owThjC
M6OElLwaROWtpFe1gONiaU1gVDZ2MdXmQPwB4ZMzNFdoAc3cx7IAzHFClei2fug=
=2HqX
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSG][OSSN] Session-fixation vulnerability in Horizon when using the default signed cookie sessions

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Session-fixation vulnerability in Horizon when using the default
signed cookie sessions
- ---

### Summary ###
The default setting in Horizon is to use signed cookies to store
session state on the client side.  This creates the possibility that if
an attacker is able to capture a user's cookie, they may perform all
actions as that user, even if the user has logged out.

### Affected Services / Software ###
Horizon, Folsom, Grizzly, Havana, Icehouse

### Discussion ###
When configured to use client side sessions, the server isn't aware
of the user's login state.  The OpenStack authorization tokens are
stored in the session ID in the cookie.  If an attacker can steal the
cookie, they can perform all actions as the target user, even after the
user has logged out.

There are several ways attackers can steal the cookie.  One example is
by intercepting it over the wire if Horizon is not configured to use
SSL.  The attacker may also access the cookie from the filesystem if
they have access to the machine.  There are also other ways to steal
cookies that are beyond the scope of this note.

By enabling a server side session tracking solution such as memcache,
the session is terminated when the user logs out.  This prevents an
attacker from using cookies from terminated sessions.

It should be noted that Horizon does request that Keystone invalidate
the token upon user logout, but this has not been implemented for the
Identity API v3.  Token invalidation may also fail if the Keystone
service is unavailable.  Therefore, to ensure that sessions are not
usable after the user logs out, it is recommended to use server side
session tracking.

### Recommended Actions ###
It is recommended that you configure Horizon to use a different session
backend rather than signed cookies.  One possible alternative is to use
memcache sessions.  To check if you are using signed cookies, look for
this line in Horizon's local_settings.py

- --- begin example local_settings.py snippet ---
  SESSION_ENGINE = 'django.contrib.sessions.backends.signed_cookies'
- --- end example local_settings.py snippet ---

If the SESSION_ENGINE is set to value other than
'django.contrib.sessions.backends.signed_cookies' this vulnerability
is not present.  If SESSION_ENGINE is not set in local_settings.py,
check for it in settings.py.

Here are the steps to configure memcache sessions:

  1. Ensure the memcached service is running on your system
  2. Ensure that python-memcached is installed
  3. Configure memcached cache backend in local_settings.py

- --- begin example local_settings.py snippet ---
CACHES = {
'default': {
'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
'LOCATION': '127.0.0.1:11211',
}
}
- --- end example local_settings.py snippet ---

 Make sure to use the actual IP and port of the memcached service.

  4. Add a line in local_settings.py to use the cache backend:

- --- begin example local_settings.py snippet ---
  SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
- --- end example local_settings.py snippet ---

  5. Restart Horizon's webserver service (typically 'apache2' or
  httpd')

Furthermore, you should always enable SSL for Horizon to help mitigate
such attack scenarios.

Please note that regardless of which session backend is used, if the
cookie is compromised, an attacker may assume all privileges of the
user for as long as their session is valid.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0017
Original LaunchPad Bug : https://bugs.launchpad.net/horizon/+bug/1327425
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
Further discussion of the issue:
http://www.pabloendres.com/horizon-and-cookies/#comment-115
Django docs:
https://docs.djangoproject.com/en/1.6/ref/settings/

https://docs.djangoproject.com/en/1.6/topics/http/sessions/#configuring-sessions
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTpFQ7AAoJEJa+6E7Ri+EVuO8IAJvfqVZOHaC0zWwpQiaHBnLg
RCtlUdSQgPR/wLhWsKjOK9swMC0ajue8hwDKuo4bzpzTEHkC0hswCTkcENaxO0f5
7uZisx/FYtdvD+IqoRjOaS23klyNOe8xTwbitsDCqgEZUyLJPAzgN+KiAwcXaoQC
UyAOMuRZgywKjGQDLGPiUrR2ug604FBmfxzywvE3iiCaNi/+4vdcHSr9wyNtzKDH
g9zM861eCbDfDP9rUzpPytNVt5H5QXLGrUl9/+M6BN2a13RpC5dRxQfP5OlgYlSy
3LiqSogFn5naC/eF7rR/kFVKfgf7FN0e9zS9ZSqFfXevZSAIY9cEP7E0V5XtyfY=
=FDu2
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Message level security plans. [barbican]

[Nathan Kinder]

On 06/12/2014 03:16 PM, Tiwari, Arvind wrote:
> Some thoughts out of the context of this email thread.
> 
> As per my understanding of Kite, it is a subset of Barbican or there might be 
> minor gaps. If that is the true statement then what is the point of having a 
> services with duplicate feature set? Why not port all the Kite feature to 
> Barbican and use Barbican for message level security needs?

That's not a true statement.  This was also something that was discussed
at the Atlanta Summit in the Kite session with the Barbican development
team, and agreement was reached that they are different use-cases and
feature sets that should remain separate.

To (over) simplify, Barbican allows OpenStack users (or services)
identified by Keystone tokens to archive and later retrieve keys.  In
contrast, Kite is generating and issuing temporary session keys to
communicating parties that are using the message queue in the underlying
OpenStack infrastructure.  These parties are not identified by Keystone.
 These session keys are also not archived by a service.  Kite generates
them, issues them in the form of a ticket, and forgets them immediately.
 You never want to be able to retrieve a key after a ticket is issued.
In addition, the key generation is not purely random as I've outlined in
my blog post (see the details around how HKDF is used if you're interested).

There are areas for integration between Kite and Barbican.  The most
obvious would be to utilize Baribican to store the long-term keys used
to authenticate the communicating party.

Thanks,
-NGK

> 
> Thoughts?
> 
> Arvind
> 
> -Original Message-
> From: Nathan Kinder [mailto:nkin...@redhat.com] 
> Sent: Thursday, June 12, 2014 3:32 PM
> To: openstack-dev@lists.openstack.org
> Cc: Jamie Lennox
> Subject: Re: [openstack-dev] Message level security plans.
> 
> Hi Tim,
> 
> Jamie Lennox (cc'd) has been the main developer working on Kite.  I'm sure he 
> would appreciate you getting involved in reviews [1] and any other 
> development help you're willing to contribute.  Patches have slowly been 
> landing in the kite repo. [2]
> 
> For others not familiar with Kite, there is the blueprint mentioned elsewhere 
> in this thread as well as this write-up of mine:
> 
>   https://blog-nkinder.rhcloud.com/?p=62
> 
> Thanks,
> -NGK
> 
> [1] https://review.openstack.org/#/q/status:open+project:stackforge/kite,n,z
> [2] https://github.com/stackforge/kite
> 
> 
> On 06/12/2014 08:08 AM, Kelsey, Timothy Joh wrote:
>> Hello OpenStack folks,
>>
>> First please allow me to introduce myself, my name is Tim Kelsey and I'm a 
>> security developer working at HP. I am very interested in projects like Kite 
>> and the work that's being undertaken to introduce message level security 
>> into OpenStack and would love to help out on that front. In an effort to 
>> ascertain the current state of development it would be great to hear from 
>> the people who are involved in this and find out what's being worked on or 
>> planned in blueprints.
>>
>> Many Thanks,
>>
>> --
>> Tim Kelsey
>> Cloud Security Engineer
>> HP Helion
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Message level security plans.

[Nathan Kinder]

Hi Tim,

Jamie Lennox (cc'd) has been the main developer working on Kite.  I'm
sure he would appreciate you getting involved in reviews [1] and any
other development help you're willing to contribute.  Patches have
slowly been landing in the kite repo. [2]

For others not familiar with Kite, there is the blueprint mentioned
elsewhere in this thread as well as this write-up of mine:

  https://blog-nkinder.rhcloud.com/?p=62

Thanks,
-NGK

[1] https://review.openstack.org/#/q/status:open+project:stackforge/kite,n,z
[2] https://github.com/stackforge/kite


On 06/12/2014 08:08 AM, Kelsey, Timothy Joh wrote:
> Hello OpenStack folks,
> 
> First please allow me to introduce myself, my name is Tim Kelsey and I’m a 
> security developer working at HP. I am very interested in projects like Kite 
> and the work that’s being undertaken to introduce message level security into 
> OpenStack and would love to help out on that front. In an effort to ascertain 
> the current state of development it would be great to hear from the people 
> who are involved in this and find out what's being worked on or planned in 
> blueprints.
> 
> Many Thanks,
> 
> --
> Tim Kelsey
> Cloud Security Engineer
> HP Helion
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OSSG][OSSN] Some versions of Glance do not apply property protections as expected (***revision***)

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

The previous revision of this OSSN specified an incorrect workaround.
 This new revision should supersede the old revision.

Thanks,
- -NGK

- --

Some versions of Glance do not apply property protections as expected
- ---

### Summary ###
Tom Leaman reported an issue to the OpenStack mailing list that
affects Glance property protections. A permissive property setting in
the Glance property protections configuration file will override any
previously set stricter ones.

### Affected Services / Software ###
Glance, Folsom, Grizzly

### Discussion ###
Glance property protections limit the users who can perform CRUD
operations on a Glance property to those in specific roles. When the
property protections rules are processed in the Folsom and Grizzly
OpenStack releases, a matching rule will only stop the processing of
subsequent rules if it authorizes the attempted action. If there is a
matching rule that would reject an action that is followed by another
matching rule that would accept the action, then the action is accepted
even though one may expect it to be rejected.

In the following policy-protections.conf example, the desired result is
to restrict 'update' and 'delete' permissions for any property
beginning with 'provider_' to only users with the 'admin' role.

- --- begin example property-protections.conf snippet ---
[^provider_.*$]
create = admin
read = admin,_member_
update = admin
delete = admin

[.*]
create = _member_
read = _member_
update = _member_
delete = _member_
- --- end example property-protections.conf snippet ---

Due to the way that the rules are processed in the Folsom and Grizzly
OpenStack releases, the admin restriction for properties beginning with
'provider_' is nullified by the '.*' permissions since it also matches
the same properties. This results in all users with the '_member_'
role  being allowed the 'create', 'update', and 'delete' permissions on
properties beginning with 'provider_', which is not what was intended.

This bug only affects the use of user-roles in Glance. It does not
occur when policies are used to determine property protections.

### Recommended Actions ###
This issue has been fixed in Havana (Glance 2013.2.2) and subsequent
releases by changing the property protections rule processing to stop
at the first rule that matches the property, even if it does not allow
the attempted action.

Users of affected releases should avoid using multiple rules that would
match the same property. Specifically, wildcard rules should be avoided
unless they are the most restricive rules defined.

If a permissive rule is needed that is intended to match all properties
that are not matched by other rules, a carefully crafted regular
expression should be used instead of a wildcard as demonstrated below.

- --- begin example property-protections.conf snippet ---
[^provider_.*$]
create = admin
read = admin,_member_
update = admin
delete = admin

[^((?!provider_).)*$]
create = _member_
read = _member_
update = _member_
delete = _member_
- --- end example property-protections.conf snippet ---

In the above example, 'create', 'update', and 'delete' operations are
only allowed for users with the '_member_' role for properties that do
not begin with 'provider_'.

Configuration files with multiple property protection entries set
should be tested to ensure that CRUD actions are constrained in the way
the administrator intended.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0013
Original Launchpad Bug : https://bugs.launchpad.net/glance/+bug/1271426
Original Report :
http://lists.openstack.org/pipermail/openstack-dev/2014-January/024861.html
Glance Property Protections :
https://wiki.openstack.org/wiki/Glance-property-protections
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTmJRSAAoJEJa+6E7Ri+EVI0sIAIVeMqpMvgRx523AkXGackEl
+XrS1O0xaAN6DHhnW9djvZEZsuiBIJSf9Wz5Vd/R0FbY2MC6TFCylj6HAqP9t1kA
4j5/J40NF8cv6pW3n3WnHUm2Df+8CDIkzYZw1eTKtY+ftu1n2zm1BeAJgm0lSHkE
2q1dwRY+rge0+CvzcyDn5asX4nwmpI/7ZbdjFbi/wBvsFrJeeAaix0o+ZvTWAF5E
9kH/zZrupfVXTERfwZ2oH3tEI9paiod5XxDRRSuD3KoeJUfJCyhzBsaLI8AXBOBN
xhpfn5cDapxwNNU84RhwySFzja+SZ9DCINjN61Irz72EbtL/EkIXwaqUTUx2pYY=
=hjFX
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSG][OSSN] Cinder wipe fails in an insecure manner on Grizzly

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cinder wipe fails in an insecure manner on Grizzly
- ---

### Summary ###
A configuration error can prevent the secure erase of volumes in Cinder
on Grizzly, potentially allowing a user to recover another user’s data.

### Affected Services / Software ###
Cinder, Grizzly

### Discussion ###
In Cinder on Grizzly, a configurable method to perform a secure erase of
volumes was added. In the event of a misconfiguration no secure erase
will be performed.

The default code path in Cinder’s clear_volume() method, which is taken
in the event of a configuration error, results in no wiping of the
volume - even in the event that the user had flagged the volume for
wiping.

This is the same behaviour as if the volume_clear = ‘none’ option was
selected. This could let an attacker recover data from a volume that was
intended to be securely erased. Examples of possible incorrect
configuration options include values that would appear to result in a
secure erase, for example “volume_clear = true” or “volume_clear =
yes”.

In the event of a misconfiguration resulting in this issue, the message
“Error unrecognized volume_clear option” should be present in log
files.

### Recommended Actions ###
- - Create and clear a volume (cinder create --display_name erasetest 10;
cinder delete erasetest)
- - Review log files for the above error message (grep “Error unrecognized
volume_clear option” )
- - Review configuration files to ensure that the valid options ‘zero’ or
‘shred’ are specified.


### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0016
Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1322766
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTjc5hAAoJEJa+6E7Ri+EVm6EH/i0IseGxSHb0il1ryDUu56K7
GwX0P72pBQ90BGaJdaLR0t/w68o9hZXFmGJxVZk/8nq0cI+FriEXa8QDCuNwWe2X
vgJ4YoqlvD9jy2V5MUV/WaP99QBnCVClj9Gr0h21YzFJe+mvyAFLKY8HMbhrxUgv
dkhtYUodDQnjSNjVO6s5hzsCYDjti78aPnzgiP2Y7bsHrOkVgRy4a1qt281btPWd
ZklXviqvvO2hI1ZSsH5JkjzLTD3THN260TIkIrVThUOm0TK3iC3JOu+f+FoTOXGg
gHXR0DyIoVldqtn1Nmcd4OY/Wx9bav6jPyPPhfcAAsbbipCzUY/WtRe9pm/gJI0=
=W3y3
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSG][OSSN] Glance allows non-admin users to create public images

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Glance allows non-admin users to create public images
- ---

### Summary ###
The default policy settings in Glance allow any user to upload an image
that is publicly available to all users. This can allow a malicious user
to upload a vulnerable image that other users may use, unknowingly
exposing themselves to attack.

### Affected Services / Software ###
Glance, Folsom, Grizzly, Havana, Icehouse

### Discussion ###
When uploading an image to Glance, the user performing the upload is
able to mark the image as public. This allows all other users to see and
use the image when they create new instances. The ability to share
images with all users within an OpenStack deployment is very useful, but
it can potentially be abused for malicious purposes. For example, an
image can be uploaded that contains a backdoor that allows the attacker
to have unauthorized access to instances that are created from that
image.

Glance does allow for the ability to publicize images to be controlled
by policy. However, the default policy setting allows all users to
publicize images.

### Recommended Actions ###
It is recommended that the ability to publicize images in Glance be
restricted to trusted users, such as users with the "admin" role.  This
can be done by modifying the "publicize_image" capability in Glance's
policy.json file.  Here is an example of restricting this capability to
users with the "admin" role:

-  begin example policy.json snippet 
"publicize_image": "role:admin",
-  end example policy.json snippet 

The default policy setting in Glance is planned to be changed to
restrict the ability to publicize images to users with the "admin" role
in the Juno release of OpenStack.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0015
Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1313746
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTifWmAAoJEJa+6E7Ri+EVx/EIAInU53IEc95TPnCjl1EXvPuI
jLcpShzPIEBphY0e3FsLu2MTK9QvJHaj/tsuL3HeQoNuszJ5uGEHUIaKw0PfY9G9
UAFFAufTQiMU99VcjpyMY5r6Mcx1h37thlutr74QfkoppKCAF2HRvcAvn+IDsn0Q
CmWTjzwpyicaqE+CgMGixzu0FQOICatHgDcTxjBpV8LsV8Lf7QNwBwBhspRT5R97
Q2ydKUYBUZZyNHtFCIxauujAC40qAGdfOYwpUAkAkMdN2wbzvKR4DY6ld56fc1uZ
UFr8qfk90cdKXS7WEdBD7cflYltr6N2JoX1sqJYYDtQpED/mdAYwo+kogmWfv2s=
=zTYI
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSG][OSSN] Multiple Cinder drivers set insecure file permissions

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Multiple Cinder drivers set insecure file permissions
- ---

### Summary ###
Several Cinder volume drivers set insecure file permissions for various
files and directories. These permissions render the files accessible for
read and write to any user with access to the Cinder host as well as any
processes running on it. This exposes user block storage data to
potential disclosure, corruption, or destruction.

### Affected Services / Software ###
Cinder, Folsom, Grizzly, Havana, Icehouse

### Discussion ###
Several Cinder drivers set file permissions that allow read and write
access to 'group' and 'others'. Affected drivers include:

 - GPFS
 - GlusterFS
 - Huawei
 - NetApp/NFS
 - Nexenta
 - NFS
 - Scality

Essentially, user volumes are made accessible to all who have access to
the Cinder host. Daemons running on the host are also able to access the
affected user volumes. The relaxed file permissions can be exploited to
disclose, modify, corrupt, or destroy user volume data.

All versions of Cinder are vulnerable in Icehouse and earlier releases
with a single exception: systems using the Icehouse GPFS driver.

This issue was reported by Dirk Mueller of SUSE.

### Recommended Actions ###
The GPFS driver in the Icehouse release fixes the file permissions issue
and also executes shell commands in non-root mode where possible.
Unfortunately, it is not practical to back-port the fix for the GPFS
driver to earlier OpenStack releases. It is anticipated that the other
affected drivers will be fixed in the OpenStack Juno release.

It is not possible to simply modify the file permissions to mitigate
the issue, as several of the affected drivers currently require the
relaxed file permissions to function. Additionally, file manipulation
cannot be uniformly restricted to a non-root user because often times a
file may be created on one host using one uid, but mounted on another
host using a different uid.

You can check what drivers are being used by Cinder by executing the
following command on your Cinder host:

  > grep "^volume_driver" /etc/cinder/cinder.conf

You should compare the results of the above command against the list of
known vulerable drivers in the "Discussion" section above to see if you
are affected. If you are running the Icehouse version of Cinder and the
GPFS driver is the only driver in use, your Cinder system is not
vulnerable to this issue.

In the likely scenario that your system is vulnerable, you should limit
access to the Cinder host as much as possible.  You should also explore
alternatives such as applying mandatory access control policies
(SELinux, AppArmor, etc) or using NFS uid squashing to control access
to the files in order to minimize the possible exposure.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0014
Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1260679
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTifNXAAoJEJa+6E7Ri+EVb54H/2dAiAEQfSDRXOFBKhxJ0seV
dpwZrM8bylxYB5w5CwsOJpAu1L8XLHnEtYKYeddL8ygzMkm27ACQHru+4oe4y9YD
04tWq2mSlz/QUEtdyKDcfa4Se1sT4hccfvvqMTgoi6q2UF2OueHdAH9XDc0xSuFI
Kd8toGRuoTifphWgLviDyQtTynhW2fVF6vIMdI5nEf42HgHM8FMdTCEBjkXILy9+
lSTT14A3vuVf4JaWHLuuGqFOkxtLdKKHGrmu44l9Xo9cHUHt3R16VFCPbk4db4oA
8+cqxpzHSVkWkyJm/gKVFvBzFFxaz4MDnWVR1p2/pCCvKPQ7ARYrcVmEJNZ6HrY=
=pm4b
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-security] [Barbican][OSSG][Keystone] Mid-Cycle Meetup

[Nathan Kinder]

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-secur...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-docs] [Doc] [ceilometer] [cinder] [glance] [heat] [horizon] [keystone] [neutron] [nova] [swift] [trove] Atlanta Summit – Discuss docs process and tool improvements

[Nathan Kinder]

On 05/08/2014 09:42 AM, Anne Gentle wrote:
> 
> 
> 
> On Wed, May 7, 2014 at 1:43 PM, Roger Luethi  > wrote:
> 
> On Wed, 07 May 2014 09:16:48 -0700, Anne Gentle wrote:
> > Why not? The responses to my recent survey about doc contributions
> indicate
> > that the top barriers to docs’ contributions are:
> >
> > - Tools: DocBook and WADL are difficult
> 
> DocBook may be a pain to set up, but editing DocBook documents is hardly
> more difficult than Markdown, RST or any other solution will be by
> the time
> you have added all the features you want to have.
> 
> 
> Yep, I realize DocBook fulfills many if not all of the requirements,
> plus it's what's used within much of RedHat and we have a translation
> toolchain built for it. These are compelling except for the survey
> results indicating it's a barrier. 
> 
> I'd like to stick to discussion of the requirements. I just named two
> possible requirements, should those be included as well? 
> 
> Thanks for the input Roger, you're exactly who we're trying to reach out
> to for docs, and your input is super valuable.
> 
> Anne
>  
> 
> 
> Formatting docs is hard because the style guides demand that numerous
> rules be considered. Ditching DocBook won't change that.
> 
> > - Subject-matter expertise: People do not have test environments
> and they
> > feel that they don't know enough to contribute. Also, 70% of the
> > respondents to the survey work on or consume OpenStack fewer than
> 10 hours
> > a week.
> 
> The people who are qualified to contribute to the docs are usually not
> non-technical people, but they can't spend hours setting up an
> environment
> just to work on docs. IMHO good documentation (or scripts, or VM
> downloads)
> that make it easy to create a complete, working environment for
> testing and
> building documentation would go a long way towards making contributions
> easier.

+1.  Anything that can be done to reduce the barrier to entry for doc
contributions would really help.  I think that it would also ease the
burden on the existing doc folks too, as they wouldn't be answering the
same questions on how to get started for new doc contributors.

-NGK

> 
> Roger
> 
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN

[Nathan Kinder]

On 05/08/2014 03:19 AM, Samuel Bercovici wrote:
> Hi,
> 
>  
> 
> Please note as commented also by other XaaS services that managing SSL
> certificates is not a sole LBaaS challenge.
> 
> This calls for either an OpenStack wide service or at least a Neutron
> wide service to implement such use cases.
> 
>  
> 
> So it here are the options as far as I have seen so far.
> 
> 1.   Barbican as a central service to store and retrieve SSL
> certificates. I think the Certificates generation is currently a lower
> priority requirement
> 
> 2.   Using Heat as a centralized service
> 
> 3.   Implementing such service in Neutron
> 
> 4.   LBaaS private implementation
> 
>  
> 
> BTW, on all the options above, Barbican can optionally be used to store
> the certificates or the private part of the certificates.

It's really just private keys you need to be concerned about, not
certificates themselves (which are really just a signed public key plus
other public data like the subject, issuer, and validity).

> 
>  
> 
> I think that we either follow option 3 if SSL management is only a
> Neutron requirement (LBaaS, VPNaaS, FWaaS) and maybe as a transition
> project to an OpenStack wide solution (1 or 2).

I'd be concerned about implementing a separate service when this clearly
falls into Barbican's target use-cases.  We should be moving towards
centralizing security related functionality like this instead of having
multiple implementations of similar functionality.

> 
> Option 1 or 2 might be the ultimate goal.

I think 1 should be the ultimate goal.  Barbican is designed for
securely storing keys, which is exactly what you are trying to do.

Thanks,
-NGK

> 
>  
> 
> Regards,
> 
> -Sam.
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> *From:*Clark, Robert Graham [mailto:robert.cl...@hp.com]
> *Sent:* Thursday, May 08, 2014 12:43 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert
> implementation for LBaaS and VPN
> 
>  
> 
> The certificate management that LBaaS requires might be slightly
> different to the normal flow of things in OpenStack services, after all
> you are talking about externally provided certificates and private keys.
> 
>  
> 
> There’s already a standard for a nice way to bundle those two elements
> together, it’s described in PKCS#12 and you’ve likely come across it in
> the form of ‘.pfx’ files. I’d suggest that perhaps it would make sense
> for LBaaS to store pfx files in the LBaaS DB and store the key for the
> pfx files in Barbican. You could probably store them together in
> Barbican, using containers if you really wanted to
> (https://blueprints.launchpad.net/barbican/+spec/crud-endpoints-secret-container)
> 
> 
>  
> 
> -Rob
> 
>  
> 
> *From:*Carlos Garza [mailto:carlos.ga...@rackspace.com]
> *Sent:* 08 May 2014 04:30
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert
> implementation for LBaaS and VPN
> 
>  
> 
>  
> 
> On May 7, 2014, at 10:53 AM, Samuel Bercovici  > wrote:
> 
>  
> 
> Hi John,
> 
>  
> 
> If the user already has an SSL certificate that was acquired outside
> of the barbican Ordering system, how can he store it securely in
> Barbican as a SSL Certificate?
> 
> The Container stored this information in a very generic way, I think
> that there should be an API that formalizes a specific way in which
> SSL certificates can be stored and read back as SSL Certificates and
> not as loosely coupled container structure.
> 
> This such API should have RBAC that allows getting back only the
> public part of an SSL certificate vs. allowing to get back all the
> details of the SSL certificate.
> 
>  
> 
> Why the need for that complexity? The X509s are public by nature and
> don't need to be stored in Barbican so there isn't really a private part
> of the certificate. The actual private key itself is what needs to be
> secured so I would advocate that the private key is what will be stored
> in barbican. I also think we should also declare that the private key
> need not be an RSA key as x509 supports other asymmetric encryption
> types so storing as a generic blob in barbican is probably a good idea.
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> -Sam.
> 
>  
> 
>  
> 
>  
> 
> *From:* John Wood [mailto:john.w...@rackspace.com
> ] 
> *Sent:* Thursday, May 01, 2014 11:28 PM
> *To:* OpenStack Development Mailing List (not for usage questions);
> os.v...@gmail.com 
> *Subject:* Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL
> cert implementation for LBaaS and VPN
> 
>  
> 
> Hello Samuel,
> 
>  
> 
> Just noting that the link below shows current-state Barbican. We are
> in th

[openstack-dev] [OSSG][OSSN] Some versions of Glance do not apply property protections as expected

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Some versions of Glance do not apply property protections as expected
- ---

### Summary ###
Tom Leaman reported an issue to the OpenStack mailing list that affects
Glance property protections. A permissive property setting in the Glance
property protections configuration file will override any previously set
stricter ones.

### Affected Services / Software ###
Glance, Folsom, Grizzly

### Discussion ###
Glance property protections limit the users who can perform CRUD
operations on a Glance property to those in specific roles. If there is
a specific rule that would reject an action and a less specific rule
that comes after that accepts the action, then the action is accepted
even though one may expect it to be rejected.

This bug only affects the use of user-roles in Glance. It does not occur
when policies are used to determine property protections.

In the following policy-protections.conf example, the desired result is
to restrict 'update' and 'delete' permissions for 'foo_property' to only
users with the 'admin' role.

- --- Begin Example ---
/etc/glance/property-protections.conf
[^foo_property$]
create = @
read = @
update = admin
delete = admin

[.*]
create = @
read = @
update = @
delete = @
- --- End Example ---

Due to the order that the rules are applied in the Folsom and Grizzly
OpenStack releases, the admin restriction for 'foo_property' is
nullified by the '.*' permissions. This results in all roles being
allowed the 'update' and 'delete' permissions on 'foo_property', which
is not what was intended.

### Recommended Actions ###
This issue has been fixed in Havana (Glance 2013.2.2) and subsequent
releases.

Users of affected releases should review and reorder the entries in
property-protections.conf to place the most open permissions at the
start of the configuration and more restrictive ones at the end, as
demonstrated below.

- --- Begin Example ---
/etc/Glance/property-protections.conf
[.*]
create = @
read = @
update = @
delete = @

[^foo_property$]
create = @
read = @
update = admin
delete = admin
- --- End Example ---

In the above example, '.*' and 'foo_property' entries in the protections
file have been reversed, ensuring that the more restrictive permissions
required for 'foo_property' are applied after the wider '.*' permissions
and assuring that 'update' and 'delete' operations are restricted to
only users with in the 'admin' role.

Configuration files with multiple property protection entries set should
be tested to ensure that CRUD actions are constrained in the way the
administrator intended.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0013
Original Launchpad Bug : https://bugs.launchpad.net/glance/+bug/1271426
Original Report :
http://lists.openstack.org/pipermail/openstack-dev/2014-January/024861.html
Glance Property Protections :
https://wiki.openstack.org/wiki/Glance-property-protections
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTarcQAAoJEJa+6E7Ri+EVEA4H/1VmKV7XvaubtwtXKvJf20fi
lV42zkpA+WQrxnxOWa05Z8TMCKGN/q3EuNYIcOjSe9hiGS3tuHAyFq/lnD+mQwJn
rc+vwr6234/BWlTnV1iuXemzXrBTKlNNk+4th5L0KLujPwUw9U2cLssJxkhfB98f
39SuUe5kmS62tPvvqJQ25yRDal0umP38NDusfTJNcfVu7Ybq3XxdUxQAinfDyiEl
piIGkKA276ZeTHX6U1DZpGJpy9pfA7yxSavNNJEHN8ABnFQJZPxz1Q4E5uEZRPBq
LQE0rcF8r0Wi0/vsHbEiU71UpTTKBcLK13Os4rNirHVvh+SXf0grvfUP5D0+DP4=
=CC5L
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][olso] How is the trusted message going on?

[Nathan Kinder]

On 05/05/2014 03:29 PM, Jiang, Yunhong wrote:
> Hi, all
>   The trusted messaging 
> (https://blueprints.launchpad.net/oslo.messaging/+spec/trusted-messaging) has 
> been removed from icehouse, does anyone know how is current status? I noticed 
> a summit session may cover it ( 
> http://junodesignsummit.sched.org/event/9a6b59be11cdeaacfea70fef34328931#.U2gMo_ldWrQ
>  ), but would really appreciate if anyone can provide some information.
> 

There is also an oslo.messaging session that has the trusted messaging
blueprint on the agenda:


http://junodesignsummit.sched.org/event/f3abf1f9d8ce7558a020fcd9ba07d166#.U2hS7jn5Gho

The "key distribution service" mentioned in the blueprint referenced
above has become the Kite project, which is currently working it's way
through implementation under the Barbican program.  I recently wrote up
an overview of how it works here:

  https://blog-nkinder.rhcloud.com/?p=62

I'm hoping to be able to discuss the changes that would be needed to
oslo.messaging to take advantage of Kite (or a different message
security approach like the PKI one mentioned in Adam's design session
proposal) at the Summit.  If we can use a plug-in approach in
oslo.messaging, then different message security mechanisms could be
swapped out relatively easily (in theory).

Thanks,
-NGK

> Thanks
> --jyh
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [barbican] Cryptography audit by OSSG

[Nathan Kinder]

On 04/18/2014 06:55 AM, Lisa Clark wrote:
> Barbicaneers,
> 
>Is anyone following the openstack-security list and/or part of the
> OpenStack Security Group (OSSG)?  This sounds like another group and list
> we should keep our eyes on.
> 
>In the below thread on the security list, Nathan Kinder is conducting a
> security audit of the various integrated OpenStack projects.  He's
> answering questions such as what crypto libraries are being used in the
> projects, algorithms used, sensitive data, and potential improvements that
> can be made.  Check the links out in the below thread.
> 
>Though we're not yet integrated, it might be beneficial to put together
> our security audit page under Security/Icehouse/Barbican.

I've started a page for you (but for Juno).  There is a lot to fill in
still (by folks more familiar with the Barbican code than I), but it's a
start.

https://wiki.openstack.org/wiki/Security/Juno/Barbican

It would be great if the Barbican team can fill this in and keep it up
to date as development continues.

I've also added the rest of the projects currently in incubation on the
top-level Security page for Juno in case other projects are interested
in filling in their info as well:

https://wiki.openstack.org/wiki/Security/Juno

Thanks,
-NGK

> 
>Another thing to consider as you're reviewing the security audit pages
> of Keystone and Heat (and others as they are added): Would Barbican help
> to solve any of the security concerns/issues that these projects are
> experiencing?
> 
> -Lisa
> 
>>
>> Message: 5
>> Date: Thu, 17 Apr 2014 16:27:30 -0700
>> From: Nathan Kinder 
>> To: "Bryan D. Payne" , "Clark, Robert Graham"
>>  
>> Cc: "openstack-secur...@lists.openstack.org"
>>  
>> Subject: Re: [Openstack-security] Cryptographic Export Controls and
>>  OpenStack
>> Message-ID: <53506362.3020...@redhat.com>
>> Content-Type: text/plain; charset=windows-1252
>>
>> On 04/16/2014 10:28 AM, Bryan D. Payne wrote:
>>> I'm not aware of a list of the specific changes, but this seems quite
>>> related to the work that Nathan has started played with... discussed on
>>> his blog here:
>>>
>>> https://blog-nkinder.rhcloud.com/?p=51
>>
>> This is definitely related to the security audit effort that I'm
>> driving.  It's hard to make recommendations on configurations and
>> deployment architectures from a security perspective when we don't even
>> have a clear picture of the current state of things are in the code from
>> a security standpoint.  This clear picture is what I'm trying to get to
>> right now (along with keeping this picture up to date so it doesn't get
>> stale).
>>
>> Once we know things such as what crypto algorithms are used and how
>> sensitive data is being handled, we can see what is configurable and
>> make recommendations.  We'll surely find that not everything is
>> configurable and sensitive data isn't well protected in areas, which are
>> things that we can turn into blueprints and bugs and work on improving
>> in development.
>>
>> It's still up in the air as to where this information should be
>> published once it's been compiled.  It might be on the wiki, or possibly
>> in the documentation (Security Guide seems like a likely candidate).
>> There was some discussion of this with the PTLs from the Project Meeting
>>from 2 weeks ago:
>>
>>
>> http://eavesdrop.openstack.org/meetings/project/2014/project.2014-04-08-21
>> .03.html
>>
>> I'm not so worried myself about where this should be published, as that
>> doesn't matter if we don't have accurate and comprehensive information
>> collected in the first place.  My current focus is on the collection and
>> maintenance of this info on a project by project basis.  Keystone and
>> Heat have started, which is great!:
>>
>>  https://wiki.openstack.org/wiki/Security/Icehouse/Keystone
>>  https://wiki.openstack.org/wiki/Security/Icehouse/Heat
>>
>> If any other OSSG members are developers on any of the projects, it
>> would be great if you could help drive this effort within your project.
>>
>> Thanks,
>> -NGK
>>>
>>> Cheers,
>>> -bryan
>>>
>>>
>>>
>>> On Tue, Apr 15, 2014 at 1:38 AM, Clark, Robert Graham
>>> mailto:robert.cl...@hp.com>> wrote:
>>>
>>> Does anyone have a documented run-down of changes that must be made
>>> to Open

Re: [openstack-dev] [Neutron][LBaaS] Use Case Question

[Nathan Kinder]

On 04/25/2014 12:50 AM, Carlos Garza wrote:
> Trevor is referring to our plans on using the SSL session ID of the
> ClientHello to provide session persistence.
> See RFC 5264 section 7.4.1.2 which sends an SSL session ID in the clear
> (Unencrypted) so that a load balancer with out the decrypting key can
> use it to make decisions on which
> back end node to send the request to.  Users browsers while typically
> use the same session ID for a while between connections. 

This is a nice approach, as it eliminates the need to decrypt/encrypt on
the load balancer.  I know that HAProxy has the ability to do this, so
it's definitely possible.

I do recall reading that the session ID isn't always sent as a part of
the client hello, so you would need to check the server hello as well.
If there is a blueprint on this, it would be good to make sure it
mentions that the server hello should be checked as well.

> 
> Also note this is supported in TLS 1.1 as well in the same section
> according to RFC 4346. And in TLS 1.0 RFC2246 as well.
> 
> So we have the ability to offer http cookie based persistence as you
> described only if we have the key but if not we can also offer SSL
> Session Id based persistence.

One other use-case that calls for re-encrypting on the load balancer is
when you want to use different certificates on the backend network (such
as a completely separate internal PKI).

I wrote up some thoughts on SSL/TLS with load balancers for the API
endpoints a few weeks ago.  It wasn't related to LBaaS, but I think it's
applicable.  It specifically discusses affinity via SSL/TLS session ID
as well as separate backend PKI use cases:

https://blog-nkinder.rhcloud.com/?p=7

I think the important take away is that everyone has different security
requirements, which requires flexibility.  There are arguments to be
made for termination at the load balancer, passing SSL/TLS through the
load balancer, and re-encryption at the load balancer.  Providing
support for all of these should be the goal.

Thanks,
-NGK

> 
> 
> 
> On Apr 24, 2014, at 7:53 PM, Stephen Balukoff  > wrote:
> 
>> Hi Trevor,
>>
>> If the use case here requires the same client (identified by session
>> cookie) to go to the same back-end, the only way to do this with HTTPS
>> is to decrypt on the load balancer. Re-encryption of the HTTP request
>> may or may not happen on the back-end depending on the user's needs.
>> Again, if the client can potentially change IP addresses, and the
>> session still needs to go to the same back-end, the only way the load
>> balancer is going to know this is by decrypting the HTTPS request. I
>> know of no other way to make this work.
>>
>> Stephen
>>
>>
>> On Thu, Apr 24, 2014 at 9:25 AM, Trevor Vardeman
>> mailto:trevor.varde...@rackspace.com>>
>> wrote:
>>
>> Hey,
>>
>> I'm looking through the use-cases doc for review, and I'm confused
>> about one of them.  I'm familiar with HTTP cookie based session
>> persistence, but to satisfy secure-traffic for this case would
>> there be decryption of content, injection of the cookie, and then
>> re-encryption?  Is there another session persistence type that
>> solves this issue already?  I'm copying the doc link and the use
>> case specifically; not sure if the document order would change so
>> I thought it would be easiest to include both :)
>>
>> Use Cases:
>>  
>> https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis
>>
>> Specific Use Case:  A project-user wants to make his secured web
>> based application (HTTPS) highly available. He has n VMs deployed
>> on the same private subnet/network. Each VM is installed with a
>> web server (ex: apache) and content. The application requires that
>> a transaction which has started on a specific VM will continue to
>> run against the same VM. The application is also available to
>> end-users via smart phones, a case in which the end user IP might
>> change. The project-user wishes to represent them to the
>> application users as a web application available via a single IP.
>>
>> -Trevor Vardeman
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> -- 
>> Stephen Balukoff
>> Blue Box Group, LLC
>> (800)613-4305 x807
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

Re: [openstack-dev] [barbican] Cryptography audit by OSSG

[Nathan Kinder]

On 04/18/2014 09:27 AM, Bryan D. Payne wrote:
>Is anyone following the openstack-security list and/or part of the
> OpenStack Security Group (OSSG)?  This sounds like another group and
> list
> we should keep our eyes on.
> 
> 
> I'm one of the OSSG leads.  We'd certainly welcome your involvement in
> OSSG.  In fact, there has been much interest in OSSG about the Barbican
> project.  And I believe that many people from the group are contributing
> to Barbican.
>  
> 
>    In the below thread on the security list, Nathan Kinder is
> conducting a
> security audit of the various integrated OpenStack projects.  He's
> answering questions such as what crypto libraries are being used in the
> projects, algorithms used, sensitive data, and potential
> improvements that
> can be made.  Check the links out in the below thread.
> 
>Though we're not yet integrated, it might be beneficial to put
> together
> our security audit page under Security/Icehouse/Barbican.
> 
> 
> This would be very helpful.  If there's anything I can do to help
> facilitate this, just let me know.

I'd definitely welcome this as well.  The integrated projects seemed
like a good place to start to me, but getting on board early with
incubated projects like Barbican would be great.  I'm happy to assist in
any way I can.

-NGK

> 
> Cheers,
> -bryan
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSG][OSSN] Sample Keystone v3 policy exposes privilege escalation vulnerability

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sample Keystone v3 policy exposes privilege escalation vulnerability
- ---

### Summary ###
The policy.v3cloudsample.json sample Keystone policy file combined with
the underlying mutability of the domain ID for user, group, and project
entities exposed a privilege escalation vulnerability.  When this
sample policy is applied a domain administrator can elevate their
privileges to become a cloud administrator.

### Affected Services / Software ###
Keystone, Havana

### Discussion ###
Changes to the Keystone v3 sample policy during the Havana release cycle
set an excessively broad domain administrator scope that allowed
creation of roles ("create_grant") on other domains (among other
actions).  There was no check that the domain administrator had
authority to the domain they were attempting to grant a role on.

Combining the mutable state of the domain ID for user, group, and
project entities with the sample v3 policy resulted in a privilege
escalation vulnerability.  A domain administrator could execute a series
of steps to escalate their access to that of a cloud administrator.

### Recommended Actions ###
Review the following updated sample v3 policy file from the OpenStack
Icehouse release:

https://git.openstack.org/cgit/openstack/keystone/commit/?id=0496466821c1ff6e7d4209233b6c671f88aadc50

You should ensure that your Keystone deployment appropriately reflects
that update.  Domain administrators should generally only be permitted
to perform actions against the domain for which they are an
administrator.

Optionally, review the recent addition of support for immutable domain
IDs and consider it for applicability to your Keystone deployment:

https://git.openstack.org/cgit/openstack/keystone/commit/?id=a2fa6a6f01a4884edf369cafa39946636af5cf1a

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0010
Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1287219
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTUCuwAAoJEJa+6E7Ri+EVvxwIAKsOIp4gBotwIO9yxTf3y4wF
C7nVi/y5JwwQmzxAHGtMCBn/M6xH8GygMz0P4HWO8B9cI8HWdxpFHy+/504ShTLV
E+ZMNbuJJ6FriKy6HASonfmleHguCT8fWsv5FvHjKsZnBjEY54OYP7Xnw4Kio4rZ
TpCja+vc3IrDnCwqoMHySjD8qSWZLsuYr/klo+AUEt0lry06Zr62Tgb7S6sqYrBn
mcbO0VJ0+89frcyVD4v6aONNX9OcqkQfH0lnriWT2Vyax6+s4DnOqAvsFy8Rdqdf
xWGBkRa7ejDUel5Jgzh9GUwrsk2tpcIpiHh1qXGjgTr8K8xmVu6zaxHE7Cm8wHY=
=l8Lr
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Security audit of OpenStack projects

[Nathan Kinder]

On 04/10/2014 09:48 AM, Russell Bryant wrote:
> On 04/10/2014 11:39 AM, Steven Hardy wrote:
>> On Mon, Apr 07, 2014 at 09:06:23AM -0700, Nathan Kinder wrote:
>>> Hi,
>>>
>>> We don't currently collect high-level security related information about
>>> the projects for OpenStack releases.  Things like the crypto algorithms
>>> that are used or how we handle sensitive data aren't documented anywhere
>>> that I could see.  I did some thinking on how we can improve this.  I
>>> wrote up my thoughts in a blog post, which I'll link to instead of
>>> repeating everything here:
>>>
>>>   http://blog-nkinder.rhcloud.com/?p=51
>>>
>>> tl;dr - I'd like to have the development teams for each project keep a
>>> wiki page updated that collects some basic security information.  Here's
>>> an example I put together for Keystone for Icehouse:
>>>
>>>   https://wiki.openstack.org/wiki/Security/Icehouse/Keystone
>>>
>>> There would need to be an initial effort to gather this information for
>>> each project, but it shouldn't be a large effort to keep it updated once
>>> we have that first pass completed.  We would then be able to have a
>>> comprehensive overview of this security information for each OpenStack
>>> release, which is really useful for those evaluating and deploying
>>> OpenStack.
>>>
>>> I see some really nice benefits in collecting this information for
>>> developers as well.  We will be able to identify areas of weakness,
>>> inconsistency, and duplication across the projects.  We would be able to
>>> use this information to drive security related improvements in future
>>> OpenStack releases.  It likely would even make sense to have something
>>> like a cross-project security hackfest once we have taken a pass through
>>> all of the integrated projects so we can have some coordination around
>>> security related functionality.
>>>
>>> For this to effort to succeed, it needs buy-in from each individual
>>> project.  I'd like to gauge the interest on this.  What do others think?
>>>  Any and all feedback is welcome!
>>
>> I think this is a good idea, and hopefully can provide valuable insight
>> into common pain-points or areas for improvement.
> 
> Huge +1.  I think tracking this information is very valuable.
> 
>> I've made a start on a page for Heat, feedback welcome!
>>
>> https://wiki.openstack.org/wiki/Security/Icehouse/Heat
> 
> I wonder if it would be easier to keep up if we restructure this a bit.

I'm all for restructuring.  These are the details we need to hash out to
determine what makes sense across all of the projects.  I see two main
viewpoints that we need to keep in mind when determining how to handle this:

- Maintenance should be easy for developers to keep the information up
to date and in sync with the code with minimal overhead.

- Consumption of the documentation should be easy for those evaluating
and deploying OpenStack.

>  In particular, I'm wondering if having a project-specific page that
> isn't version specific would be easier.  It could just contain version
> pointers where appropriate.

The downside with this is that the page starts to get confusing/complex
after a number of releases.  It's not going to provide a concise picture
of a given release 5 releases from now.

I was thinking that this should be similar to a source control branching
model.  A project would be updating this information for the trunk, then
branching when we near a release.  This effectively provides a snapshot
of the security information for a particular release, which should only
need to be updated if we backport code changes that necessitate a
documentation change.  The size of the document will not get out of hand
over many releases, but we will just have different versions of the
document for different releases.  This model could be seen as an
argument for keeping the doc in-tree with the source code, which we
could then publish for easier consumption by non-developers (wiki and/or
the OpenStack Security Guide).

> 
> In the case of Nova, we already have a number of sub-pages under
> wiki/Nova, so I think a wiki/Nova/Security page would make sense.
> 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSG][OSSN] OpenSSL Heartbleed vulnerability can lead to OpenStack compromise

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Heartbleed vulnerability can lead to OpenStack compromise
- ---

### Summary ###
A vulnerability in OpenSSL can lead to leaking of confidential data
protected by SSL/TLS in an OpenStack deployment.

### Affected Services / Software ###
Grizzly, Havana, OpenSSL

### Discussion ###
A vulnerability in OpenSSL code-named Heartbleed was recently discovered
that allows remote attackers limited access to data in the memory of any
service using OpenSSL to provide encryption for network communications.
This can include key material used for SSL/TLS, which means that any
confidential data that has been sent over SSL/TLS may be compromised.
For full details, see the following website that describes this
vulnerability in detail:

http://heartbleed.com/

While OpenStack software itself is not directly affected, any deployment
of OpenStack is very likely using OpenSSL to provide SSL/TLS
functionality.

### Recommended Actions ###
It is recommended that you immediately update OpenSSL software on the
systems you use to run OpenStack services.  In most cases, you will want
to upgrade to OpenSSL version 1.0.1g, though it is recommended that you
review the exact affected version details on the Heartbleed website
referenced above.

After upgrading your OpenSSL software, you will need to restart any
services that use the OpenSSL libraries.  You can get a list of all
processes that have the old version of OpenSSL loaded by running the
following command:

lsof | grep ssl | grep DEL

Any processes shown by the above command will need to be restarted, or
you can choose to restart your entire system if desired.  In an
OpenStack deployment, OpenSSL is commonly used to enable SSL/TLS
protection for OpenStack API endpoints, SSL terminators, databases,
message brokers, and Libvirt remote access.  In addition to the native
OpenStack services, some commonly used software that may need to be
restarted includes:

  Apache HTTPD
  Libvirt
  MySQL
  Nginx
  PostgreSQL
  Pound
  Qpid
  RabbitMQ
  Stud

It is also recommended that you treat your existing SSL/TLS keys as
compromised and generate new keys.  This includes keys used to enable
SSL/TLS protection for OpenStack API endpoints, databases, message
brokers, and libvirt remote access.

In addition, any confidential data such as credentials that have been
sent over a SSL/TLS connection may have been compromised.  It is
recommended that cloud administrators change any passwords, tokens, or
other credentials that may have been communicated over SSL/TLS.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0012
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
Heartbleed Website: http://heartbleed.com/
CVE: CVE-2014-0160
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTRkbnAAoJEJa+6E7Ri+EVITYH/A5TQlCCAuK0+6ZWxRAC+KYC
x0SCGNS9v4eArDAijnt1KmdAvh83hWXsM34my1/S3L8zjmYaE2MBBotcj7Du8znV
N+i9JLG6Zr3kOONv5AfnNdeOm/qaVpNugRSRj1SQ/OvIO2VkybAwFLKBZezCfk8D
VSoAdnpiHlR9tPqxPlqWHqtNXf3CZjQ486DhuCaVFD0VsRi+YZQk3U6b81+kwpUT
32O7BqeQ/yzJZ6dDIl9qwIb+j6BznDY8lokaW40wzw/ec3E8Rqs89D9gGIgob9/Q
ZqparwBLjqFEUVNni7xqUAVlocAKhDxFaWr49AbVR/mYqPkbTLIn6pkLS6eH8VU=
=R1bD
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Security audit of OpenStack projects

[Nathan Kinder]

Hi,

We don't currently collect high-level security related information about
the projects for OpenStack releases.  Things like the crypto algorithms
that are used or how we handle sensitive data aren't documented anywhere
that I could see.  I did some thinking on how we can improve this.  I
wrote up my thoughts in a blog post, which I'll link to instead of
repeating everything here:

  http://blog-nkinder.rhcloud.com/?p=51

tl;dr - I'd like to have the development teams for each project keep a
wiki page updated that collects some basic security information.  Here's
an example I put together for Keystone for Icehouse:

  https://wiki.openstack.org/wiki/Security/Icehouse/Keystone

There would need to be an initial effort to gather this information for
each project, but it shouldn't be a large effort to keep it updated once
we have that first pass completed.  We would then be able to have a
comprehensive overview of this security information for each OpenStack
release, which is really useful for those evaluating and deploying
OpenStack.

I see some really nice benefits in collecting this information for
developers as well.  We will be able to identify areas of weakness,
inconsistency, and duplication across the projects.  We would be able to
use this information to drive security related improvements in future
OpenStack releases.  It likely would even make sense to have something
like a cross-project security hackfest once we have taken a pass through
all of the integrated projects so we can have some coordination around
security related functionality.

For this to effort to succeed, it needs buy-in from each individual
project.  I'd like to gauge the interest on this.  What do others think?
 Any and all feedback is welcome!

Thanks,
-NGK

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSG][OSSN] Heat templates with invalid references allows unintended network access

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Heat templates with invalid references allows unintended network access
- ---

### Summary ###
Orchestration templates can create security groups to define network
access rules.  When creating these rules, it is possible to have a rule
grant incoming network access to instances belonging to another security
group.  If a rule references a non-existent security group, it can
result in allowing incoming access to all hosts for that rule.

### Affected Services / Software ###
Heat, nova-network, Havana

### Discussion ###
When defining security groups of the "AWS::EC2::SecurityGroup" type in a
CloudFormation-compatible format (CFN) orchestration template, it is
possible to use references to other security groups as the source for
ingress rules.  When these rules are evaluated by Heat in the OpenStack
Havana release, a reference to a non-existent security group will be
silently ignored.  This results in the rule using a "CidrIp" property of
"0.0.0.0/0".  This will allow incoming access to any host for the
affected rule.  This has the effect of allowing unintended network
access to instances.

This issue only occurs when Nova is used for networking (nova-network).
The Neutron networking service is not affected by this issue.

The OpenStack Icehouse release is not affected by this issue.  In the
Icehouse release, Heat will check if a non-existent security group is
referenced in a template and return an error, causing the creation of
the security group to fail.

### Recommended Actions ###
If you are using Heat in the OpenStack Havana release with Nova for
networking (nova-network), you should review your orchestration
templates to ensure that all references to security groups in ingress
rules are valid.  Specifically, you should look at the use of the
"SourceSecurityGroupName" property in your templates to ensure that
all referenced security groups exist.

One particular improper usage of security group references that you
should look for is the case where you define multiple security groups
in one template and use references between them.  In this case, you
need to make sure that you are using the "Ref" intrinsic function to
indicate that you are referencing a security group that is defined in
the same template.  Here is an example of a template with a valid
security group reference:

-  begin example correct template snippet 
"WikiDatabaseSecurityGroup" : {
  "Type" : "AWS::EC2::SecurityGroup",
  "Properties" : {
"GroupDescription" : "Enable HTTP access plus SSH access",
"SecurityGroupIngress" : [
  {
"IpProtocol" : "icmp",
"FromPort" : "-1",
"ToPort" : "-1",
"CidrIp" : "10.1.1.0/24"
  },
  {
"IpProtocol" : "tcp",
"FromPort" : "80",
"ToPort" : "80",
"CidrIp" : "10.1.1.0/24"
  },
  {
"IpProtocol" : "tcp",
"FromPort" : "22",
"ToPort" : "22",
"CidrIp" : "10.1.1.0/24"
  },
  {
"IpProtocol" : "tcp",
"FromPort" : "3306",
"ToPort" : "3306",
"SourceSecurityGroupName" : {
  "Ref": "WebServerSecurityGroup"
}
  }
]
  }
},

"WebServerSecurityGroup" : {
  "Type" : "AWS::EC2::SecurityGroup",
  "Properties" : {
"GroupDescription" : "Enable HTTP access plus SSH access",
"SecurityGroupIngress" : [
  {
"IpProtocol" : "icmp",
"FromPort" : "-1",
"ToPort" : "-1",
"CidrIp" : "10.1.1.0/24"
  },
  {
"IpProtocol" : "tcp",
"FromPort" : "80",
"ToPort" : "80",
"CidrIp" : "10.1.1.0/24"
  },
  {
"IpProtocol" : "tcp",
"FromPort" : "22",
"ToPort" : "22",
"CidrIp" : "10.1.1.0/24"
  }
]
  }
},
-  end example correct template snippet 

Here is an example of an incorrect reference to a security group defined
in the same template:

-  begin example INVALID template snippet 
  {
"IpProtocol" : "tcp",
"FromPort" : "3306",
"ToPort" : "3306",
"SourceSecurityGroupName" : "WebServerSecurityGroup" #INCORRECT!
  }
-  end example INVALID template snippet 

The above invalid reference will result in allowing incoming networking
on port 3306 from all hosts:

IP Protocol | From Port | To Port | IP Range| Source Group |
  +-+---+-+-+--+
  |icmp |-1 |  -1 | 10.1.1.0/24 |  |
  | tcp |80 |  80 | 10.1.1.0/24 |  |
  | tcp |22 |  22 | 10.1.1.0/24 |  |
  | tcp |  3306 |3306 |   0.0.0.0/0 |  |
  +-+---+-+-+--+

It is also recommended that you test your templates if you are using
security group references to ensure that the resulting network rules
are as intended.

### Contacts / References ###
This OSSN : 

[openstack-dev] [OSSG][OSSN] Potential token revocation abuse via group membership

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Potential token revocation abuse via group membership
- ---

### Summary ###
Deletion of groups in Keystone causes token revocation for group
members.  If group capabilities are delegated to users, they can abuse
those capabilities to maliciously revoke tokens for other users.

### Affected Services / Software ###
Keystone, Grizzly, Havana, Icehouse

### Discussion ###
If a group is deleted from Keystone, all tokens for all users that are
members of that group are revoked.  By adding users to a group without
those users' knowledge and then deleting that group, a group admin can
revoke all of the users' tokens.  While the default policy file gives
the group admin role to global admin, an alternative policy could
delegate the "create_group", "add_user_to_group", and "delete_group"
capabilities to a set of users.  In such a system, those users will also
get a token revocation capability.  Only setups using a custom policy
file in Keystone are affected.

### Recommended Actions ###
Keystone's default policy.json file uses the "admin_required" rule for
the "create_group", "delete_group", and "add_user_to_group"
capabilities.  It is recommended that you use this default configuration
if possible.  Here is an example snippet of a properly configured
policy.json file:

-  begin example policy.json snippet 
"identity:create_group": "rule:admin_required",
"identity:delete_group": "rule:admin_required",
"identity:add_user_to_group": "rule:admin_required",
-  end example policy.json snippet 

If you need to delegate the above capabilities to non-admin users, you
need to take into account that those users will be able to revoke
tokens for other users by performing group deletion operations.  You
should take caution with who you delegate these capabilities to.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0009
Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1268751
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTPCYGAAoJEJa+6E7Ri+EVw+wIAI1RaoIuHf7VAQSI8J/RhUK/
sKmoKUmEq0yDTQwKnbW2X8PMM6t4d4NDV0bSJfrKZYjnIWBNoh0hk3yg4GYytn2s
s8o31ctOhWWOx/EGfnhlm7IrJZ91KmnhrVTLMdSFOQhiIzxa2gyEk0Fw3k6oYlDN
wJWC5NyKKeNpjb7SSoHhifcQ/7FGUJIcd8tnm1KT3vMrK9pUM46Jsb8sdfZ2+8hE
ym3vCSc47t5K/32HFDjiAsfaCKBVIoJeOBOJGOcsQIpuW6GkRB8Ic5n2+EW25Z3O
y5tgwhHZaoTL6K0KlpGHPvVSoeJea09yTL97KqCIcMM89KwNcKvobM2KHgtwqHY=
=i6VA
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] proxying SSL traffic for API requests

[Nathan Kinder]

On 03/26/2014 09:51 AM, Clint Byrum wrote:
> Excerpts from Chris Jones's message of 2014-03-26 06:58:59 -0700:
>> Hi
>>
>> We don't have a strong attachment to stunnel though, I quickly dropped it in 
>> front of our CI/CD undercloud and Rob wrote the element so we could repeat 
>> the deployment.
>>
>> In the fullness of time I would expect there to exist elements for several 
>> SSL terminators, but we shouldn't necessarily stick with stunnel because it 
>> happened to be the one I was most familiar with :)
>>
>> I would think that an httpd would be a good option to go with as the 
>> default, because I tend to think that we'll need an httpd running/managing 
>> the python code by default.
>>
> 
> I actually think that it is important to separate SSL termination from
> the app server. In addition to reasons of scale (SSL termination scales
> quite a bit differently than app serving), there is a security implication
> in having the private SSL keys on the same box that runs the app.

There is also a security implication in having network traffic from the
SSL terminator to the application in the clear.  If the app is
compromised, one could just read all incoming traffic anyway since it is
not encrypted.

> 
> So if we use apache for running the python app servers, that is not a
> reason to also use apache for SSL. Quite the opposite I think.
> 
> As far as "which is best".. there are benefits and drawbacks for all of
> them, and it is modular enough that we can just stick with stunnel and
> users who find problems with it can switch it out without too much hassle.
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] All LDAP users returned using keystone v3/users API

[Nathan Kinder]

On 03/13/2014 08:36 AM, Anna A Sortland wrote:
> [A] The current keystone LDAP community driver returns all users that
> exist in LDAP via the API call v3/users, instead of returning just users
> that have role grants (similar processing is true for groups). This
> could potentially be a very large number of users. We have seen large
> companies with LDAP servers containing hundreds and thousands of users.
> We are aware of the filters available in keystone.conf
> ([ldap].user_filter and [ldap].query_scope) to cut down on the number of
> results, but they do not provide sufficient filtering (for example, it
> is not possible to set user_filter to members of certain known groups
> for OpenLDAP without creating a memberOf overlay on the LDAP server).
> 
> [Nathan Kinder] What attributes would you filter on?  It seems to me
> that LDAP would need to have knowledge of the roles to be able to filter
> based on the roles.  This is not necessarily the case, as identity and
> assignment can be split in Keystone such that identity is in LDAP and
> role assignment is in SQL.  I believe it was designed this way to deal
> with deployments
> where LDAP already exists and there is no need (or possibility) of
> adding role info into LDAP.
> 
> [A] That's our main use case. The users and groups are in LDAP and role
> assignments are in SQL.
> You would filter on role grants and this information is in SQL backend.
> So new API would need to query both identity and assignment drivers.
> 
> [Nathan Kinder] Without filtering based on a role attribute in LDAP, I
> don't think that there is a good solution if you have OpenStack and
> non-OpenStack users mixed in the same container in LDAP.
> If you want to first find all of the users that have a role assigned to
> them in the assignments backend, then pull their information from LDAP,
> I think that you will end up with one LDAP search operation per user.
> This also isn't a very scalable solution.
> 
> [A] What was the reason the LDAP driver was written this way, instead of
> returning just the users that have OpenStack-known roles? Was the
> creation of a separate API for this function considered?
> Are other exploiters of OpenStack (or users of Horizon) experiencing
> this issue? If so, what was their approach to overcome this issue? We
> have been prototyping a keystone extension that provides an API that
> provides this filtering capability, but it seems like a function that
> should be generally available in keystone.
> 
> [Nathan Kinder] I'm curious to know how your prototype is looking to
> handle this.
> 
> [A] The prototype basically first calls assignment API
> list_role_assignments() to get a list of users and groups with role
> grants. It then iterates the retrieved list and calls identity API
> list_users_in_group() to get the list of users in these groups with
> grants and get_user() to get users that have role grants but do not
> belong to the groups with role grants (a call for each user). Both calls
> ignore groups and users that are not found in the LDAP registry but
> exist in SQL (this could be the result of a user or group being removed
> from LDAP, but the corresponding role grant was not revoked). Then the
> code removes duplicates if any and returns the combined list.

My main concern about this is that you have a single LDAP search
operation per user.  This will get you the correct results, but it isn't
very efficient for the LDAP server if you have a large number of users.
 Performing a single LDAP search operation will perform better if there
is some attribute you can use to filter on, as the connection handling
and operation parsing overhead will be much less.  If you are unable to
add an attribute in LDAP that identifies users that Keystone should list
(such as memberOf), you may not have much choice other than your proposal.

> 
> The new extension API is /v3/my_new_extension/users. Maybe the better
> naming would be v3/roles/users (list users with any role) - compare to
> existing v3/roles/​{role_id}​/users  (list users with a specified role).
> 
> Another alternative that we've tried is just a new identity driver that
> inherits from keystone.identity.backends.ldap.LDAPIdentity and overrides
> just the list_users() function. That's probably not the best approach
> from OpenStack standards point of view but I would like to get
> community's feedback on whether this is acceptable.
> 
> 
> I've posted this question to openstack-security last week but could not
> get any feedback after Nathan's first reply. Reposting to openstack-dev..

Sorry for the delay in replying.  This list is a better place to discuss
this anyway, as you will get more visibility.

Thanks,
-NGK
> 
> 
> 
> Anna

[openstack-dev] [OSSG][OSSN] DoS style attack on noVNC server can lead to service interruption or disruption

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

DoS style attack on noVNC server can lead to service interruption or
disruption
- ---

### Summary ###
There is currently no limit to the number of noVNC or SPICE console
sessions that can be established by a single user. The console host has
limited resources and an attacker launching many sessions may be able to
exhaust the available resources, resulting in a Denial of Service (DoS)
condition.

### Affected Services / Software ###
Horizon, Nova, noVNC proxy, SPICE console, Grizzly, Havana

### Discussion ###
Currently with a single user token, no restrictions are enforced on the
number or frequency of noVNC or SPICE console sessions that may be
established.  While a user can only access their own virtual machine
instances, resources can be exhausted on the console proxy host by
creating an excessive number of simultaneous console sessions.  This can
result in timeouts for subsequent connection requests to instances using
the same console proxy.  Not only would this prevent the user from
accessing their own instances, but other legitimate users would also be
deprived of console access.  Further, other services running on the
noVNC proxy and Compute hosts may degrade in responsiveness.

By taking advantage of this lack of restrictions around noVNC or SPICE
console connections, a single user could cause the console proxy
endpoint to become unresponsive, resulting in a Denial Of Service (DoS)
style attack.  It should be noted that there is no amplification effect.

### Recommended Actions ###
For current stable OpenStack releases (Grizzly, Havana), users need to
workaround this vulnerability by using rate-limiting proxies to cover
access to the noVNC proxy service.  Rate-limiting is a common mechanism
to prevent DoS and Brute-Force attacks.

For example, if you are using a proxy such as Repose, enable the rate
limiting feature by following these steps:

  https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter

Future OpenStack releases are looking to add the ability to restrict
noVNC and SPICE console connections.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0008
Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1227575
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTHJz3AAoJEJa+6E7Ri+EVdHUH/10DusIv3xhL9rsnxhP5vbKW
tucqnh4MxaVX7ZfyKhD1aEme1IXtupbfGxOqF1Xa35PXPv/pHTDjhs3HEcnB3MVf
PzAx8o3fywIxqVsTcdrweLOhZ2EirhG56WudiLOL+J5zVjfU5Cz4sZgIf3DvqRpk
hpy0fWGMRExir8PgPpByTSJxuqQx1gsYeUqnvV8VknmoR1SW5Dk2RLP3cy+4aMNA
qTYXug3Le71Ra4ligp/6BzA/L7+zaVBM2OFOIU2RXCt29S5zmCTI6EuPiQXPstwK
/qEIPnNXwA4vY6r6iObDBa+K5CBEqMkI4rJTl1kSxksYx+g8UD6EQhlIgb51d2U=
=XyEq
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 答复: [OSSN] Live migration instructions recommend unsecured libvirt remote access

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/07/2014 03:13 AM, Luohao (brian) wrote:
> Nathan,
> 
> I have another idea of allowing vm migration without need for
> remote access to libvirt daemon between compute servers.
> 
> As I know, vm migration data path can be independent with libvirt
> daemon. For example, libvirt supports delegating vm migration to
> the hypervisor. When a vm migration is required, nova can prepare
> an ephemeral migration service on the destination node, and then
> launch the connection from source node to destination node to
> perform the migration. All these can be done by local libvirt calls
> on different compute nodes.

This delegation is what is already being used for the case described
in the OSSN as far as I understand.  The ephemeral ports described are
handled by QEMU, and libvirtd remote access is simply telling QEMU to
listen on the receiving side.  Nova could do this in theory by talking
to the remote nova-compute service and making local libvirtd calls,
but the ephemeral ports are still needed.  The ephemeral ports are
more problematic that libvitd remote access, as they don't directly
allow for any authentication or encryption.  The ability to tunnel the
QEMU migration through the libvirtd remote access port allows
authentication and encryption to be used (though this isn't currently
possible for block migration).  Tunneling really does seem to be the
most secure approach.

This page provides a nice overview of libvirt's migration capabilities:

http://libvirt.org/migration.html

Thanks,
- -NGK

> 
> -Hao
> 
> -邮件原件- 发件人: Nathan Kinder [mailto:nkin...@redhat.com] 发送时间:
> 2014年3月7日 3:36 收件人: OpenStack Development Mailing List (not for
> usage questions) 主题: [openstack-dev] [OSSN] Live migration
> instructions recommend unsecured libvirt remote access
> 
> Live migration instructions recommend unsecured libvirt remote
> access ---
> 
> ### Summary ### When using the KVM hypervisor with libvirt on
> OpenStack Compute nodes, live migration of instances from one
> Compute server to another requires that the libvirt daemon is
> configured for remote network connectivity. The libvirt daemon
> configuration recommended in the OpenStack Configuration Reference
> manual configures libvirtd to listen for incoming TCP connections
> on all network interfaces without requiring any authentication or
> using any encryption.  This insecure configuration allows for
> anyone with network access to the libvirt daemon TCP port on
> OpenStack Compute nodes to control the hypervisor through the
> libvirt API.
> 
> ### Affected Services / Software ### Nova, Compute, KVM, libvirt,
> Grizzly, Havana, Icehouse
> 
> ### Discussion ### The default configuration of the libvirt daemon
> is to not allow remote access.  Live migration of running instances
> between OpenStack Compute nodes requires libvirt daemon remote
> access between OpenStack Compute nodes.
> 
> The libvirt daemon should not be configured to allow
> unauthenticated remote access.  The libvirt daemon  has a choice of
> 4 secure options for remote access over TCP.  These options are:
> 
> - SSH tunnel to libvirtd's UNIX socket - libvirtd TCP socket, with
> GSSAPI/Kerberos for auth+data encryption - libvirtd TCP socket,
> with TLS for encryption and x.509 client certificates for
> authentication - libvirtd TCP socket, with TLS for encryption and
> Kerberos for authentication
> 
> It is not necessary for the libvirt daemon to listen for remote TCP
> connections on all interfaces.  Remote network connectivity to the
> libvirt daemon should be restricted as much as possible.  Remote
> access is only needed between the OpenStack Compute nodes, so the
> libvirt daemon only needs to listen for remote TCP connections on
> the interface that is used for this communication.  A firewall can
> be configured to lock down access to the TCP port that the libvirt
> daemon listens on, but this does not sufficiently protect access to
> the libvirt API.  Other processes on a remote OpenStack Compute
> node might have network access, but should not be authorized to
> remotely control the hypervisor on another OpenStack Compute node.
> 
> ### Recommended Actions ### If you are using the KVM hypervisor
> with libvirt on OpenStack Compute nodes, you should review your
> libvirt daemon configuration to ensure that it is not allowing
> unauthenticated remote access.
> 
> Remote access to the libvirt daemon via TCP is configured by the
> "listen_tls", "listen_tcp", and "auth_tcp" configuration
> directives.  By default, these directives are all commented out.
> This results in remote access via TCP being disabled.
> 
> If you do not need remote libvirt daemon a

[openstack-dev] [OSSN] Live migration instructions recommend unsecured libvirt remote access

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Live migration instructions recommend unsecured libvirt remote access
- ---

### Summary ###
When using the KVM hypervisor with libvirt on OpenStack Compute nodes,
live migration of instances from one Compute server to another requires
that the libvirt daemon is configured for remote network connectivity.
The libvirt daemon configuration recommended in the OpenStack
Configuration Reference manual configures libvirtd to listen for
incoming TCP connections on all network interfaces without requiring any
authentication or using any encryption.  This insecure configuration
allows for anyone with network access to the libvirt daemon TCP port on
OpenStack Compute nodes to control the hypervisor through the libvirt
API.

### Affected Services / Software ###
Nova, Compute, KVM, libvirt, Grizzly, Havana, Icehouse

### Discussion ###
The default configuration of the libvirt daemon is to not allow remote
access.  Live migration of running instances between OpenStack Compute
nodes requires libvirt daemon remote access between OpenStack Compute
nodes.

The libvirt daemon should not be configured to allow unauthenticated
remote access.  The libvirt daemon  has a choice of 4 secure options for
remote access over TCP.  These options are:

 - SSH tunnel to libvirtd's UNIX socket
 - libvirtd TCP socket, with GSSAPI/Kerberos for auth+data encryption
 - libvirtd TCP socket, with TLS for encryption and x.509 client
   certificates for authentication
 - libvirtd TCP socket, with TLS for encryption and Kerberos for
   authentication

It is not necessary for the libvirt daemon to listen for remote TCP
connections on all interfaces.  Remote network connectivity to the
libvirt daemon should be restricted as much as possible.  Remote
access is only needed between the OpenStack Compute nodes, so the
libvirt daemon only needs to listen for remote TCP connections on the
interface that is used for this communication.  A firewall can be
configured to lock down access to the TCP port that the libvirt daemon
listens on, but this does not sufficiently protect access to the libvirt
API.  Other processes on a remote OpenStack Compute node might have
network access, but should not be authorized to remotely control the
hypervisor on another OpenStack Compute node.

### Recommended Actions ###
If you are using the KVM hypervisor with libvirt on OpenStack Compute
nodes, you should review your libvirt daemon configuration to ensure
that it is not allowing unauthenticated remote access.

Remote access to the libvirt daemon via TCP is configured by the
"listen_tls", "listen_tcp", and "auth_tcp" configuration directives.  By
default, these directives are all commented out.  This results in remote
access via TCP being disabled.

If you do not need remote libvirt daemon access, you should ensure that
the following configuration directives are set as follows in the
/etc/libvirt/libvirtd.conf configuration file.  Commenting out these
directives will have the same effect, as these values match the internal
defaults:

-  begin example libvirtd.conf snippet 
listen_tls = 1
listen_tcp = 0
auth_tcp = "sasl"
-  end example libvirtd.conf snippet 

If you need to allow remote access to the libvirt daemon between
OpenStack Compute nodes for live migration, you should ensure that
authentication is required.  Additionally, you should consider enabling
TLS to allow remote connections to be encrypted.

The following libvirt daemon configuration directives will allow for
unencrypted remote connections that use SASL for authentication:

-  begin example libvirtd.conf snippet 
listen_tls = 0
listen_tcp = 1
auth_tcp = "sasl"
-  end example libvirtd.conf snippet 

If you want to require TLS encrypted remote connections, you will have
to obtain X.509 certificates and configure the libvirt daemon to use
them to use TLS.  Details on this configuration are in the libvirt
daemon documentation.  Once the certificates are configured, you should
set the following libvirt daemon configuration directives:

-  begin example libvirtd.conf snippet 
listen_tls = 1
listen_tcp = 0
auth_tls = "none"
-  end example libvirtd.conf snippet 

When using TLS, setting the "auth_tls" configuration directive to "none"
uses X.509 client certificates for authentication.  You can additionally
require SASL authentication by setting the following libvirt daemon
configuration directives:

-  begin example libvirtd.conf snippet 
listen_tls = 1
listen_tcp = 0
auth_tls = "sasl"
-  end example libvirtd.conf snippet 

When using TLS, it is also necessary to configure the OpenStack Compute
nodes to use a non-default URI for live migration.  This is done by
setting the following configuration directive in /etc/nova/nova.conf:

-  begin example nova.conf snippet 
live_migration_uri=qemu+tls://%s/system
-  end example nova.conf snippet 

For more details on libvirt daemon remote URI form

[openstack-dev] [OSSG][OSSN] Keystone can allow user impersonation when using REMOTE_USER for external authentication

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Keystone can allow user impersonation when using REMOTE_USER for
external authentication
- ---

### Summary ###
When external authentication is used with Keystone using the
"ExternalDefault" plug-in, external usernames containing "@"
characters are truncated at the "@" character before being mapped to a
local Keystone user. This can result in separate external users
mapping to the same local Keystone user, which could lead to user
impersonation.

### Affected Services / Software ###
Keystone, Havana

### Discussion ###
When Keystone is run in the Apache HTTP Server, the webserver can
handle authentication and pass the authenticated username to Keystone
using the REMOTE_USER environment variable. External authentication
behavior is handled by authentication plugins in Keystone. In the
Havana release of OpenStack, if the external username provided in the
REMOTE_USER environment variable contains an "@" character Keystone
will only use the portion preceding the "@" character as the username
when using the "ExternalDefault" authentication plugin. This results
in the ability for multiple unique external usernames to map to the
same single username in Keystone. For example, the external usernames
"j...@example1.com" and "j...@example2.com" would both map to the
Keystone user "jdoe". This behavior could potentially be abused to
allow one to impersonate another similarly named external user.

Keystone in OpenStack releases prior to Havana uses the entire value
contained in the REMOTE_USER environment variable, so those versions
are not vulnerable to this impersonation issue.

### Recommended Actions ###
If the "ExternalDefault" plugin is being used for external
authentication in the Havana release, you should ensure that external
usernames do not contain "@" characters unless you want to collapse
similarly named external users into a single user on the Keystone side.

If your external usernames do contain "@" characters and you do not
want to collapse similarly named external users into a single user on
the Keystone side, you might be able to use the "ExternalDomain"
plug-in. This plugin considers the portion of the external username
that follows an "@" character to be the domain that the user belongs
to in Keystone. This allows similarly named external users to map to
separate Keystone users if the portion of the external username that
follows an "@" character maps to a Keystone domain name. To configure
the "ExternalDomain" authentication plugin, set the "external"
parameter in the "[auth]" section of Keystone's keystone.conf as follows:

-  begin example keystone.conf snippet 
[auth]
methods = external,password,token
external = keystone.auth.plugins.external.ExternalDomain
-  end example keystone.conf snippet 

If neither of the above recommendations work for your deployment, a
custom authentication plugin can be created that uses the external
username that contains an "@" character as-is.

### Contacts / References ###
This OSSN : https://bugs.launchpad.net/ossn/+bug/1254619
Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1254619
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS2X1/AAoJEJa+6E7Ri+EV5dsH/2ZpIXJ9F/aW3CCtoYH1cW7K
V3OC4zAIxiHtUmAxB/sxonaxK38oD/hLSFmigY1pHinwiYVZYvAooFytOEVpfwPv
ExZZvE35EJnAdPHUfyZwrUSzph44n4fvKnECtZl5tbGlk+cUO4TQNE8sc6YNTcNy
Br/WfVYvzXFUiu4UzRKmXHKViqDl6OTNgDr+Wk1K7JqBtYyXggIitUru0zAIw7LE
14HjFP00r2o89YEuDj9Bf/Ud4FC0ns/hyANix8OGkjVzjVM9pTiTxqjFc/1IleJY
rvFSt8med468GPmUdM1SiAAkhkvjeL2GbaTbvvbBilfsTOEnfP/bhH/yjVpq6SA=
=vK5j
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Nominations to Horizon Core

[Nathan Kinder]

On 12/11/2013 08:08 PM, Bryan D. Payne wrote:
> We can involve people in security reviews without having them on the
> core review team.  They are separate concerns.
> 
> 
> Yes, but those people can't ultimately approve the patch.  So you'd need
> to have a security reviewer do their review, and then someone who isn't
> a security person be able to offer the +1/+2 based on the opinion of the
> security reviewer.  This doesn't make any sense to me.  You're involving
> an extra person needlessly, and creating extra work.
> 
>  
> 
> This has been discussed quite a bit.  We can't handle security patches
> on gerrit right now while they are embargoed because we can't completely
> hide them.
> 
> 
> I think that you're confusing security reviews of new code changes with
> reviews of fixes to security problems.  In this part of my email, I'm
> talking about the former.  These are not embargoed.  They are just the
> everyday improvements to the system.  That is the best time to identify
> and gate on security issues.  Without someone on core that can give a -2
> when there's a problem, this will basically never happen.  Then we'll be
> back to fixing a greater number of things as bugs.

+1.  I'd really like to see at least one security representative per
project on core who makes sure that incoming code an blueprints are
following security best practices.  These best practices still need to
be clearly defined, but it's going to be impossible to uphold them once
they are established unless someone with review power is involved.  We
want security to be more proactive instead of reactive.

-NGK

> 
> -bryan
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSG][OSSN] Glance allows sharing of images between projects without consumer project approval

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Glance allows sharing of images between projects without consumer
project approval
- ---

### Summary ###
Glance allows images to be shared between projects. In certain API
versions, images can be shared without the consumer project's
approval. This allows potentially malicious images to show up in a
project's image list.

### Affected Services / Software ###
Glance, Image Service, Diablo, Essex, Folsom, Grizzly, Havana

### Discussion ###
Since the OpenStack Diablo release, Glance allows images to be shared
between projects. To share an image, the producer of the image adds
the consumer project as a member of the image. When using the Image
Service API v1, the image producer is able to share an image with a
consumer project without their approval. This results in the shared
image showing up in the image list for the consumer project. This can
mislead users with roles in the consumer project into running a
potentially malicious image.

The Image Service API v2.0 does not allow image sharing between
projects, so a project is not susceptible to running unauthorized
images shared by other projects. The Image Service API v2.1 allows
image sharing using a two-step process. An image producer must add a
consumer as a member of the image, and the consumer must accept the
shared image before it shows up in their image list. This additional
approval process allows a consumer to control what images show up in
their image list, thus preventing potentially malicious images being
used without the consumers knowledge.

### Recommended Actions ###
In the OpenStack Diablo, Essex, and Folsom releases, Glance supports
image sharing using the Image Service API v1. There is no way to
require approval of a shared image by consumer projects. Users should
be cautioned to be careful when using images from their image list, as
they may be using an image that was shared with them without their
knowledge.

In the OpenStack Grizzly and Havana releases, Glance supports the
Image Service API v2.1 or later. Support is still provided for Image
Service API v1, which allows image sharing between projects without
consumer project approval. It is recommended to disable v1 of the
Image Service API if possible. This can be done by setting the
following directive in the glance-api.conf configuration file:

-  begin example glance-api.conf snippet 
enable_v1_api = False
-  end example glance-api.conf snippet 

### Contacts / References ###
This OSSN : https://bugs.launchpad.net/ossn/+bug/1226078
Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1226078
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
CVE: CVE-2013-4354
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSqTCNAAoJEJa+6E7Ri+EVZwEH+gK6PC8t1OHqCZ2Z7Sd9I0PW
GPMD17iMCSvwV9492wWbjmvMpnyEdu9bQKYe1Rx/mQE2poKuxm/fmBA72M8YiiI3
WoS2ABOtvPPp35ZpQgre/sVwOoOwRxmpHDn9gf9U+/hgGw1gGsfWB3bm/R7paLUD
xzWEU/XS8NY9DQLcajPBGDI2/VoySOUf1WS9i9+G/sbplVbHVNDzs7qzlAhdHdgw
Ed6KTfxF0Em7sA4QL0SpEeHMiiYJgA2YhJsSVXN0sklz8Jw7drwaH/vdLEG9KES3
f+q46GDnNJhwB9vlPs3ljUYKtVrFFhOtxTiZhZV2wsXtsnNTQtxg22HRC40vVvg=
=tYQj
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] [Security]

[Nathan Kinder]

On 11/27/2013 08:58 AM, Paul Montgomery wrote:
> I created some relatively high level security best practices that I
> thought would apply to Solum.  I don't think it is ever too early to get
> mindshare around security so that developers keep that in mind throughout
> the project.  When a design decision point could easily go two ways,
> perhaps these guidelines can sway direction towards a more secure path.
> 
> This is a living document, please contribute and let's discuss topics.
> I've worn a security hat in various jobs so I'm always interested. :)
> Also, I realize that many of these features may not directly be
> encapsulated by Solum but rather components such as KeyStone or Horizon.
> 
> https://wiki.openstack.org/wiki/Solum/Security

This is a great start.

I think we really need to work towards a set of overarching security
guidelines and best practices that can be applied to all of the
projects.  I know that each project may have unique security needs, but
it would be really great to have a central set of agreed upon
cross-project guidelines that a developer can follow.

This is a goal that we have in the OpenStack Security Group.  I am happy
to work on coordinating this.  For defining these guidelines, I think a
"working group" approach might be best, where we have an interested
representative from each project be involved.  Does this approach make
sense to others?

Thanks,
-NGK

> 
> I would like to build on this list and create blueprints or tasks based on
> topics that the community agrees upon.  We will also need to start
> thinking about timing of these features.
> 
> Is there an OpenStack standard for code comments that highlight potential
> security issues to investigate at a later point?  If not, what would the
> community think of making a standard for Solum?  I would like to identify
> these areas early while the developer is still engaged/thinking about the
> code.  It is always harder to go back later and find everything in my
> experience.  Perhaps something like:
> 
> # (SECURITY) This exception may contain database field data which could
> expose passwords to end users unless filtered.
> 
> Or
> 
> # (SECURITY) The admin password is read in plain text from a configuration
> file.  We should fix this later.
> 
> Regards,
> Paulmo
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] tenant or project

[Nathan Kinder]

On 11/23/2013 08:28 AM, Tim Bell wrote:
> 
> Horizon uses Project in the user interface, yet the openstack.rc file 
> contains tenant_id and tenant_name. It makes it very difficult to write user 
> guides given that such a fundamental concept has two names.

+1.  I struggled with this dual-nomenclature when writing up a security
note earlier this week.  I discussed it with Adam from the Keystone
project, and he said that they want the tenant term to go away and be
replaced by project.  This is even mentioned in their v3 API docs:


https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#whats-new-in-version-30

> 
> No problem to maintain compatibility (i.e. try OS_TENANT_NAME after 
> OS_PROJECT_NAME) but the lack of convergence is not helping new user adoption.
> 
> How about the technical committee makes a statement that by Icehouse we align 
> all user facing definitions to Tenant or Project (while maintaining backwards 
> compatibility on the environment variables) ?

I think that this is absolutely needed.

-NGK

> 
> Tim
> 
>> -Original Message-
>> From: Christopher Yeoh [mailto:cbky...@gmail.com]
>> Sent: 23 November 2013 13:10
>> To: openstack-dev@lists.openstack.org
>> Subject: [openstack-dev] tenant or project
>>
>> Hi,
>>
>> So in the past we've used both tenant and project to refer to the same thing 
>> and I think its been a source of confusion for people new to
>> OpenStack. In the Nova code we use both, but at least for the API we've been 
>> trying to consistently present to the client tenant (which is
>> the majority usage) rather than project.
>>
>> And then Russell pointed out in https://review.openstack.org/#/c/57612/
>> that the Keystone uses project in the Keystone V3 API rather than tenant. 
>> http://api.openstack.org/api-ref-identity.html#identity-v3
>>
>> I think that we should be consistent across the openstack projects.
>> From a very quick look at the core openstack projects I think that they 
>> mostly use tenant at the moment rather than project.
>>
>> Does this change in Keystone nomenclature signify that we all should be 
>> moving to use project rather than tenant in the future (its not too
>> late to do a big a search and replace for the Nova V3 API). And is the plan 
>> for Keystone python client to also change to project rather than
>> tenant?
>>
>> Chris
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OSSG][OSSN] Authenticated users are able to update passwords without providing their current password

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Authenticated users are able to update passwords without providing
their current password
- ---

### Summary ###
An authenticated user is able to change their password without
providing their current password. This allows compromised
authentication tokens to be used to permanently compromise a user account.

### Affected Services / Software ###
Horizon, Keystone, Identity, Grizzly

### Discussion ###
Horizon allows a user to change their own password, which uses the
Identity API to perform the password change. A user is required to
supply their current password to successfully perform a password
change. This requirement prevents a malicious user from stealing a
user's authentication token and changing that user's password to
permanently compromise their account. With this additional password
check, a compromised authentication token only compromises the user
account until the token is no longer valid due to expiration or
revocation.

When using the Identity v3 API, a user is able to successfully change
their password without supplying the correct current password. This
leaves users vulnerable to permanently compromised accounts if their
authentication token is compromised. The Identity v2 API is not
vulnerable to this issue, as it has a separate API call for updating
user passwords that properly validates the current password.

### Recommended Actions ###
In the OpenStack Grizzly release, a user is allowed to update the
attributes in their own entry by default. It is recommended that you
restrict user updates to only be allowed by admin users. This is done
by setting the "update_user" policy to "admin_required" in Keystone's
policy.json file. Here is an example snippet of a properly configured
policy.json file:

-  begin example policy.json snippet 
"identity:get_user": [["rule:admin_required"]],
"identity:list_users": [["rule:admin_required"]],
"identity:create_user": [["rule:admin_required"]],
"identity:update_user": [["rule:admin_required"]],
"identity:delete_user": [["rule:admin_required"]],
-  end example policy.json snippet 

This change has the side-effect of restricting a user from updating
any of their own attributes, not just their password.

In the OpenStack Havana release, the default policy is to only allow
admin users to update attributes in user entries. In addition, Horizon
will not allow a user to change their own password if it is using the
Identity v3 API, even if Keystone is configured to allow users to
update their own entries. Despite this restriction in Horizon, it is
recommended to leave the default "update_user" policy setting as is,
as an attacker could target Keystone directly without using Horizon to
initiate a password change.

### Contacts / References ###
This OSSN : https://bugs.launchpad.net/ossn/+bug/1237989
Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1237989
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
CVE: CVE-2013-4471
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSj9ZNAAoJEJa+6E7Ri+EVGLsH/1j3E6fiO/QInwO2bx7stVHN
27KWvP/8GcLzgNNYN9qMcJExCA5ZbmOXIJlzOR12x/7hrNMkShaaC+VQTYwInn0e
TQ0AESwdb08Wv4GeFDOuc2sliYrH9JR5Lr8/kjGFsmSZ3O4Pyl4AGBrXUDehoVCZ
rq3cSC9+utn11o+lY9BZigbufBCBdWHKKoJ93wEdnTkjl6cQAekqLJyTXLltR5x/
7vSz4e0bYKLyKFZ5BLdPn2gR7pFfnjhlG+oZR0TwGYSCDLJeFFY5tkUKbc2hyGwi
DqPp1escgHTDzXm2gUXWOHs8k0yitHq9JL62VXqL2lbWvbb/HJsCD87JUrFVLUo=
=OLH1
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][keystone] APIs, roles, request scope and admin-ness

[Nathan Kinder]

On 11/02/2013 09:06 AM, Steven Hardy wrote:

Hi all,

Looking to start a wider discussion, prompted by:
https://review.openstack.org/#/c/54651/
https://blueprints.launchpad.net/heat/+spec/management-api
https://etherpad.openstack.org/p/heat-management-api

Summary - it has been proposed to add a management API to Heat, similar in
concept to the admin/public API topology used in keystone.

I'm concerned that this may not be a pattern we want to propagate throughout
OpenStack, and that for most services, we should have one API to access data,
with the scope of the data returned/accessible defined by the roles held by
the user (ie making proper use of the RBAC facilities afforded to us via
keystone).

In the current PoC patch, a users admin-ness is derived from the fact that
they are accessing a specific endpoint, and that policy did not deny them
access to that endpoint.  I think this is wrong, and we should use keystone
roles to decide the scope of the request.
+1.  It seems like a bad idea to have authorization be driven from 
something other than the roles that a user possesses.


The proposal seems to consider tenants as the top-level of abstraction, with
the next level up being a global service provider admin, but this does not
consider the keystone v3 concept of domains [1], or that you may wish to
provide some of these admin-ish features to domain-admin users (who will
adminster data accross multiple tenants, just like has been proposed), via the
public-facing API.

It seems like we need a way of scoping the request (via data in the context),
based on a heirarchy of admin-ness, like:

1. Normal user
2. Tenant Admin (has admin role in a tenant)
3. Domain Admin (has admin role in all tenants in the domain)
4. Service Admin (has admin role everywhere, like admin_token for keystone)

The current "is_admin" flag which is being used in the PoC patch won't allow
this granularity of administrative boundaries to be represented, and splitting
admin actions into a separate API will prevent us providing tenant and domain
level admin functionality to customers in a public cloud environment.

It has been mentioned that in keystone, if you have admin in one tenant, you
are admin everywhere, which is a pattern I think we should not follow -
keystone folks, what are your thoughts in terms of roadmap to make role
assignment (at the request level) scoped to tenants rather than globally
applied?  E.g what data can we add to move from X-Roles in auth_token, to
expressing roles in multiple tenants and domains?

Basically, I'm very concerned that we discuss this, get a clear roadmap which
will work with future keystone admin/role models, and is not a short-term hack
which we won't want to maintain long-term.
I can't speak for the Keystone developers, but it does seem to me that 
if this level of admin granularity is needed, Keystone is the right 
place for it.


-NGK


What are peoples thoughts on this?

[1]: https://wiki.openstack.org/wiki/Domains

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev