Open Stack

Travis,

Several of us have been working along these lines. We presented on the
topic at PyCon this year. You can see the slides here:

http://www.slideshare.net/jarito030506/state-of-crypto-in-python?qid=c557d2
b4-d080-4696-a467-6050cd189a3d&v=qf1&b=&from_search=1


And a video of the presentation here:

http://pyvideo.org/video/2583/the-state-of-crypto-in-python



We do have a goal of having cryptography be audited it at some point in
the future. However, since cryptography just exposes functionality of C
backends, most / all of the crypto heavy lifting happens in C land. That
is where the most value for auditing will come in.

I've included Paul and Alex, both of whom work heavily on the cryptography
package.


--
Jarret Raim 
@jarretraim





On 6/5/14, 2:58 PM, "Travis McPeak" <Travis_McPeak at symantec.com> wrote:

>Hi all,
>
>I¹ve been thinking about some of the crypto libraries that are being used
>in OpenStack projects, specifically how much confidence should we have in
>them.  It has occurred to me that we don¹t really know if they have been
>audited, or even if anybody has taken a hard look at them.  We know that
>security of a system is only as good as the weakest link, but what about
>these backbones of security that we are relying on?  Have they been
>vetted?  
>
>I have started an etherpad:
>https://etherpad.openstack.org/p/CryptoLibraryInventory to track this very
>issue.  Please contribute if you know anything about any of the libraries
>listed.  If there are libraries that I haven¹t listed, please add them.
>
>I think with the collective knowledge of the community, we can begin to
>build some clarity around which libraries are more ³trustworthy² than
>others, and how much we can trust them.
>
>Thanks,
>  -Travis
>
>
>
>
>On 6/5/14, 5:00 AM, "openstack-security-request at lists.openstack.org"
><openstack-security-request at lists.openstack.org> wrote:
>
>>Send Openstack-security mailing list submissions to
>>	openstack-security at lists.openstack.org
>>
>>To subscribe or unsubscribe via the World Wide Web, visit
>>	http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>
>>or, via email, send a message with subject or body 'help' to
>>	openstack-security-request at lists.openstack.org
>>
>>You can reach the person managing the list at
>>	openstack-security-owner at lists.openstack.org
>>
>>When replying, please edit your Subject line so it is more specific
>>than "Re: Contents of Openstack-security digest..."
>>
>>
>>Today's Topics:
>>
>>   1. [Bug 1174608] Re: [OSSA 2013-010] Insecure directory creation
>>      for signing (Morgan Fainberg)
>>
>>
>>----------------------------------------------------------------------
>>
>>Message: 1
>>Date: Wed, 04 Jun 2014 23:23:55 -0000
>>From: Morgan Fainberg <morgan.fainberg at gmail.com>
>>To: openstack-security at lists.openstack.org
>>Subject: [Openstack-security] [Bug 1174608] Re: [OSSA 2013-010]
>>	Insecure directory creation for signing
>>Message-ID: <20140604232358.27834.43216.launchpad at gac.canonical.com>
>>Content-Type: text/plain; charset="utf-8"
>>
>>** Changed in: keystone/folsom
>>       Status: Fix Committed => Fix Released
>>
>>-- 
>>You received this bug notification because you are a member of OpenStack
>>Security Group, which is subscribed to OpenStack.
>>https://bugs.launchpad.net/bugs/1174608
>>
>>Title:
>>  [OSSA 2013-010] Insecure directory creation for signing
>>
>>Status in OpenStack Identity (Keystone):
>>  Invalid
>>Status in Keystone folsom series:
>>  Fix Released
>>Status in OpenStack Compute (Nova):
>>  Fix Released
>>Status in OpenStack Compute (nova) folsom series:
>>  Fix Committed
>>Status in OpenStack Compute (nova) grizzly series:
>>  Fix Released
>>Status in OpenStack Security Advisories:
>>  Fix Released
>>Status in Python client library for Keystone:
>>  Fix Released
>>
>>Bug description:
>>  Originally found by Grant Murphy (gmurphy at redhat.com):
>>
>>  The signing directory is used to store the signing certificates
>>  and the default location for this directory is:
>>
>>      signing_dir = /tmp/keystone-signing-nova
>>
>>  In the file:
>>
>>     keystone/middleware/auth_token.py
>>
>>  During the initialization of the AuthMiddleware the following
>>  operations are made for the signing directory:
>>
>>      IF the directory exists but cannot be written to a configuration
>>error is raised.
>>      ELSE IF the directory doesn't exist, create it.
>>      NEXT chmod permisions(stat.S_IRWXU) to the signing_directory
>>
>>  AFAICT The signing certificates used in validation will only be
>>  fetched from the keystone if the cms_verify action raises an exception
>>  because the certificate file is missing from the signing directory.
>>
>>  This means that if an attacker populated the /tmp/keystone-signing-nova
>>  with the appropriate files for signautre verification they could
>>potentially
>>  issue forged tokens which would be validated by the middleware. As:
>>      - The directory location deterministic. (default for glance, nova)
>>      - *If the directory already exists it is reused*
>>
>>To manage notifications about this bug go to:
>>https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions
>>
>>
>>
>>------------------------------
>>
>>_______________________________________________
>>Openstack-security mailing list
>>Openstack-security at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>
>>
>>End of Openstack-security Digest, Vol 16, Issue 10
>>**************************************************
>
>
>_______________________________________________
>Openstack-security mailing list
>Openstack-security at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5611 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140605/041d9030/attachment.bin>