QEMU 安全模型深度解读威胁边界、隔离机制与安全状态报告机制【免费下载链接】qemuOfficial QEMU mirror. Please see https://www.qemu.org/contribute/ for how to submit changes to QEMU. Pull Requests are disabled. Please only use release tarballs from the QEMU website.项目地址: https://gitcode.com/gh_mirrors/qe/qemu本篇指南基于 docs/system/security.rst 展开系统梳理 QEMU 官方定义的安全需求Security Requirements、安全边界判定范围Security boundary scope、以secure注解为核心的安全状态报告机制以及“客户机隔离 最小权限”的安全架构设计原则并辅以仓库源码如 qapi/compat.json、qapi/qapi-util.c、include/hw/core/boards.h验证实现细节。读完本文你将掌握哪些使用场景被 QEMU 官方视为“受安全支持”、如何用-compat insecure-types与qom-list-types识别不具备安全边界security boundary的机器/设备类型以及安全部署 QEMU 时应遵循的最小权限与隔离加固手段。一、安全需求QEMU 设计要满足的承诺QEMU 支持众多差异极大的使用场景其中部分场景的安全要求远高于其他场景。社区对“用户可依赖的整体安全需求”达成了一致这些需求界定了从安全角度看“什么是被支持的”。需求被划分为两大类虚拟化用例Virtualization Use Case与非虚拟化用例Non-virtualization Use Case。1.1 虚拟化用例唯一提供安全保证的支撑范围虚拟化用例涵盖云主机、虚拟私有服务器VPS托管以及传统数据中心与桌面虚拟化。这类用例依赖硬件虚拟化扩展如 Intel VT-x / AMD-V、ARM 虚拟化扩展在物理 CPU 上以接近原生的速度安全执行客户机代码。在该用例下以下实体被认定为不可信可能自身存在缺陷或被恶意利用客户机Guest面向用户的接口如 VNC、SPICE、WebSocket网络协议如 NBD、在线迁移 live migration用户提供的文件如磁盘镜像、内核、设备树透传设备Passthrough devices如 PCI、USB凡是影响这些实体的缺陷都会被评估“在真实使用场景中是否可能造成损害”若确实可能造成损害则按**安全缺陷security bug**处理。要纳入这套安全支持策略即获得官方安全承诺必须同时满足两个条件使用虚拟化加速器如 KVM 或 HVF使用下方列出的受支持 machine 类型之一。文档同时提醒即使搭配虚拟化加速器其他 machine 类型也可能在“客户机可信”的工作负载下带来更好性能但任何未列入清单的 machine 类型都不应被认为提供客户机隔离或安全保证它们被归入“非虚拟化用例”。受支持的安全 machine 类型清单按目标架构整理目标架构受安全支持的 machine 类型aarch64virti386, x86_64microvm、xenfv、xenpv、xenpvh、pc、q35s390xs390-ccw-virtioloongarch64virtppc64pseriesriscv32, riscv64virt以 aarch64 的virt机器为例其最新版本宏定义位于 hw/arm/virt.cDEFINE_VIRT_MACHINE_AS_LATEST/DEFINE_VIRT_MACHINE从源码结构看virt是 aarch64 上持续演进、承担虚拟化安全职责的主力机型。1.2 非虚拟化用例TCG 纯软件模拟不提供安全保证非虚拟化用例指使用 Tiny Code GeneratorTCG进行的纯软件模拟。原则上TCG 与配套的设备模拟代码应当满足与虚拟化用例相同的安全需求但由于历史原因大量非虚拟化用例代码在编写时并未以这些安全需求为前提。因此影响非虚拟化用例的缺陷目前不被视为安全缺陷。使用非虚拟化用例的用户绝不能依赖 QEMU 提供客户机隔离或任何安全保证——例如在纯 TCG 模拟中运行恶意代码、研究不受信二进制等场景都应默认“无隔离、无防护”前提。二、安全边界范围什么缺陷才算安全漏洞即使缺陷影响的是上述“虚拟化用例”也并非所有场景都纳入安全处理范围。QEMU 官方使用以下指引判定是走完整安全流程含 CVE 分配还是仅作为普通缺陷修复。2.1 assert / abort断言与中止若触发某条代码路径需要客户机内核权限或 root 账户访问那么 QEMU 内的 assert/abort 属于“自损式拒绝服务”不会按安全缺陷处理至多算加固缺陷 hardening bug。反之若可由客户机内的非特权账户触发则可能有理由按安全缺陷处理。2.2 vhost-user / vfio-user 后端后端进程与 QEMU 进程共享同一块内存区域co-mapped。进程分离的初衷是运维弹性与灵活性以及允许独立软件供应商提供后端实现QEMU 与 vhost-user、vfio-user 后端之间不认为存在安全边界。因此后端中能导致 QEMU 崩溃/异常行为的缺陷不会被当作安全缺陷而应作为加固缺陷修复。2.3 内存分配边界Memory allocation boundsQEMU 进程合法消耗的内存有诸多途径可能远超分配的客户机 RAMQEMU 的最坏情况内存用量应视为实际上无上界。因此宿主上的 QEMU 部署必须为内存峰值预留余地并采取反制措施保证宿主操作连续性。典型做法是依赖 Linux OOM killer 在内存过量提交overcommit时回收过度消耗内存的进程提供一定程度的保护。据此会导致过度/无界内存分配的缺陷通常不归类为安全缺陷而按加固缺陷修复。2.4 降级的客户机行为Degraded guest behaviour存在一类缺陷会让客户机的硬件设备行为异常例如虚拟 IOMMU 操作缺陷可能无法提供应有的设备隔离。若利用此类缺陷需要客户机内核权限或 root 账户且结果只是虚拟设备行为次优则视为自损式服务降级不按安全缺陷处理至多加固缺陷若客户机内非特权账户即可触发则可能构成安全缺陷。2.5 嵌套虚拟化Nested virtualization嵌套虚拟化的安全范围是“防止 level 2 客户机逃逸进入 level 1 客户机”。如前所述大量仅可由客户机内核/root 账户利用、且只影响客户机自身服务/可用性的缺陷场景被排除在安全处理之外。在带 PCI 设备直通的嵌套虚拟化场景中level 2 客户机内核可能触发影响 level 0 QEMU 进程的缺陷这类缺陷应当修复但当前不会按安全缺陷分诊。2.6 迁移 / 快照Migration/snapshots只要源虚拟机与 savevm 文件分别仍然可用迁移失败与快照加载失败被视为正常运行的一部分。在迁移/快照目标端中止 QEMU 进程同样不视为安全问题。只要下述“架构”章节所述设计原则成立迁移数据流即被假定为安全仅对数据流的普通篡改不被视作攻击向量。2.7 未初始化栈变量若缺陷场景依赖“未显式初始化栈变量”导致的未定义行为通常不视为安全缺陷。构建系统会加入-ftrivial-auto-var-initzero编译选项受支持的 GCC 与 Clang 均支持确保所有栈变量隐式零初始化消除未定义行为从而消除绝大多数此类缺陷场景。2.8 低严重性影响兜底规则作为兜底规则对系统影响严重度被判定为“低”的问题通常不构成安全缺陷也不分配 CVE将在时间允许时作为常规缺陷修复。三、安全状态报告机制secure 注解与 insecure-types 策略3.1 TypeInfo.secure显式声明安全边界QEMU 项目通过注解类型来显式声明某类型是否提供安全边界。对于 machine、accelerator 与 device 类型只有被标注secure标志的类型才有资格分配 CVE。未来该注解会逐步扩展到其他后端backend与对象object类型使安全状态完全显式化。实现层面TypeInfo结构体在 include/qom/object.h 中新增了bool secure;字段。类型注册时该标志随.secure字段写入类型信息见 qom/object.c 中ti-secure info-secure;并提供查询函数object_class_is_secure()qom/object.c判断某类是否声明安全边界。机器类型的宏体系在 include/hw/core/boards.h 中做了统一封装DEFINE_MACHINE_EXTENDED(namestr, ..., ABSTRACT, SECURE, ...)通过参数传入.secure SECUREDEFINE_MACHINE(...)默认.secure false注释明确写有 “Implicitly insecure”隐式不安全DEFINE_SECURE_MACHINE(...)/DEFINE_SECURE_MACHINE_WITH_INTERFACES(...)硬编码.secure true供受支持的安全机器类型使用。从源码结构可以推断官方文档列出的受支持 machine 类型virt、pc、q35、microvm、s390-ccw-virtio、pseries等正是通过这类带安全标志的宏注册从而获得“eligible for CVE assignment”的资格。3.2 -compat insecure-types控制不安全类型的使用用户或管理工具可以使用-compat参数的insecure-types选项来控制或识别未显式提供安全边界类型的使用。该参数接受三个值取值行为accept允许使用任何类型。这是当前与历史上的默认行为warn使用未显式声明 secure 的类型时输出警告消息但仍允许使用reject使用未显式声明 secure 的类型时输出错误消息且不允许使用兼容性策略在 QEMU启动初期以及运行期通过 monitor 命令所做的任何变更中都会被强制执行。该策略的 QAPI 定义位于 qapi/compat.json枚举CompatPolicySecurityaccept/reject/warn并作为CompatPolicy结构体的可选字段*insecure-types默认accept。从该文件注释看此字段自 QEMU 11.2 起引入。运行时判定逻辑在 qapi/qapi-util.c 的compat_policy_check_security()中实现若类型is_secure为真则直接放行否则根据policy-insecure_types分别执行COMPAT_POLICY_SECURITY_ACCEPT静默放行COMPAT_POLICY_SECURITY_REJECT报错Type %s does not provide a security boundary to protect against untrusted data or actions拒绝使用COMPAT_POLICY_SECURITY_WARN通过warn_report()输出同名警告但继续放行。3.3 运行时查询qom-list-types、query-machines 与命令行 help任何类型类的安全状态都可以在运行时查询qom-list-types命令返回信息中会标记任何被声明为 secure 的类型secure属性实现见 qom/qom-qmp-cmds.c其中对非 secure 类型会省略secure属性、对 secure 类型显式置truequery-machines命令对 machine 类型反映同样的安全信息命令行-machine help、-accel help、-device help分别用于查询 machine 类型、加速器与设备的安全状态。对安全要求严格的部署建议将insecure-typesreject或至少warn纳入启动参数并定期用qom-list-types审计所用类型的secure标注避免无意中使用到不具备隔离保证的模拟设备。四、安全架构两大设计原则与隔离机制本章描述确保上述安全需求得到满足的设计原则。4.1 客户机隔离Guest Isolation客户机隔离指把客户机代码限制在虚拟机内部。当客户机代码在宿主上获得执行控制权时即称为“逃逸出虚拟机”escaping the virtual machine。隔离同时包含资源限制对 CPU、内存、磁盘或网络的节流throttling客户机必须无法突破自身资源限额。QEMU 以“模拟设备”的形式向客户机呈现攻击面。客户机必须无法获得对 QEMU 的控制权——模拟设备中的缺陷可能让恶意客户机在 QEMU 内获得代码执行一旦如此客户机便已逃逸出虚拟机能够在宿主上以 QEMU 进程的上下文行动。此外客户机之间经常互相交互并共享资源。恶意客户机不得获得对其他客户机的控制权也不得访问其他客户机的数据。磁盘镜像文件与网络流量必须受到保护除非用户明确与其他人/进程共享。4.2 最小权限原则Principle of Least Privilege最小权限原则要求每个组件只拥有其功能所必需的权限。就 QEMU 而言即每个进程只拥有属于其客户机的资源。QEMU 进程不应拥有任何“客户机不可访问”的资源——这样客户机即便逃逸进 QEMU 进程也一无所获因为它在客户机内部本就拥有这些资源。遵循最小权限原则可以立即满足客户机隔离需求例如客户机 A 只能访问自己的磁盘镜像a.img而无法访问客户机 B 的b.img。现实中确实存在“客户机不可访问、但 QEMU 必须拥有”的资源例如宿主系统调用QEMU 需要但不会暴露给客户机。一旦客户机逃逸进 QEMU 进程便可开始调用宿主系统调用——这正是隔离机制要压缩的攻击面。新功能必须按最小权限原则设计若因技术原因无法做到必须将安全风险明确写入文档让用户知晓启用该功能的代价。4.3 可用隔离机制总览除 Linux seccomp 由 QEMU 自身提供外以下机制均由启动 QEMU 的管理工具如 libvirt部署且具有平台相关性文档仅针对 Linux 简要描述。基础机制QEMU 进程必须以非特权用户运行。有时为让 QEMU 访问宿主设备如/dev/net/tun而以 root 启动 QEMU 看似方便但这带来巨大安全风险。替代方案有两种文件描述符传递File descriptor passing让本无特权的 QEMU 进程获得宿主设备访问权而无需以 root 运行UNIX 组授权以非 root 用户启动 QEMU并通过配置 UNIX 组授权访问/dev/kvm、/dev/net/tun等设备节点。部分 Linux 发行版已默认内置这些设备的 UNIX 组。其余机制逐一说明SELinux 与 AppArmor超越传统 UNIX 进程与文件权限模型来约束进程限制 QEMU 进程访问宿主上与 QEMU 无关的进程和文件资源限制与 cgroup 控制器对 CPU 时间、内存、I/O 带宽等关键资源提供吞吐与利用率上限Linux namespaces让进程、文件系统及其他系统资源对 QEMU 不可见。处于命名空间中的 QEMU 进程只能访问被授予的资源Linux seccomp通过 QEMU 的--sandbox选项启用禁用 QEMU 不需要的系统调用从而缩减宿主内核攻击面传输层安全TLS在网络不可信时为在线迁移连接提供真实性与加密。-sandbox的完整参数在 qemu-options.hx 中有详细定义Seccomp mode 2 系统调用过滤器默认off-sandbox on[,obsoleteallow|deny][,elevateprivilegesallow|deny|children] [,spawnallow|deny][,resourcecontrolallow|deny]各子参数含义obsolete是否允许内核提供、但现代 C 库通常已不再使用的过时系统调用elevateprivileges是否允许 QEMU 进程通过set*uid|gid系统调用提权值children表示对主 QEMU 进程禁用set*uid|gid但允许其 fork/exec 出的子进程以非特权方式运行spawn通过阻断*fork与execve避免 QEMU 派生出新线程或新进程resourcecontrol禁用进程亲和性affinity与调度优先级设置。五、敏感配置监控控制台QMP 与 HMP的安全处置QEMU 存在若干具有安全影响的方面用户与管理应用必须知晓。5.1 控制台即特权接口监控控制台无论使用 QMP 还是 HMP提供对 QEMU 大量运行时行为的动态控制接口。其中许多命令会指示 QEMU 访问宿主文件系统内容或触发外部进程的派生。文档给出两个典型示例migrate命令允许为隧道化迁移数据流而派生任意进程blockdev-add命令指示 QEMU 打开任意文件将其内容作为虚拟磁盘暴露给客户机。因此除非 QEMU 已通过 SELinux、AppArmor 或 Linux namespaces 等技术加以约束否则监控控制台应被视为拥有与 QEMU 运行账户同等的权限。5.2 字符设备后端的选择监控控制台所依托的字符设备后端的自身安全性同样关键它必须能够抵御恶意第三方发起未授权连接或中间人攻击。许多字符设备后端并不满足这一要求因此不得用于监控控制台。官方建议明确监控控制台应仅通过 UNIX domain socket 后端暴露给本地宿主。除非同时配置 TLS 加密与客户端连接授权控制策略否则使用基于 TCP 的字符设备后端是不恰当的。5.3 总结监控控制台是 QEMU 的特权控制接口只应开放给可信的管理应用或用户访问。任何将其暴露到不可信网络、或通过不加密通道开放的做法都会显著放大宿主被攻破的风险。六、安全部署检查清单综合以上文档与源码要点面向生产环境的安全部署可遵循以下清单用例确认确认自身属于“虚拟化用例”KVM/HVF 加速器 受支持 machine 类型否则不应期待任何安全保证machine 类型只选用文档列出的受支持类型aarch64virt、x86_64pc/q35/microvm等可通过-machine help与query-machines核对secure标注安全策略落地评估后启用-compat insecure-typesreject或warn并用qom-list-types审计留意该策略在启动期与 monitor 变更期均生效最小权限以非特权用户运行 QEMU用 FD 传递或 UNIX 组/dev/kvm、/dev/net/tun授权设备访问避免 root 运行多层加固按需叠加 SELinux/AppArmor 策略、cgroup 与资源限制、Linux namespaces、-sandbox onseccomp 过滤合理配置obsolete、elevateprivileges、spawn、resourcecontrol子项控制台收敛监控控制台仅通过本地 UNIX socket 暴露给可信管理端确需远程时启用 TLS 加密并配置授权策略迁移安全在不信任的网络中为 live migration 配置 TLS确保迁移流真实性、机密性与完整性预期管理对 vhost-user/vfio-user 后端、内存峰值、客户机内核可触发的 assert 等“边界外”缺陷有合理预期将其视为加固缺陷而非依赖其获得安全承诺。上述安全需求的权威定义与边界判定规则均以 docs/system/security.rst 为准实现细节可进一步查阅 qapi/compat.json、qapi/qapi-util.c、include/qom/object.h、include/hw/core/boards.h 与 qemu-options.hx 对应章节。【免费下载链接】qemuOfficial QEMU mirror. Please see https://www.qemu.org/contribute/ for how to submit changes to QEMU. Pull Requests are disabled. Please only use release tarballs from the QEMU website.项目地址: https://gitcode.com/gh_mirrors/qe/qemu创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
