On 2016-08-31 10:18:57 +0100 (+0100), John Spray wrote: [...] > Given that all the drivers live in the Manila repo, will this > requirement for security audits is going to apply to them? Given the > variety of technologies and network protocols involved in talking to > external storage systems, this strikes me as probably the hardest > part. [...]
Perhaps, but if you look at the templates the Security Group has started putting together they're not for a rigorous code audit: https://git.openstack.org/cgit/openstack/security-analysis/tree/doc/source/templates/ The idea, as I understand it, is that projects will document their architecture and security model, and call out risks they can identify posed by different parts thereof. So for drivers in the manila repo, this is perhaps things like risk in leaking credentials for the storage backend to unauthorized parties or failure to enforce isolation of data access between distinct privilege domains. Then others outside manila can review and provide feedback on this information, ask questions, and help refine it. Then it eventually becomes a living document of the project's design and risk profile both to benefit the users/community at large and also to make it easier for the VMT and the manila-coresec team to classify reports of potential vulnerabilities. If anything, I suspect in-tree drivers for proprietary backends are going to be harder to map to requirement #6 (ability for the VMT to test fixes), but the way it's been handled in other already grandfathered-in projects is that the core security review team for that project subscribes a subject matter expert to the bug and they use their knowledge/access to vet proposed fixes under embargo and then we take their word for it. -- Jeremy Stanley __________________________________________________________________________ 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