openEuler 内核漏洞处理规范

修订记录

1. 前言

安全漏洞修复是openEuler内核维护的一个非常重要的组成部分，为更快的响应漏洞，openEuler社区拟专门成立“openEuler 内核漏洞应急响应小组”（以下简称“应急小组”）。为指导和规范应急小组的工作，特制定“openEuler 内核漏洞处理规范”，以下简称“本规范”。

本规范的上位文档是openEuler社区的“漏洞管理”规范。应急小组是 openEuler Kernel SIG 下设的专项工作组，并接受openEuler技术委员会（以下简称 TC）和openEuler安全委员会（以下简称“安全委员会”）的指导和监督。

2. 漏洞处理要求

openEuler 社区根据漏洞的严重等级采取差异化的修复策略，制定了漏洞修复的时间要求，牵引社区快速修复高风险漏洞。安全委员会也将结合漏洞的舆情和利用情况等指标，识别高危漏洞，在1~3天内完成修复，降低漏洞被利用的风险。由于漏洞修复是一个复杂的工作，社区不能保证所有的漏洞修复都能按照预期完成。

不同等级漏洞的目标修复时长：

3. 漏洞感知

openEuler 漏洞感知由安全委员会负责。感知到内核漏洞后，自动（或人工）提交 issue 到 src-openeuler/kernel。gitee 感知到漏洞提交，会自动通过邮件通知应急小组成员。

如果遇到有漏洞安全委员会没有感知到的情况，可以人工录入。

4. 漏洞处理流程

图片来源: https://www.openeuler.org/zh/security/vulnerability-reporting/

上图是openEuler社区漏洞处理流程图。应急小组需要处理图中的：漏洞评估、漏洞影响描述、补丁开发（含提交与合入）、补丁验证等四个环节。

4.1 漏洞评估

4.1.1 感知到漏洞之后，需要评估漏洞的严重程度及影响。业界普遍使用CVSS标准评估漏洞的严重性，openEuler在使用CVSSv3进行漏洞评估时，需要设定漏洞攻击场景，基于在该攻击场景下的实际影响进行评估。漏洞严重等级评估是指针对漏洞利用难易程度，以及利用后对机密性、完整性、可用性的影响进行评估，并生成一个评分值。

4.1.2 CVSS基础评分与受影响组件的版本号，提供和使用的方式，平台以及软件的编译方式相关，NVD评分考虑了漏洞被利用的所有场景，而openEuler是基于上游社区自己构建的，主要应用于服务器场景，所以对于openEuler开源产品来说，直接采用NVD评分是不合适的，因此openEuler对所有受影响的CVE有自己的评分，存在打分和NVD不同的情况。

详细的漏洞评估标准，请参考：openEuler社区的“漏洞管理”规范。

4.1.3 评估结果，更新到对应的 issue 中。

4.2 漏洞影响描述

评估 openEuler 哪些版本受该漏洞影响，并将评估结果更新到对应的 issue 中。

4.3 补丁开发（或称“漏洞修复”）

4.3.1 漏洞修复，一般分为以下几种情况：

1. 不受影响：分析确认版本不涉及，影响分析中将对应版本标记为“不受影响”，之后可关闭CVE。
2. 受影响，补丁已合入：分析确认版本已修复，影响分析中将对应版本标记为“已完成”，关联合入修复的PR，之后可关闭CVE。
3. 受影响，上游社区有补丁：回合社区对应版本补丁进行修复。
4. 受影响，上游社区无补丁：如业界有解决方案，需自研补丁进行修复。
5. 受影响，上游社区无补丁，业务无解决方案：挂起跟踪业界/社区修复。

4.3.2 上述第1、2两种情况，只需将分析结果更新到对应 issue。安全委员会会对评估为不受影响的漏洞进行复核。

4.3.3 上述第3、4两种情况，修复补丁需遵循 openEuler kernel 社区规范，通过 PR 向 openEuler/kernel 提交补丁。PR 中可以包含对一个或多个CVE的修复补丁。

4.3.4 CVE 的修复补丁的 commit message 中须包含对应的 CVE ID, 如 CVE: CVE-2022-1234。

4.4 补丁验证

4.4.1 如果业界有CVE验证用例，提交 PR 时，须验证通过后提交。

4.4.2 修复 CVE 漏洞的 PR，须由应急小组组长/副组长和对应的子系统 Committer 同时 Review 方可合入。

5. 漏洞应急小组

5.1 应急小组的组成和产生

5.1.1 组成与职责

5.1.2 组长、副组长任期 6 or 12 个月，可以连选连任。

5.1.3 轮值组长，轮值期为1个月（或4周）。

5.1.4 组长、副组长的产生：

1. 组长由 Kernel SIG 提名，应急小组全员投票，如反对票数< 50%，则当选，否则重新提名选举。
2. 副组长由 Kernel SIG 提名，及组员自荐，如提名人数≤2，则自动当选；如提名人数＞2，则差额选举，得票最高的两人当选。
3. 如组长缺位，由当月的轮值组长兼任，并与 Kernel SIG 协商，确定是否补选。
4. 组长、副组长选举完成，报TC或安全委员会批准生效。

5.2 应急小组的运作

5.2.1 应急小组的沟通和例会

1. 应急小组日常通过邮件辅以即时通信软件进行交流；
2. 应急小组每月至少组织两次例会，对齐和沟通日常漏洞修复；
3. 应急小组例会由轮值组长组织和主持；
4. 应急小组例会参与范围：组员。需要时，可以邀请辅导员、Kernel SIG 的 Maintainer 或 领域专家参与。
5. 应急小组的例会可以不公开；
6. 应急小组的沟通邮件的发送范围：组员、辅导员、Kernel SIG Maintainer 或 子版本/分支的Committer、TC 中负责安全的委员，不发送公开的邮件列表。

5.2.2 漏洞状态跟踪与报告

1. 轮值组长应跟踪和督促组员及时修复漏洞，确保漏洞在要求的期限内完成修复与合入。
2. 轮值组长发现漏洞修复存在逾期风险，应及时协调资源，上报风险。风险上报途径：Kernel SIG、安全委员会。
3. 轮值组长应每周两次邮件汇报漏洞修复状态，邮件发送范围除5.2.1节中要求的范围，还应抄送Release SIG 的 Maintainer。
4. 组长每季度可以到 Kernel SIG 或安全委员会汇报漏洞修复情况及应急小组运作情况。

5.2.3 漏洞处理分工

1. 小组内部协商制定分工策略，如有分歧可与 Kernel SIG 协商解决，或上升至 TC 或安全委员会。
2. 分工可以按照版本、分支、领域、子系统等维度，进行分工，必要时协调领域专家参与或协助。

5.2.4 紧急漏洞监测和处理

1. 轮值组长负责检测社区漏洞情况，如有紧急漏洞，可召开临时会议，商讨漏洞修复策略或协调专家参与。
2. 紧急漏洞处理，可以组成由安全委员会委员、Kernel SIG 专家、Kernel SIG 版本/分支负责人、组成的专项小组商讨修复策略。

5.3 应急小组的激励

5.3.1 每年，由 Kernel SIG 提名，安全委员会批准，评选优秀安全工程师，进行激励。

5.3.2 是否可以申请更多的激励或赞助？

6. 本规范的修改

6.1 修改的提出

6.1.1 由应急小组2人或以上，可以共同提出修改建议；

6.1.2 Kernel SIG 可以提出修改建议；

6.1.3 安全委员会委员、TC 委员可以提出修改建议；

6.2 修改的评审和审批

6.2.1 Kernel SIG 评审修复方案后，报安全委员会和TC审批生效。