Open Stack

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