Linux 系统上本地 lxd 组的成员有多种途径将其权限提升至 root。本仓库包含全自动本地 root 利用示例。漏洞的详细解释及利用演练可在我的博客 此处 找到。
以下利用并非容器逃逸，而是 利用 容器并 针对 宿主操作系统的本地 root 利用。成功利用需要宿主环境的低权限访问。
我相信我在第二个版本中的策略是独特的，并且足够有趣（至少对我来说）以至于在以上链接的博客中写了详细解释。
lxd_rootv1.sh 将宿主机的 / 文件系统挂载到容器中，在容器内宿主机的低权限用户具有 root 访问权限。此 root 访问权限映射回宿主机，允许将当前用户添加到 /etc/sudoers 文件中。此方法在我之前已被其他人利用。lxd_rootv2.py 将宿主机的 systemd 私有 UNIX 套接字挂载到容器中，然后通过 LXD 代理设备再次挂载回宿主机。这些代理设备具有 root 权限，并且在套接字通信期间传递 它们自己的 凭据，而不是发起通信的低权限用户的凭据。这被滥用来创建一个临时的 systemd 服务，将当前用户添加到 /etc/sudoers 文件中。两种利用都需要一个容器，因此请先创建一个。然后，从宿主操作系统运行利用，将容器名称作为第一个参数。
# Exploit with v1
$ bash lxd_rootv1.sh <container name>
# Exploit with v2
$ python3 lxd_rootv2.py <container name>
在我遇到这些问题之前，官方 LXD 文档中没有任何内容警告用户 lxd 组是危险的。任何按照官方指南配置 LXD 的人都会在部署第一个容器之前将其帐户添加到该组中。我向 Canonical 提交了一个 bug 来表达我的担忧——你可以查看完整讨论 这里。LXD 团队迅速对文档进行了调整，现在明确说明该组只应授予受信任的 root 用户。
一如既往，通过他们的 bug 追踪系统与 Canonical 团队打交道是一次非常愉快的经历。我要感谢他们的时间以及对我提出的想法给予的深思熟虑。我强烈建议其他安全研究人员也以这种方式直接向他们提交问题。
我并非第一个利用 LXD 的人。这个问题早在 2016 年就已在多个 GitHub issue 中被提出：
据我所知，第一个链接中的 (simpoir) 是第一个识别出此风险的人。
@reboare 在很久以前就写了一篇不错的博客，使用与我 v1 利用相同的方法来利用 LXD：
感谢 LXD 团队制作了一个非常酷的工具。我个人使用 LXD 并且非常喜欢它。我认为这并不会成为使用 LXD 的障碍，但重要的是要理解将用户添加到 lxd 组时的潜在风险。
这两种漏洞都没有官方修复方案。任何使用 LXD 的人都应意识到，将用户添加到 lxd 组基本上就是将他们变成 root。
如果你在单用户主机（如桌面）上使用 LXD，最好完全不要使用 lxd 组，而是在需要与 API 通信时运行 sudo。
对于多人共同使用容器的共享环境，最好创建嵌套环境。LXD 组的每个用户都能够利用自己的环境，但随后需要更努力地突破该容器以利用其他用户的环境。