openEuler 内核漏洞处理规范
修订记录
| 日期 | 版本 | 修改描述 | 作者 |
|---|---|---|---|
| 2022-8-24 | 0.1 | 初稿 | 谢秀奇、郭梦琪、郑增凯 |
1. 前言
安全漏洞修复是openEuler内核维护的一个非常重要的组成部分，为更快的响应漏洞，openEuler社区拟专门成立“openEuler 内核漏洞应急响应小组”（以下简称“应急小组”）。为指导和规范应急小组的工作，特制定“openEuler 内核漏洞处理规范”，以下简称“本规范”。
本规范的上位文档是openEuler社区的“漏洞管理”规范。应急小组是 openEuler Kernel SIG 下设的专项工作组，并接受openEuler技术委员会（以下简称 TC）和openEuler安全委员会（以下简称“安全委员会”）的指导和监督。
2. 漏洞处理要求
openEuler 社区根据漏洞的严重等级采取差异化的修复策略，制定了漏洞修复的时间要求，牵引社区快速修复高风险漏洞。安全委员会也将结合漏洞的舆情和利用情况等指标，识别高危漏洞，在1~3天内完成修复，降低漏洞被利用的风险。由于漏洞修复是一个复杂的工作，社区不能保证所有的漏洞修复都能按照预期完成。
不同等级漏洞的目标修复时长：
| 严重等级（Severity Rating） | CVSS评分（Score） | 漏洞修复时长（SLO) |
|---|---|---|
| 致命（Critical） | 9.0 - 10.0 | 7天 |
| 高（High） | 7.0 - 8.9 | 14天 |
| 中（Medium） | 4.0 - 6.9 | 30天 |
| 低（Low） | 0.1 - 3.9 | 30天 |
| 无（None） | 0.0 | - |
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 漏洞修复，一般分为以下几种情况：
- 不受影响：分析确认版本不涉及，影响分析中将对应版本标记为“不受影响”，之后可关闭CVE。
- 受影响，补丁已合入：分析确认版本已修复，影响分析中将对应版本标记为“已完成”，关联合入修复的PR，之后可关闭CVE。
- 受影响，上游社区有补丁：回合社区对应版本补丁进行修复。
- 受影响，上游社区无补丁：如业界有解决方案，需自研补丁进行修复。
- 受影响，上游社区无补丁，业务无解决方案：挂起跟踪业界/社区修复。
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 组成与职责
| 角色 | 职责与要求 |
|---|---|
| 组长 1 人 | 总体负责应急小组运作，定期向安全委员会汇报漏洞修复状态 |
| 副组长2人 | 协助组长组织漏洞修复和应急小组的运作 |
| 轮值组长 | 由组长和副组长轮流担任，负责漏洞分发、会议组织、进展汇报等 |
| 辅导员 | 由安全委员会委员，或负责安全的TC委员担任，指导和监督漏洞修复的运作 |
| 组员 | 除辅导员以外的其他成员，协同负责漏洞的评估、修复、验证等工作 |
5.1.2 组长、副组长任期 6 or 12 个月，可以连选连任。
5.1.3 轮值组长，轮值期为1个月（或4周）。
5.1.4 组长、副组长的产生：
- 组长由 Kernel SIG 提名，应急小组全员投票，如反对票数< 50%，则当选，否则重新提名选举。
- 副组长由 Kernel SIG 提名，及组员自荐，如提名人数≤2，则自动当选；如提名人数＞2，则差额选举，得票最高的两人当选。
- 如组长缺位，由当月的轮值组长兼任，并与 Kernel SIG 协商，确定是否补选。
- 组长、副组长选举完成，报TC或安全委员会批准生效。
5.2 应急小组的运作
5.2.1 应急小组的沟通和例会
- 应急小组日常通过邮件辅以即时通信软件进行交流；
- 应急小组每月至少组织两次例会，对齐和沟通日常漏洞修复；
- 应急小组例会由轮值组长组织和主持；
- 应急小组例会参与范围：组员。需要时，可以邀请辅导员、Kernel SIG 的 Maintainer 或 领域专家参与。
- 应急小组的例会可以不公开；
- 应急小组的沟通邮件的发送范围：组员、辅导员、Kernel SIG Maintainer 或 子版本/分支的Committer、TC 中负责安全的委员，不发送公开的邮件列表。
5.2.2 漏洞状态跟踪与报告
- 轮值组长应跟踪和督促组员及时修复漏洞，确保漏洞在要求的期限内完成修复与合入。
- 轮值组长发现漏洞修复存在逾期风险，应及时协调资源，上报风险。风险上报途径：Kernel SIG、安全委员会。
- 轮值组长应每周两次邮件汇报漏洞修复状态，邮件发送范围除5.2.1节中要求的范围，还应抄送Release SIG 的 Maintainer。
- 组长每季度可以到 Kernel SIG 或安全委员会汇报漏洞修复情况及应急小组运作情况。
5.2.3 漏洞处理分工
- 小组内部协商制定分工策略，如有分歧可与 Kernel SIG 协商解决，或上升至 TC 或安全委员会。
- 分工可以按照版本、分支、领域、子系统等维度，进行分工，必要时协调领域专家参与或协助。
5.2.4 紧急漏洞监测和处理
- 轮值组长负责检测社区漏洞情况，如有紧急漏洞，可召开临时会议，商讨漏洞修复策略或协调专家参与。
- 紧急漏洞处理，可以组成由安全委员会委员、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审批生效。