0001 .. include:: ../disclaimer-zh_CN.rst
0002
0003 :Original: :doc:`../../../admin-guide/security-bugs`
0004
0005 :译者:
0006
0007 吴想成 Wu XiangCheng <bobwxc@email.cn>
0008
0009 安全缺陷
0010 =========
0011
0012 Linux内核开发人员非常重视安全性。因此我们想知道何时发现了安全漏洞，以便尽快
0013 修复和披露。请向Linux内核安全团队报告安全漏洞。
0014
0015 联络
0016 -----
0017
0018 可以通过电子邮件<security@kernel.org>联系Linux内核安全团队。这是一个安全人员
0019 的私有列表，他们将帮助验证错误报告并开发和发布修复程序。如果您已经有了一个
0020 修复，请将其包含在您的报告中，这样可以大大加快进程。安全团队可能会从区域维护
0021 人员那里获得额外的帮助，以理解和修复安全漏洞。
0022
0023 与任何缺陷一样，提供的信息越多，诊断和修复就越容易。如果您不清楚哪些信息有用，
0024 请查看“Documentation/translations/zh_CN/admin-guide/reporting-issues.rst”中
0025 概述的步骤。任何利用漏洞的攻击代码都非常有用，未经报告者同意不会对外发布，除
0026 非已经公开。
0027
0028 请尽可能发送无附件的纯文本电子邮件。如果所有的细节都藏在附件里，那么就很难对
0029 一个复杂的问题进行上下文引用的讨论。把它想象成一个
0030 :doc:`常规的补丁提交 <../process/submitting-patches>` （即使你还没有补丁）：
0031 描述问题和影响，列出复现步骤，然后给出一个建议的解决方案，所有这些都是纯文本的。
0032
0033 披露和限制信息
0034 ---------------
0035
0036 安全列表不是公开渠道。为此，请参见下面的协作。
0037
0038 一旦开发出了健壮的补丁，发布过程就开始了。对公开的缺陷的修复会立即发布。
0039
0040 尽管我们倾向于在未公开缺陷的修复可用时即发布补丁，但应报告者或受影响方的请求，
0041 这可能会被推迟到发布过程开始后的7日内，如果根据缺陷的严重性需要更多的时间，
0042 则可额外延长到14天。推迟发布修复的唯一有效原因是为了适应QA的逻辑和需要发布
0043 协调的大规模部署。
0044
0045 虽然可能与受信任的个人共享受限信息以开发修复，但未经报告者许可，此类信息不会
0046 与修复程序一起发布或发布在任何其他披露渠道上。这包括但不限于原始错误报告和
0047 后续讨论（如有）、漏洞、CVE信息或报告者的身份。
0048
0049 换句话说，我们唯一感兴趣的是修复缺陷。提交给安全列表的所有其他资料以及对报告
0050 的任何后续讨论，即使在解除限制之后，也将永久保密。
0051
0052 协调
0053 ------
0054
0055 对敏感缺陷（例如那些可能导致权限提升的缺陷）的修复可能需要与私有邮件列表
0056 <linux-distros@vs.openwall.org>进行协调，以便分发供应商做好准备，在公开披露
0057 上游补丁时发布一个已修复的内核。发行版将需要一些时间来测试建议的补丁，通常
0058 会要求至少几天的限制，而供应商更新发布更倾向于周二至周四。若合适，安全团队
0059 可以协助这种协调，或者报告者可以从一开始就包括linux发行版。在这种情况下，请
0060 记住在电子邮件主题行前面加上“[vs]”，如linux发行版wiki中所述：
0061 <http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>。
0062
0063 CVE分配
0064 --------
0065
0066 安全团队通常不分配CVE，我们也不需要它们来进行报告或修复，因为这会使过程不必
0067 要的复杂化，并可能耽误缺陷处理。如果报告者希望在公开披露之前分配一个CVE编号，
0068 他们需要联系上述的私有linux-distros列表。当在提供补丁之前已有这样的CVE编号时，
0069 如报告者愿意，最好在提交消息中提及它。
0070
0071 保密协议
0072 ---------
0073
0074 Linux内核安全团队不是一个正式的机构实体，因此无法签订任何保密协议。
