x024n/almalinux-januscape-mitigation
GitHub: x024n/almalinux-januscape-mitigation
面向 AlmaLinux 9.5 生产环境的 Januscape 等 KVM 漏洞缓解指南与脚本，提供分阶段的宿主机安全加固操作流程。
Stars: 0 | Forks: 0
# AlmaLinux 9.5 — 缓解 Januscape (CVE-2026-53359) & Bad Epoll (CVE-2026-46242)
针对运行**多个 VPS 客户端 (KVM)** 的 **AlmaLinux 9 / 9.5** 宿主机提供的**生产级安全**、分步操作指南。
## 摘要（请先阅读此部分）
| 项目 | 详情 |
|------|--------|
| **主要 CVE** | **CVE-2026-53359** — *Januscape* — KVM/x86 **客户机 -> 宿主机逃逸**（+ 宿主机 DoS） |
| **附加 CVE (Alma 9)** | **CVE-2026-46242** — *Bad Epoll* — 本地非特权用户 LPE -> root |
| **易受攻击群体** | 使用 **KVM**（Intel/AMD）的 x86_64 宿主机，多租户 VPS |
| **彻底修复** | 将内核更新至 **≥ `5.14.0-687.23.1.el9_8`**，然后**重启宿主机** |
| **临时缓解措施** | 禁用 **nested virtualization** + 限制对 **`/dev/kvm`** 的访问 |
| **不重启宿主机？** | 可以实施**部分**软缓解措施；**在虚拟机运行时卸载 KVM 模块 = 危险 / 不可能** |
### 生产环境原则
1. **切勿**在生产宿主机上运行 PoC / exploit。
2. 当还有客户机在运行时，**切勿**执行 `rmmod kvm*`。
3. 先进行软缓解（关闭 nested + 修改权限），然后安排**计划内的宿主机重启**以打补丁。
4. 重启前（如果是 cluster）将 VPS 实时迁移到其他节点。
5. 在**每个**步骤后进行验证。
## 目录
1. [什么是 Januscape？](#1-apa-itu-januscape)
2. [你的宿主机受影响吗？](#2-apakah-host-kamu-terdampak)
3. [生产环境策略（决策流程）](#3-strategi-production-alur-keputusan)
4. [阶段 0 — 安全预检查（只读）](#4-fase-0--pre-check-aman-read-only)
5. [阶段 1 — 软缓解（最少重启）](#5-fase-1--soft-mitigasi-minim-reboot)
6. [阶段 2 — 内核补丁（彻底修复，需重启宿主机）](#6-fase-2--patch-kernel-fix-penuh-perlu-reboot-host)
7. [阶段 3 — 缓解后验证](#7-fase-3--verifikasi-pasca-mitigasi)
8. [禁止事项](#8-yang-tidak-boleh-dilakukan)
9. [常见问题解答 (FAQ)](#9-faq)
10. [脚本](#10-script)
11. [官方参考资料](#11-referensi-resmi)
12. [免责声明](#12-disclaimer)
## 1. 什么是 Januscape？
**Januscape (CVE-2026-53359)** 是存在于 **KVM/x86**（Intel & AMD）中的一个漏洞，它允许：
| 影响 | 说明 |
|--------|------------|
| **客户机到宿主机的逃逸** | 恶意客户机可以在**宿主机**上以 root 身份执行代码 |
| **宿主机 DoS** | 客户机可以触发宿主机的 **kernel panic** -> 该节点上的所有 VPS 都会宕机 |
| **本地 LPE** | 如果 `/dev/kvm` 是全局可写的（`0666`，这在许多 RHEL 系系统中是默认设置），无特权的本地用户**无需**虚拟机即可提权至 root |
简要来源：
- [AlmaLinux — Januscape and Bad Epoll](https://almalinux.org/blog/2026-07-06-januscape-bad-epoll/)
- [Ubuntu 缓解措施](https://ubuntu.com/blog/januscape-linux-vulnerability-mitigations-available)
- [Red Hat CVE-2026-53359](https://access.redhat.com/security/cve/cve-2026-53359)
- 研究人员的分析文章：[V4bel/Januscape](https://github.com/V4bel/Januscape)（切勿在生产环境中运行）
**Bad Epoll (CVE-2026-46242)**（AlmaLinux 9 & 10）：epoll 子系统中的 UAF 竞争条件 -> 本地 LPE。该漏洞的修复包含在 AlmaLinux 发布的**同一个内核**中。
## 2. 你的宿主机受影响吗？
### 快速检查（只读，安全）
```
# OS
cat /etc/os-release | egrep 'NAME|VERSION'
# Kernel
uname -r
rpm -q kernel
# KVM 模块
lsmod | egrep 'kvm|kvm_intel|kvm_amd'
# 开启 Nested？ (Y/1 = Nested 路径易受攻击；N/0 = 关闭 Nested)
grep -H . /sys/module/kvm_intel/parameters/nested 2>/dev/null
grep -H . /sys/module/kvm_amd/parameters/nested 2>/dev/null
# /dev/kvm 权限 (0666 = 在多用户主机中非常宽松)
namei -l /dev/kvm 2>/dev/null
stat -c '%a %U:%G %n' /dev/kvm 2>/dev/null
getfacl /dev/kvm 2>/dev/null | head
# 有 guest 吗？
# libvirt：
virsh list --all 2>/dev/null | head
# 或 qemu 进程：
ps aux | egrep 'qemu-system|qemu-kvm' | grep -v grep | wc -l
```
或者：
```
sudo bash scripts/00-precheck.sh
```
### 结果判读
| 状态 | 情况 |
|---------|--------|
| 无 `kvm` 模块 / 不是 hypervisor | Januscape KVM **关联不大**（但如果是 Alma 9，仍需更新内核以防范 Bad Epoll） |
| `nested=Y` 或 `1` | **nested virt** 路径处于活动状态 — 优先进行软缓解 |
| 内核 **< `5.14.0-687.23.1.el9_8`** | 尚未修补 Januscape+Bad Epoll（针对 Alma 9 生产环境） |
| 内核 **≥ `5.14.0-687.23.1.el9_8`** 且已重启至该内核 | 已彻底修复（通过 `uname -r` 确认） |
| `/dev/kvm` 权限为 `666` | 本地 LPE 变得更容易 — **请锁定权限** |
## 3. 生产环境策略（决策流程）
```
┌─────────────────────┐
│ Host KVM multi-VPS? │
└──────────┬──────────┘
│ ya
┌──────────▼──────────┐
│ Kernel sudah patched│
│ + sudah boot ke sana│
└──────────┬──────────┘
belum │ │ ya
┌────────────▼──┐ ┌──▼────────────┐
│ Soft mitigasi │ │ Verifikasi + │
│ (Fase 1) │ │ monitoring │
└────────────┬──┘ └───────────────┘
│
┌────────────▼──────────────────────┐
│ Jadwalkan maintenance: │
│ migrate VPS (jika bisa) → │
│ dnf upgrade kernel → reboot host │
│ (Fase 2) │
└───────────────────────────────────┘
```
| 优先级 | 操作 | 是否重启宿主机？ | 对 VPS 客户端的风险 |
|-----------|----------|--------------|----------------------|
| **P0** | 软缓解：nested=0（持久化）+ 检查无 nested guest | 如果仅写入配置，通常**不需要**；**完全生效**往往需要重载模块 / 重启 | Nested guest（如果有）将会损坏 |
| **P0** | 软缓解：`/dev/kvm` 权限不是 0666 | **否** | 不会关闭现有虚拟机 |
| **P1** | 打内核补丁 + 重启宿主机 | **是** | 该节点上的所有 VPS 将随宿主机一起重启（除非事先进行实时迁移） |
## 4. 阶段 0 — 安全预检查（只读）
**仅运行只读命令**。不会修改系统。
```
sudo bash scripts/00-precheck.sh | tee /root/januscape-precheck-$(date +%F).txt
```
保存输出。这对于审计和内部工单非常有用。
手动检查清单：
- [ ] 已记录运行中的 VPS 数量
- [ ] 已记录 Nested 状态
- [ ] 已记录 `uname -r`
- [ ] 备份/迁移计划已就绪
- [ ] 宿主机的 IPMI/iDRAC/控制台访问权限已就绪
## 5. 阶段 1 — 软缓解（最少重启）
### 5.1 禁用 nested virtualization（持久化）
这是 Ubuntu/Proxmox/Red Hat 公开指南中建议在等待重启至已修补内核期间采取的缓解措施：
- [Ubuntu — 禁用 nested](https://ubuntu.com/blog/januscape-linux-vulnerability-mitigations-available)
- [Red Hat CVE 页面 — modprobe 选项](https://access.redhat.com/security/cve/cve-2026-53359)
- [Proxmox 论坛 — nested=0](https://forum.proxmox.com/threads/are-there-mitigations-available-for-cve-2026-53359-januscape.184874/)
#### A) 首先检查：是否有客户机**正在使用** nested？
```
# Libvirt：查找 CPU 模式 host-passthrough + nested feature，或 XML 中的 vmx/svm feature
virsh list --name 2>/dev/null | while read -r vm; do
[ -z "$vm" ] && continue
echo "=== $vm ==="
virsh dumpxml "$vm" 2>/dev/null | egrep -i 'nested|vmx|svm|host-passthrough|host-model' | head -20
done
```
如果**有客户端特意在 VPS 内部使用 nested KVM**：
- 软缓解 nested=0 将**破坏他们的功能**
- 需先进行协调，或者优先在不关闭 nested 的情况下进行**补丁修复 + 重启**（内核修复后，可根据需要重新打开 nested）
如果**没有** nested guest（大多数共享 VPS 的情况）：
#### B) 写入永久配置（安全，不会自行触发重启）
```
sudo tee /etc/modprobe.d/disable-kvm-nested.conf >/dev/null <<'EOF'
# Januscape CVE-2026-53359 临时缓解措施
# 参考：https://ubuntu.com/blog/januscape-linux-vulnerability-mitigations-available
# https://access.redhat.com/security/cve/cve-2026-53359
options kvm_intel nested=0
options kvm_amd nested=0
EOF
# 确保没有其他文件强制 nested=1
grep -rni 'nested' /etc/modprobe.d/ || true
```
这对于**下次加载模块**（在宿主机重启或重载模块后）是**持久化**的。
#### C) **不重启**的情况下激活 nested=0 — **仅当没有正在运行的客户机时**
Ubuntu 文档显示的模式：
```
# 仅当：virsh list --state-running 为空 / 没有 qemu 时
sudo rmmod kvm_amd 2>/dev/null || true
sudo rmmod kvm_intel 2>/dev/null || true
sudo rmmod kvm 2>/dev/null || true
sudo modprobe kvm
sudo modprobe kvm_intel # atau kvm_amd
```
**在运行着数十个 VPS 的生产环境中：切勿执行 rmmod。**
KVM 模块**正在被**客户机使用 -> `rmmod` 将**失败**或**非常危险**。
| 情况 | 应用 nested=0 的方法 |
|---------|---------------------|
| **0 个客户机运行中** | 可以重载模块（无需重启 OS） |
| **有客户机运行中** | 仅写入 `/etc/modprobe.d/...`；在**宿主机重启**（阶段 2）或维护排空时完全生效 |
| 集群 / 实时迁移 | 将所有 VM 迁移出该节点 -> 重载模块或重启空节点 |
重载/重启后检查运行时状态：
```
grep -H . /sys/module/kvm_intel/parameters/nested 2>/dev/null
grep -H . /sys/module/kvm_amd/parameters/nested 2>/dev/null
# 缓解预期：0 或 N
```
脚本：
```
sudo bash scripts/01-soft-mitigation-nested.sh
# 默认：仅写入 config，不执行 rmmod
# 强制重新加载 (如果有 VM 则很危险)：
# sudo bash scripts/01-soft-mitigation-nested.sh --reload-modules
```
### 5.2 锁定 `/dev/kvm` 权限（无需重启）
Alma/RHEL 系统的 `/dev/kvm` 权限通常过于宽松；AlmaLinux 博客提到 **0666** 会使本地 LPE 变得更容易。
```
# 立即查看
stat -c '%a %U:%G %n' /dev/kvm
# 运行时 (直接生效，无需重启) — 严格示例：
# root:kvm, mode 660 (仅限 root + kvm 组)
sudo chown root:kvm /dev/kvm
sudo chmod 660 /dev/kvm
# 通过 udev 持久化 (示例)
sudo tee /etc/udev/rules.d/99-kvm-restrict.rules >/dev/null <<'EOF'
# 加固 /dev/kvm — 减少非特权本地访问 (Januscape LPE 路径)
KERNEL=="kvm", GROUP="kvm", MODE="0660"
EOF
sudo udevadm control --reload-rules
sudo udevadm trigger --name-match=kvm
stat -c '%a %U:%G %n' /dev/kvm
```
**生产环境注意事项：**
- 确保 hypervisor 服务用户（`qemu`, `libvirt-qemu` 等）仍处于正确的组中。
- 不要将其锁定到导致 **libvirtd/qemu 无法打开** `/dev/kvm` 的地步。
- 测试：`virsh list` 仍然正常，并创建一个非关键测试 VM。
```
sudo bash scripts/02-soft-mitigation-devkvm.sh
```
### 5.3 （可选）限制允许创建 VM 的人员
- 切勿让不受信任的用户加入 `kvm` / `libvirt` 组。
- VPS 控制面板：除非必要，否则不要向客户暴露 nested CPU flag。
- SELinux：保持 **enforcing** 状态（切勿将其作为“缓解措施”关闭）。
## 6. 阶段 2 — 内核补丁（彻底修复，需重启宿主机）
### 已修复的 AlmaLinux 9 内核（生产环境）
根据 [AlmaLinux 博客](https://almalinux.org/blog/2026-07-06-januscape-bad-epoll/)：
| 发行版 | 已修复内核（最低版本） |
|---------|---------------------------|
| AlmaLinux 9 | **`kernel-5.14.0-687.23.1.el9_8`** 或更新版本 |
| AlmaLinux 8 | `kernel-4.18.0-553.141.2.el8_10`+ |
| AlmaLinux 10 | `kernel-6.12.0-211.31.1.el10_2`+ |
生产环境的补丁已进入主仓库（不再需要 testing 仓库）。
### 6.1 维护计划（多租户环境必做）
1. 向客户宣布维护窗口。
2. 对关键 VPS 进行快照/备份（根据策略）。
3. 如果有**集群**：将 VPS 实时迁移到其他节点 -> 清空节点 -> 升级 -> 重启 -> 迁移回来。
4. 如果是**单节点**：该节点上所有 VPS 的停机时间 = 宿主机的重启时长。
### 6.2 更新（重启前）
```
# 干净的 Metadata
sudo dnf clean metadata
sudo dnf makecache
# 查看将要安装的 kernel
sudo dnf list --available 'kernel*' | egrep 'kernel.x86_64|kernel-core' | tail -20
# 升级 (建议进行完整的安全更新，至少更新 kernel*)
sudo dnf upgrade -y 'kernel*'
# 或完整更新：
# sudo dnf upgrade -y
# 确保新 kernel 已安装到磁盘上 (不一定正在运行)
rpm -q kernel kernel-core | sort -V
```
**切勿**在维护窗口之外自动重启。需手动重启：
```
# 最终检查 guest 数量
virsh list --state-running
# 同步并重启 HOST
sudo sync
sudo reboot
```
### 6.3 重启后
```
uname -r
# 必须 >= 5.14.0-687.23.1.el9_8 (与 sort -V 进行比较)
rpm -q kernel
# Nested：符合策略 (可以为 0；如果已修补且需要 nested 则为 1)
grep -H . /sys/module/kvm_*/parameters/nested 2>/dev/null
# VPS
virsh list --all
```
```
sudo bash scripts/03-patch-kernel.sh
# 脚本不会自动重启；仅执行 dnf upgrade kernel* + 打印重启说明
```
## 7. 阶段 3 — 缓解后验证
```
sudo bash scripts/04-verify.sh
```
检查清单：
- [ ] `uname -r` ≥ 已修补版本
- [ ] 无新的 Oops/panic：`journalctl -k -p err --since "1 hour ago"`
- [ ] Nested 状态符合策略
- [ ] `/dev/kvm` 权限不是 `666`
- [ ] Libvirt/qemu 状态健康
- [ ] 抽样 VPS 的网络/磁盘正常
## 8. 禁止事项
| 切勿 | 原因 |
|--------|--------|
| 在生产环境中运行 Januscape PoC | 可能导致**宿主机 panic** / 逃逸 |
| 在虚拟机运行时执行 `rmmod kvm*` | 会失败或断开所有客户机的连接 |
| 在未通知客户的情况下重启宿主机 | 造成大规模停机 |
| 为了“图方便”关闭 SELinux | 扩大了攻击面 |
| 假设软缓解 = 已完全安全 | 关闭 nested 可减少途径；**内核补丁仍是强制性的** |
| 仅给 1 个节点打补丁而忘记其他节点 | 需要审计所有 x86 KVM hypervisor |
## 9. 常见问题解答 (FAQ)
### 是否可以 100% 不重启？
- **软缓解**（modprobe 文件 + chmod/udev）：**无需重启**。
- 在运行时**不重启关闭 nested**：仅当模块可以重载时 -> **要求该节点上有 0 个客户机**。
- **彻底修复 CVE（内核代码）**：**需要引导至新内核** -> 重启宿主机（如果供应商提供，可使用企业级 live-patch；Alma 标准方式 = 重启）。
### 关闭 nested 会断开普通 VPS 吗通常**不会**。普通 VPS 不会在客户机内部运行 hypervisor。
受影响的是**特意**使用 nested virt 的客户（在共享主机中很少见）。
### 宿主机不是 KVM（仅 OpenVZ/LXC）？
Januscape = **KVM/x86**。如果宿主机是**纯容器**且没有 KVM，则 KVM 客户机逃逸路径不适用 — 但仍需检查 Bad Epoll 并更新内核。
### Virtuozzo / OpenVZ 7？
不是本仓库的重点（内核不同）。对于 Vz7，请遵循供应商的安全公告以及单独的 ReadyKernel/vzkernel 指南。
## 10. 脚本
| 脚本 | 功能 | 生产环境备注 |
|--------|--------|-----------------|
| [`scripts/00-precheck.sh`](scripts/00-precheck.sh) | 只读资产清单 | 安全 |
| [`scripts/01-soft-mitigation-nested.sh`](scripts/01-soft-mitigation-nested.sh) | 写入 nested=0 | 默认**不执行** rmmod |
| [`scripts/02-soft-mitigation-devkvm.sh`](scripts/02-soft-mitigation-devkvm.sh) | 强化 `/dev/kvm` | 检查 libvirt 是否仍正常工作 |
| [`scripts/03-patch-kernel.sh`](scripts/03-patch-kernel.sh) | `dnf upgrade kernel*` | **不**自动重启 |
| [`scripts/04-verify.sh`](scripts/04-verify.sh) | 验证状态 | 安全 |
```
chmod +x scripts/*.sh
sudo bash scripts/00-precheck.sh
sudo bash scripts/01-soft-mitigation-nested.sh
sudo bash scripts/02-soft-mitigation-devkvm.sh
# 维护窗口：
sudo bash scripts/03-patch-kernel.sh
# 然后：sudo reboot
sudo bash scripts/04-verify.sh
```
## 11. 官方参考资料
| 来源 | URL |
|--------|-----|
| AlmaLinux — 生产环境补丁 | https://almalinux.org/blog/2026-07-06-januscape-bad-epoll/ |
| Ubuntu — nested 缓解措施 | https://ubuntu.com/blog/januscape-linux-vulnerability-mitigations-available |
| Red Hat CVE-2026-53359 | https://access.redhat.com/security/cve/cve-2026-53359 |
| CloudLinux 公告 | https://blog.cloudlinux.com/januscape-cve-2026-53359-mitigation-and-kernel-update-on-cloudlinux/ |
| TuxCare 概览 | https://tuxcare.com/blog/januscape-exposes-the-kvm-shadow-paging-bug-that-kept-coming-back/ |
| Proxmox 讨论 | https://forum.proxmox.com/threads/are-there-mitigations-available-for-cve-2026-53359-januscape.184874/ |
| 研究人员分析文章（切勿在生产环境进行 PoC） | https://github.com/V4bel/Januscape |
## 12. 免责声明
- 本指南是为运维人员提供的社区指南。不能替代供应商的公告或法律顾问。
- 如果可能，请在实验室/预发布环境中进行测试。
- 对于执行命令造成的停机或损失，作者不承担责任。
- 请务必将内核版本与最新的 [AlmaLinux 博客](https://almalinux.org/blog/2026-07-06-januscape-bad-epoll/) 进行核对。
## 速查表
```
# 1) 预检查
uname -r
grep . /sys/module/kvm_*/parameters/nested 2>/dev/null
stat -c '%a %n' /dev/kvm
virsh list --state-running | wc -l
# 2) 软缓解 (持久化关闭 nested)
echo -e 'options kvm_intel nested=0\noptions kvm_amd nested=0' | \
sudo tee /etc/modprobe.d/disable-kvm-nested.conf
# 3) 软缓解 (/dev/kvm)
sudo chown root:kvm /dev/kvm; sudo chmod 660 /dev/kvm
# 4) 修复 (维护中)
sudo dnf clean metadata && sudo dnf upgrade -y 'kernel*'
# 迁移 VM 或宣布停机
sudo reboot
# 5) 验证
uname -r # >= 5.14.0-687.23.1.el9_8
```
## License
MIT — 详情见 [LICENSE](LICENSE)。
标签：AlmaLinux, KVM, Web报告查看器, 安全漏洞修复, 应用安全, 本地提权, 系统运维, 虚拟化安全