他们最近发布的消息是 发现漏洞 （已在 CVE-2022-31214 下列出） 在 Firejail 应用程序沙盒工具中，详细说明检测到的漏洞可能允许本地用户成为主机系统上的 root。
Firejail 在 Linux 中使用命名空间机制、AppArmor 和系统调用过滤 (seccomp-bpf) 进行隔离，但需要提升权限来配置隔离版本，它通过绑定到 suid 根标志实用程序或使用 sudo 运行来获得。
该漏洞是由于“--join=”选项的逻辑错误造成的», 旨在连接到已经运行的隔离环境（类似于沙盒环境的登录命令），环境由其中运行的进程的 ID 定义。 在预启动阶段，firejail 会检测指定进程的权限并将其应用于使用“--join”选项加入环境的新进程。
连接前， 检查指定进程是否在 firejail 环境中运行。 此检查评估 /run/firejail/mnt/join 文件的存在。 要利用该漏洞， 攻击者可以模拟一个虚构的非隔离火狱环境 使用挂载命名空间，然后使用“--join”选项连接到它。
如果配置没有开启禁止在新进程中获取额外权限的模式（prctl NO_NEW_PRIVS），firejail会将用户连接到一个虚构的环境，并尝试应用init进程的用户标识符（namespace user）的用户命名空间配置（ PID 1)。
join 函数背后的大部分逻辑都在源代码中 来自 `src/firejail/join.c` 文件。 代码的关键部分执行 提升的特权（有效的 UID 0）。 作为命令传递的进程 ID 检查 line 参数以确定它是否是 r容器并确定它的一些属性 它也适用于新的进入过程。
决定是否加入目标进程的主要标准 成功是目标的挂载命名空间中存在文件， 在 /run/firejail/mnt/join 中找到的进程。 此验证是在 f 上完成的`is_ready_for_join()` 函数。 使用 l 打开文件`O_RDONLY|O_CLOEXEC` 标志和跟踪 `fstat()` 结果应该 满足以下要求：
– 文件必须是普通文件。
– 该文件必须由用户 ID 0 拥有（从初始用户可见
命名空间）。
– 文件大小必须为 1 字节。
结果是， 通过“firejail --join”连接的进程将在命名空间中结束 用户的原始用户 ID 特权不变， 但在不同的挂载点空间，完全由攻击者控制。
生成的“加入”外壳现在将存在于初始用户
命名空间，仍然保留原来的普通用户权限，但是 挂载命名空间将是由攻击者控制的命名空间。 作为
没有应用 nonewprivs 配置，攻击者现在可以
在这个挂载命名空间中运行 setuid-root 程序
特别是，攻击者可以在它创建的挂载点的空间中运行 setuid-root 程序，例如，允许它在其文件层次结构中更改 /etc/sudoers 配置或 PAM 参数，并获得以 root 身份运行命令的能力使用 sudo 或其实用程序。
最后，值得一提的是，已经开发了一个功能性漏洞利用程序，并在安装了 firejail 实用程序的当前版本的 openSUSE、Debian、Arch、Gentoo 和 Fedora 上进行了测试。
该问题已在 firejail 版本 0.9.70 中得到修复。 作为安全修复，您可以将配置（/etc/firejail/firejail.config）设置为“no join”和“force-nonewprivs yes”。
最后 如果您有兴趣了解更多有关它的信息，您可以在中查看详细信息 以下链接。