Gentoo 漏洞处理策略

• 安全
• 漏洞处理策略
• 保持知情

范围

支持的架构

Gentoo Linux 在许多不同的架构上提供。其中一些架构拥有比其他架构更多的开发人员，因此能够更快地响应新的安全漏洞。虽然 Gentoo 安全项目的最终目标是确保所有架构同时收到安全修复，但我们也必须平衡这一点，以便尽可能快地发布安全修复和 GLSA，使大多数用户能够及时了解并获得保护。

出于此原因，安全团队将 Gentoo 架构分成两组，**主要**和**次要：**

主要

这些架构必须在 GLSA 发布之前提交稳定的修复

次要

这些架构将被通知新的漏洞（在相关的漏洞中 cc），但是，我们可能不会在发布 GLSA 之前等待这些架构上的稳定修复

以下是 GLSA 目的的主要架构列表：**amd64，arm64，ppc64**。但是，可能会根据软件包、问题的严重程度及其流行程度来酌情决定是否在非 **amd64** 上阻止 GLSA 发布。

次要架构可能会成为 GLSA 目的的主要架构。需要满足两个简单的标准

• 任命一名开发人员作为与您的架构相关的安全问题的首要联系人（架构安全联络人）：该人员负责确保安全漏洞在其特定架构上得到充分修复。
• 同意遵守已发布的测试时间表并将软件包标记为稳定。

内核

内核不属于 GLSA 发布流程。漏洞仍然需要报告并会被修复，但当所有问题都解决时，不会发布 GLSA。

非稳定软件包

有时会在不在稳定树中的软件包中发现漏洞。当漏洞是较新（~ARCH）ebuild 中的安全回归，但较旧（稳定）软件包不受影响，或者当软件包在树中从未有过任何稳定的 ebuild 时，就会出现这种情况。在这种情况下，漏洞仍然需要报告并会被修复，但当所有问题都解决时，不会发布 GLSA。

漏洞提要

已发布的漏洞

每个漏洞最初都应作为 Bugzilla 条目输入，产品为“Gentoo 安全”，组件为“漏洞”（分配给 [email protected]）。主要的安全列表应分配官方侦察员，以确保这些列表上宣布的所有漏洞都获得安全 Bugzilla 条目。

机密漏洞

机密漏洞（例如来自开发人员的直接通信或受限制的列表）必须遵循特定程序。它们不应作为公共 Bugzilla 条目出现，而应仅出现在安全受限的媒体中，例如私人 Bugzilla 部分或 GLSAMaker 工具。它们应使用 GLSA 协调员和软件包维护者之间的私人通信渠道进行更正。

分发

严重性级别

为了确定适当的反应时间和升级程序，我们需要为每个漏洞分配一个严重性级别。此严重性级别必须基于受影响的软件在 Gentoo 用户中的普及程度和漏洞的深度。

您可以使用以下两个表格来帮助您分配严重性级别

以下是生成的严重性级别表。它们应设置为同名的 Bugzilla 严重性级别

安全漏洞整理员角色

有人应该承担安全漏洞整理员的责任，并在新漏洞进入 Bugzilla 后立即执行以下任务

• 检查重复项：如果漏洞描述了已报告的漏洞，则应将其解决为重复
• 检查错误的组件：如果漏洞不是关于漏洞，则应相应地更改其组件
• 检查漏洞是否确实是漏洞，以及它是否影响 Gentoo Linux 软件包，否则将其解决为无效

在此阶段，可能需要向报告人询问详细信息。漏洞状态保持为未确认或已确认，直到必要时。当（如果）漏洞通过这些健全性测试后，应将其标记为正在进行，漏洞整理员应执行以下操作

• 重命名漏洞，使其在开头包含类别/软件包名称（例如：net-mail/clamav: 使用 RAR 文件进行拒绝服务攻击）
• 如果无法获得修复版本，则删除漏洞标题中的版本信息。应避免类似 <=类别/软件包-1.2.3 的漏洞标题，其中 1.2.3 是软件包的最新版本。
• 评估并分配严重性级别（见上文）
• 将状态设置为正在进行
• 将状态白板播种到正确的严重性代码和状态
• 根据软件包元数据，将软件包维护者 cc 到漏洞中
• 将 URL 字段设置为上游漏洞或类似内容
• 搜索保留的或分配的 CVE 标识符并将其添加到漏洞标题中，否则请求 CVE
• 将漏洞编号输入 CVE 跟踪器（前提是整理员有权访问它）
• 将别名字段设置为 CVE 标识符。如果存在多个标识符，请使用第一个标识符。

时间范围和备份程序

