Chinese (Simplified)

Warning

此文件的目的是为让中文读者更容易阅读和理解,而不是作为一个分支。 因此, 如果您对此文件有任何意见或更新,请先尝试更新原始英文文件。

Note

如果您发现本文档与原始文件有任何不同或者有翻译问题,请联系该文件的译者, 或者请求时奎亮的帮助:<alexs@kernel.org>。

Original:

Security bugs

译者:

吴想成 Wu XiangCheng <bobwxc@email.cn> 慕冬亮 Dongliang Mu <dzm91@hust.edu.cn>

安全缺陷

Linux内核开发人员非常重视安全性。因此我们想知道何时发现了安全漏洞,以便尽快 修复和披露。请向Linux内核安全团队报告安全漏洞。

联络

可以通过电子邮件<security@kernel.org>联系Linux内核安全团队。这是一个安全人员 的私有列表,他们将帮助验证错误报告并开发和发布修复程序。如果您已经有了一个 修复,请将其包含在您的报告中,这样可以大大加快处理进程。安全团队可能会从区域维护 人员那里获得额外的帮助,以理解和修复安全漏洞。

与任何缺陷一样,提供的信息越多,诊断和修复就越容易。如果您不清楚哪些信息有用, 请查看“报告问题”中 概述的步骤。任何利用漏洞的攻击代码都非常有用,未经报告者同意不会对外发布, 除非已经公开。

请尽可能发送无附件的纯文本电子邮件。如果所有的细节都藏在附件里,那么就很难对 一个复杂的问题进行上下文引用的讨论。把它想象成一个 常规的补丁提交 (即使你还没有补丁): 描述问题和影响,列出复现步骤,然后给出一个建议的解决方案,所有这些都是纯文本的。

披露和限制信息

安全列表不是公开渠道。为此,请参见下面的协作。

一旦开发出了健壮的补丁,发布过程就开始了。对公开的缺陷的修复会立即发布。

尽管我们倾向于在未公开缺陷的修复可用时即发布补丁,但应报告者或受影响方的请求, 这可能会被推迟到发布过程开始后的7日内,如果根据缺陷的严重性需要更多的时间, 则可额外延长到14天。推迟发布修复的唯一有效原因是为了适应QA的逻辑和需要发布 协调的大规模部署。

虽然可能与受信任的个人共享受限信息以开发修复,但未经报告者许可,此类信息不会 与修复程序一起发布或发布在任何其他披露渠道上。这包括但不限于原始错误报告和 后续讨论(如有)、漏洞、CVE信息或报告者的身份。

换句话说,我们唯一感兴趣的是修复缺陷。提交给安全列表的所有其他资料以及对报告 的任何后续讨论,即使在解除限制之后,也将永久保密。

与其他团队协调

虽然内核安全团队仅关注修复漏洞,但还有其他组织关注修复发行版上的安全问题以及协调 操作系统厂商的漏洞披露。协调通常由 “linux-distros” 邮件列表处理,而披露则由 公共 “oss-security” 邮件列表进行。两者紧密关联且被展示在 linux-distros 维基: <https://oss-security.openwall.org/wiki/mailing-lists/distros>

请注意,这三个列表的各自政策和规则是不同的,因为它们追求不同的目标。内核安全团队 与其他团队之间的协调很困难,因为对于内核安全团队,保密期(即最大允许天数)是从补丁 可用时开始,而 “linux-distros” 则从首次发布到列表时开始计算,无论是否存在补丁。

因此,内核安全团队强烈建议,作为一位潜在安全问题的报告者,在受影响代码的维护者 接受补丁之前,且在您阅读上述发行版维基页面并完全理解联系 “linux-distros” 邮件列表会对您和内核社区施加的要求之前,不要联系 “linux-distros” 邮件列表。 这也意味着通常情况下不要同时抄送两个邮件列表,除非在协调时有已接受但尚未合并的补丁。 换句话说,在补丁被接受之前,不要抄送 “linux-distros”;在修复程序被合并之后, 不要抄送内核安全团队。

CVE分配

安全团队不分配 CVE,同时我们也不需要 CVE 来报告或修复漏洞,因为这会使过程不必要 的复杂化,并可能延误漏洞处理。如果报告者希望为确认的问题分配一个 CVE 编号, 可以联系 内核 CVE 分配团队 获取。

保密协议

Linux内核安全团队不是一个正式的机构实体,因此无法签订任何保密协议。