Re: [openstack-dev] Security audit of OpenStack projects
Hi Rob, We quickly discussed your ephemeral CA idea this morning and like it. We also realize that it will take a lot of work to make it happen. At this point in time we are attempting to simply add some form of SSL to a cloud installed with TripleO. We lost all of our previous installation tools and are essentially starting from ground zero. The TripleO community does not have a solution in place so we are all learning how to build ISOs and what files to add/modify to install SSL. Due to our short deadlines we will not be able to push our changes up through the community in time so we may have some throw away work once the community catches up. Mark -Original Message- From: Clark, Robert Graham Sent: Friday, May 02, 2014 7:12 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Security audit of OpenStack projects > -Original Message- > From: John Dennis [mailto:jden...@redhat.com] > Sent: 02 May 2014 14:23 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] Security audit of OpenStack projects > > 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). It's a great project, we really should be doing this more. I think there's certainly scope to record 'installer' type information too, in the form of either recommendations or 'enhancements'. This information could be aggregated in the OpenStack Hardening Guide too. As Nathan said this really needs buy-in from individual teams in order to pay off and the effort w
Re: [openstack-dev] Security audit of OpenStack projects
> -Original Message- > From: John Dennis [mailto:jden...@redhat.com] > Sent: 02 May 2014 14:23 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] Security audit of OpenStack projects > > 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). It's a great project, we really should be doing this more. I think there's certainly scope to record 'installer' type information too, in the form of either recommendations or 'enhancements'. This information could be aggregated in the OpenStack Hardening Guide too. As Nathan said this really needs buy-in from individual teams in order to pay off and the effort would need to be repeated for each release. I expect that future iterations would require a lot less effort than the first though. Projects like this can be a bit of a time drain for core developers and highly active code contributors but they're ideal for people starting off in a project, a nice way to have them look through the code, understand it and report on it I'd be very interested in any ideas on how to take this forward -Rob smime.p7s Description: S/MIME cryptographic 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
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 ___ 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
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
Re: [openstack-dev] Security audit of OpenStack projects
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. 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. 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. -- Russell Bryant ___ 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
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. I've made a start on a page for Heat, feedback welcome! https://wiki.openstack.org/wiki/Security/Icehouse/Heat Steve ___ 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
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