此分发必须在漏洞创建后迅速完成，以便为重大漏洞播种短延迟，并对漏洞报告者表示感谢。目标延迟为 12 小时。安全漏洞整理员必须维护一个可能的 GLSA 协调员列表，其中包含可用性和首选专业领域。为了确保永久分发，安全漏洞整理员工作应有适当的备份。

漏洞修正和 GLSA 草稿

GLSA 协调员角色

GLSA 协调员负责以下任务

• 确定为了关闭漏洞必须执行的操作（例如，识别包含修复的上游版本）。
• 如果上游尚未提供修复，请确保将漏洞正确报告给上游开发人员，并将状态白板设置为 upstream。
• 如果提供修复，请让软件包维护者参与，以生成和提交包含修复的 ebuild，并将状态白板设置为 ebuild。
• 提交 ebuild 后，评估修复 ebuild 需要哪些关键字，并让特定于架构的团队在他们的架构上测试并标记 ebuild 为稳定（应将架构团队 cc 到漏洞中，以及发布准备期间的 releng），并将状态白板设置为 stable。
• 如果修复 ebuild 与最新的漏洞版本相比没有回归，则架构维护者应标记 ebuild 为稳定。
• 同时，使用 GLSAMaker 工具编写 GLSA 草稿。
• 当所有支持的架构都准备好更正 ebuild 后，将状态白板设置为 glsa。

时间框架和升级流程

为了满足漏洞解决的目标延迟，已经定义了一系列升级流程。这些流程包括：

• 当一个处于等待状态的漏洞需要紧急处理时，您应该将状态白板条目更改为其“+”对应项：upstream+、ebuild+、stable+ 和 glsa+。
• 如果上游没有可用的修复程序（upstream+ 状态），则必须决定是否屏蔽该软件包：安全团队可以屏蔽不依赖于自身的软件包，在屏蔽非独立软件包之前应咨询维护人员。
• 如果维护人员/项目在召唤后 48 小时内没有出现以生成 ebuild（ebuild+ 状态），安全团队应尝试自行提升 ebuild。
• 如果测试和标记稳定花费的时间过长（stable+ 状态），安全团队将在 IRC 频道和 gentoo-dev 列表上呼吁，以获得更多测试人员。它将自行将 ebuild 标记为稳定，或者如果由于稳定性问题而无法执行此操作，则对其进行屏蔽（参见上面的安全屏蔽批准策略）。
• 如果 GLSA 协调员没有出现以草拟 GLSA（glsa+ 状态），则安全团队的另一位成员应草拟 GLSA 并将其提交到同行评审。

安全漏洞的良好实践

安全漏洞不同于其他漏洞，因为必须通过 GLSA 向用户提供简单易行的升级路径。因此，软件包维护人员和 GLSA 协调员应遵循以下良好实践。

• 包含安全修复的 ebuild 应具有自己的版本号，以便在正常的系统升级过程中被选中：如果需要，请使用版本号提升。
• 包含安全修复的 ebuild 的版本号应高于任何以前发布的版本，以便可以向用户提议简单的升级路径。
• 如果需要进行补丁，则应将其仅应用于最新版本，无需对所有带修补程序版本的 ebuild 进行版本号提升。
• 在漏洞进入 stable 状态之前，应将存在漏洞的版本保留在树中，以便正确评估修复版本的关键字。

GLSA 发布流程

同行评审

一旦准备就绪，GLSA 应提交到同行评审。安全团队至少需要两位成员批准草案 GLSA。一旦草案通过同行评审流程，就应为其分配正式的 GLSA 编号。

GLSA 发布

一旦 GLSA 通过同行评审流程（并在确保 ebuild 已进入稳定树后），GLSA 协调员应将 GLSA XML 提交到 Gentoo CVS 存储库。完成此操作后，GLSA 将自动出现在 官方 GLSA 索引页面 和 RSS 订阅 上。

GLSA 发布

GLSA 文本版本必须由 GLSA 协调员发布到以下媒体：

应该发送一封电子邮件，并遵循以下规则：

• To: 字段必须设置为 gentoo-announce。
• From: 和 Return-Path: 必须设置为 GLSA 协调员 @gentoo.org 地址。
• Subject: 字段必须为“[ GLSA XXXXYY-ZZ ] 您的漏洞”。
• 正文应仅包含 GLSA 的文本版本。
• 电子邮件必须由 GLSA 协调员的 OpenPGP 密钥签名。

发布 GLSA 后，相应的 bugzilla 漏洞应解决为 FIXED，并在漏洞的评论部分引用 GLSA 编号。GLSAMaker 2 在发布安全公告后提供了此选项。

GLSA 勘误

有时，错误会通过同行评审过程，并且错误的 GLSA 会发布到全世界。根据错误的严重程度，应应用以下勘误策略。