使用 LXC 增强 X11 应用程序安全性

# 用 LXC 增强 X11 应用安全性 · dobrowolski.dev 来源：https://dobrowolski.dev/article/enhancing-x11-application-security-with-lxc 2025-12-05 如果能为网页浏览器或基于 Electron 的即时通讯应用增加一层额外的安全性，那该多好啊？毕竟，一旦浏览器被攻破，用户的整个主目录都可能面临风险。 让我们通过使用 LXC 将应用与主机系统隔离来缓解这个问题。 本文使用的系统是 Arch Linux，但操作步骤应该很容易适配到其他发行版。 --- ## 网络功能 首先，我们需要安装并预配置 LXC。安装以下软件包： `` # pacman -S lxc lxcfs `` 接下来，我们需要让 LXC 容器具备网络功能。为此，编辑 `/etc/default/lxc` 文件，并在末尾追加以下一行： 现在我们可以启动 LXC 桥接接口。启用并启动对应的 systemd 单元： `` # systemctl enable lxc-net.service --now `` 现在应该会出现一个名为 `lxcbr0` 的新接口。用以下命令验证： `` # ip a show dev lxcbr0 `` --- ## 创建容器 完成上述步骤后，我们就可以创建第一个应用容器了。先从创建初始配置开始。 导航到 `/etc/lxc` 并创建一个新的配置文件。因为我正在创建一个浏览器容器，所以将其命名为 `www.conf`。 使用你喜欢的编辑器打开该文件，并添加以下行： `` lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up lxc.net.0.hwaddr = 10:66:6a:xx:xx:xx lxc.idmap = u 0 100000 65536 lxc.idmap = g 0 100000 65536 `` 前四行指定容器应使用我们之前创建的网络桥接。 接下来，我们定义容器的 UID 和 GID 如何映射到主机上的 UID 和 GID。由于我们的目标是最大安全性，我们将使用非特权容器。为此，我们将容器的 ID 映射到主机上不存在的 ID 范围内。这确保即使恶意进程逃逸出容器，它在主机系统上也不会有任何有意义的权限。 ### 理解 `idmap` 以下是 idmap 配置工作原理的详细说明： `` lxc.idmap = [类型] [容器 ID] [主机 ID] [范围] `` - [类型] – 指定要映射的 ID 类型。选项： - u 用于 UID - g 用于 GID - [容器 ID] – 容器内要映射的第一个 UID/GID。在我们的例子中是 0（容器的 root）。 - [主机 ID] – 容器 ID 映射到的主机起始 UID/GID。在这里，容器内的 0 映射到主机上的 100000。ID 按顺序递增： - 容器 ID=1 → 主机 ID=100001 - 容器 ID=1000 → 主机 ID=101000 - [范围] – 要映射的 UID/GID 块大小。我们使用 65536 来提供完整的标准 Linux ID 范围。 示例映射表： `` | container_id | host_id | | ------------------ | ----------- | | 0 | 100000 | | 1 | 100001 | | 1000 | 101000 | | 65535 | 165535 | `` 接下来，我们需要告诉 LXC 在新容器中使用哪些 UID/GID 映射。我们通过在 `/etc/subuid` 和 `/etc/subgid` 文件中添加以下行来实现： 这一行表示主机用户 root 可以创建用于 LXC 容器的 UID 映射，范围是 100000–165535。这直接对应于我们之前创建的非特权容器配置。 如果你想创建另一个具有不同映射的容器，例如将 container_id=0 映射到 host_id=200000，只需在 subuid/subgid 文件中添加另一行： `` root:100000:65536 root:200000:65536 `` ### 启动容器 现在我们终于可以开始使用我们准备好的配置文件创建容器了。在这个例子中，我将使用 debian:trixie 镜像作为基础： `` # lxc-create --config /etc/lxc/www.conf --name www -t download --- \ -d debian -r trixie -a amd64 `` 验证容器是否正在运行： `` # lxc-ls -f `` 设置完成后，登录到容器： `` # lxc-attach www /bin/bash `` 在容器内部，你可以像在常规 Linux 系统上一样安装所需的软件。例如，要运行 Firefox： `` # apt update # apt-get -y install firefox-esr `` 许多 x11 应用程序在 root 用户下运行不佳，因此最好创建一个专用用户来在容器内运行应用程序： `` # /sbin/useradd -m -s /bin/bash www `` ## 设置 X11 基本容器配置已完成，让我们直接进入配置以托管 x11 应用程序。首先，我们必须映射 x11 套接字。如果你当前正在运行 X 服务器，你会在 `/tmp/.X11-unix` 下找到它。 我们还需要给容器提供一个 `.Xauthority` 文件，以便它可以向 X 服务器进行授权。简单地挂载主机的文件是行不通的：每个 cookie 条目都由主机名键控，客户端只使用与其运行机器的主机名匹配的条目——在容器内部，主机名是不匹配的。解决方法是将条目的 family 字段替换为 `FamilyWild` 通配符 (`ffff`)，使其匹配任何主机，然后将其合并到容器的一个新的 `.Xauthority` 文件中： `` : > /tmp/lxc.Xauthority && xauth nlist :0 | \ sed 's/^..../ffff/' | xauth -f /tmp/lxc.Xauthority nmerge - # 将 :0 替换为你的 $DISPLAY 值 `` 最后，我们必须确保设置了以下环境变量： - DISPLAY – 将其设置为主机的 DISPLAY 值 - XAUTHORITY – 将其设置为 `lxc.Xauthority` 文件在容器内挂载的路径 为了实现这些步骤，让我们编辑容器的配置文件并添加以下行。注意，这是 `lxc-create` 在 `/var/lib/lxc/www/config` 下生成的每个容器的配置，这与我们在创建时传递的 `/etc/lxc/www.conf` 模板不同： `` lxc.environment = XAUTHORITY=/tmp/lxc.Xauthority lxc.environment = DISPLAY=:0 lxc.mount.entry = /tmp/.X11-unix tmp/.X11-unix none bind,optional,create=dir,ro lxc.mount.entry = /tmp/lxc.Xauthority tmp/lxc.Xauthority none bind,optional,create=file,ro `` 最后一个细节：由于我们构建的是非特权容器，其 ID 被我们的 idmap 偏移了（容器 UID 0 映射到主机 UID 100000）。然而，`.Xauthority` 文件是由 `xauth` 以模式 0600 创建的，并且属于你的主机用户，其 UID 不在映射范围内。因此，在容器内部，该文件显示为属于 `nobody`，我们的容器用户无法读取它——所以 X 仍然会以 `Authorization required` 拒绝连接。 最简单的解决方法是在主机上将 cookie 文件设为全局可读： `` chmod 644 /tmp/lxc.Xauthority `` 如果你希望保持 0600 权限，可以将其 `chown` 到容器用户映射到的主机 UID（对于容器 UID 1000 的 `www` 用户，即主机 UID 101000）。 如果一切顺利，你现在应该能够运行我们之前安装的浏览器，并看到其窗口显示在主机的桌面上： `` # lxc-start www # lxc-attach www -- su www -c firefox `` 可选地，如果你希望容器内拥有硬件加速渲染和视频解码功能，可以通过挂载 `/dev/dri` 来透传 GPU： `` lxc.mount.entry = /dev/dri dev/dri none bind,optional,create=dir `` ## 设置声音 音频遵循与显示相同的模式。PipeWire 提供了一个兼容 PulseAudio 的服务器，因此我们可以在主机上暴露一个 PulseAudio 套接字，并将其 bind-mount 到容器中，就像我们对 x11 套接字所做的那样。 首先，在容器内安装音频包，以便应用程序可以使用该套接字： `` # apt-get -y install pulseaudio pipewire-pulse `` 接下来，通过将 `server.address` 添加到 `~/.config/pipewire/pipewire-pulse.conf` 中，告诉 PipeWire 打开一个专用的 PulseAudio 套接字： `` pulse.properties = { # ... 保留现有默认值 ... server.address = [ "unix:native" "unix:/tmp/pulse-socket-0" ] } `` 重新加载 PulseAudio 服务器，以便套接字出现： `` systemctl --user restart pipewire-pulse `` 现在应该会存在 `/tmp/pulse-socket-0`。接下来，将其挂载到容器中，并将 `PULSE_SERVER` 指向它。将以下内容添加到容器配置中： `` lxc.environment = PULSE_SERVER=unix:/tmp/pulse-socket-0 lxc.mount.entry = /tmp/pulse-socket-0 tmp/pulse-socket-0 none bind,optional,create=file,ro `` 与 cookie 文件不同，该套接字是全局可访问的，因此之前非特权容器的所有权问题在这里不适用——无需执行 `chmod`。重新启动容器，它应该就能正常播放音频了。 --- ## 结论 我们现在拥有一个在非特权 LXC 容器内运行的 GUI 应用程序，其显示和声音从主机转发。如果浏览器被攻破，影响范围仅限于一个容器，其 UID 映射到主机上未使用的范围——你的主目录和系统的其余部分都遥不可及。 然而，隔离并非没有代价，也并非绝对。我们打开的每一个通道——X 套接字、PulseAudio 套接字，以及可选的 GPU——都是墙上的一个洞，每个通道都会扩大被攻破进程能够触及的范围。例如，音频套接字既允许播放也允许捕获。仅转发应用程序实际需要的部分，其余部分不要转发；这种权衡正是整个练习的目的所在。 同样的设置也适用于任何不受信任的 GUI 应用程序，而不仅仅是浏览器。你可以通过 seccomp 或 AppArmor 配置文件进一步加强安全性，但即便如此，被攻破的应用程序现在被限制在容器内，而不是直接置于你的主目录之上。