跳转到: 导航, 搜索

安全/安全说明流程

此页面描述了编写和发布 OpenStack 安全说明 (OSSN) 应遵循的流程。此页面供 OpenStack 安全项目成员使用。

对于安全项目的许多成员来说,OSSN 将是他们首次使用标准工具和流程为 OpenStack 社区做出贡献。为 OpenStack 安全说明仓库做出贡献被视为在 OpenStack 中的积极技术贡献,作者可以获得参加 OpenStack 峰会的折扣权限以及被认可为为世界上最大的、发展最快的开源项目贡献安全性的荣誉。

什么是 OSSN

OpenStack 有两种机制可以向下游利益相关者传达安全信息,即“建议”和“说明”。安全建议 (OSSA) 是为处理 OpenStack 中已提供修复程序的严重安全问题而创建的 - OSSA 由 OpenStack VMT 发布。我们创建了安全说明流程,用于所有不符合建议要求的安全问题,也就是说,无法修复的安全问题、设计问题、部署和配置漏洞。

读者可以访问 https://security.openstack.org/vmt-process.html 了解有关 OSSA 流程和 VMT 的更多信息。

流程

通常,第三方会通过 Launchpad 在 OpenStack 中提交安全漏洞。如果 VMT 认为该漏洞可能是有效的,但不符合 OSSA 的要求,他们会将“OpenStack 安全说明”团队添加到漏洞的“也受到影响”部分。Launchpad 漏洞会影响多个团队,将安全说明团队添加到漏洞是通知我们存在需要解决的问题的主要方式。

通过 Launchpad 报告的漏洞 => 漏洞被标记为影响“OpenStack 安全说明” => 漏洞被 OSSP 接受 => 漏洞被编写并提交到 Gerrit 进行审查 => 说明通过电子邮件和 OpenStack wiki 发布

审查漏洞

需要编写 OSSN 的漏洞列表维护在这里:https://bugs.launchpad.net/ossn,应类似于以下列表

Screenshot of OSSN bug tracker from Launchpad

漏洞有许多不同的状态,Launchpad 使用的标签更侧重于代码开发而不是文档,但是请将不同的状态解释如下

新建 此漏洞是新的,OSSP 尚未确认他们将为此漏洞编写说明
不会修复 OSSP 不会为此漏洞发布说明
已确认 OSSP 将为此漏洞编写说明
正在处理 此漏洞已分配给 OSSP 的成员,他们正在积极处理该问题
已发布修复 已为此问题发布安全说明

还可以将其他状态应用于项目,包括“不完整、意见、无效、已分类、已提交修复” - 安全项目目前不使用这些标签来管理安全说明。如果您看到带有这些标签的说明,应在 IRC 或通过邮件列表提出问题。

编写

编写新的安全说明时,应确保目标受众在阅读安全说明后能够清楚地回答以下问题

  • 问题是什么?
  • 我的部署受到影响吗?
  • 如果我的部署受到影响,会有什么后果?
  • 我该如何纠正或避免该问题?

为了确保安全说明在技术上是正确的,如果需要任何澄清,您应该联系相关开发人员。所需的许多技术信息通常已经在 Launchpad 漏洞中,但通常需要更多信息才能生成一份全面的安全说明。

您还应检查新的安全说明是否存在以下问题

  • 拼写正确
  • 语法正确
  • 避免使用缩略语(或在安全说明中首次使用时定义它们)

编号分配

开始编写新的安全说明时,您应该做的第一件事是为您的说明分配下一个可用的 OSSN 编号。这在 wiki 上的 安全说明发布区域 中完成。使用下一个可用的编号添加占位符,其中包含您新的安全说明的建议标题,并在末尾附加 (正在进行中)。它应该类似于以下示例

  • OSSN-1234 - 我的新的安全说明 (正在进行中)

保存页面,然后单击您刚刚添加的链接,以创建一个新页面。粘贴 OSSN 的标题和指向 launchpad 漏洞的链接,然后保存页面。

模板

OpenStack 安全说明保存在 安全文档仓库 中,其中包含一个模板,以帮助创建新的安全说明。

该模板采用用于发布到 OpenStack 邮件列表的格式。行长度应限制为 72 个字符,配置文件的示例片段或 联系方式/参考资料 部分中的长链接除外。这将防止换行问题破坏流行的 PGP 邮件客户端软件中可能发生的格式。模板格式也是我们用于推送到 git 仓库的安全说明的格式。

测试

如果新的安全说明记录了解决方法,则重要的是实际测试它以确保其有效。如果您需要帮助进行测试,您可以联系原始 Launchpad 漏洞中的开发人员以及 OpenStack 安全组的其他成员。

审查

Gerrit 审查系统用于审查新的安全说明。如果您不熟悉它,建议您阅读 开发工作流程。如果您想了解该过程,请随时联系已发布说明的作者。

为了将审查链接到相关的 Lauchpad 漏洞,您应该在提交消息中使用 Closes-bug 标签。有关使用此标签的详细信息,请参阅 Git 提交消息 页面。

OpenStack 安全说明源代码仓库可在 http://git.openstack.org/cgit/openstack/security-doc/ 处获得

安全说明需要由 OpenStack 安全说明核心组的两个成员进行审查才能合并。添加与安全说明相关的项目的 PTL 作为审查员也是一个好主意。

发布

安全说明获得适当的审查人员批准后,即可发布。安全说明发布到 OpenStack wiki 和 OpenStack 邮件列表。

维基

在将安全说明发布到邮件列表之前,应先在 OpenStack wiki 上发布。这样,安全说明的电子邮件版本就可以包含指向立即可访问的 wiki 的链接。每个安全说明都有自己的 wiki 页面,然后从 安全说明 wiki 页面链接到该页面。新的安全说明 wiki 页面位置应为 OSSN/OSSN-编号。编号方案只是一个 4 位整数,我们在发布新的 OSSN 时对其进行递增。您可以查看先前发布的安全说明,以了解下一个空闲编号是什么。

在 OpenStack wiki 上发布安全说明时,应使用正确的 wiki 标记来改善格式和提高可读性。建议您查看先前发布的安全说明,以查看如何使用标记进行格式设置的示例。

邮件列表

安全说明发布到 wiki 后,应将其发送到以下邮件列表

  • openstack-discuss@lists.openstack.org
  • openstack-announce@lists.openstack.org

电子邮件应签名,主题应采用 [OSSN 编号] 标题 的形式。电子邮件正文应使用上述模板中的格式。

事后任务

发布安全说明后,最好查看 OpenStack 安全指南或安全准则是否可以改进,以帮助防止与安全说明中的问题类似的问题。