Open Stack

On 04/07/2014 12:06 PM, 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!

Catching up after having been away for a while.

Excellent write-up Nathan and a good idea.

The only suggestion I have at the moment is the information concerning
how sensitive data is protected needs more explicit detail. For example
saying that keys and certs are protected by file system permissions is
not sufficient IMHO.

Earlier this year when I went though the code that generates and stores
certs and keys I was surprised to find a number of mistakes in how the
permissions were set. Yes, they were set, but no they weren't set
correctly. I'd like to see explicit listing of the user and group as
well as the modes and SELinux security contexts of directories, files
(including unix sockets). This will not only help other developers
understand best practice but also allow us to understand if we're
following a consistent model across projects.

I realize some may say this falls into the domain of "installers" and
"packaging", but we should get it right ourselves and allow it to serve
as an example for installation scripts that may follow (many of which
just copy the values).


-- 
John