监禁 Xorg 应用程序的目的是防止其访问@/tmp/X11/X0和/tmp/X11/X0然后重新使用它的麻省理工学院魔术饼干从连接到 X 服务器的其他应用程序中窃取。
该 cookie 用于在应用程序第一次连接时获取 Xorg 的文件句柄/套接字抽象。如果邪恶的黑客对应用程序进行段错误并启动 shell，他将无法访问此文件句柄/套接字抽象，因此需要来自 的原始 MIT-MAGIC-COOKIE.X权威并且他需要访问 /tmp/X11/X0 文件/abstract-socket 来创建新的 Xorg 上下文。
firejail 和 Linux 命名空间背后的想法是向他隐藏这些资源并阻止他创建新的 Xorg 上下文。
为此，firejail 依赖于 Linux 命名空间，并将应用程序移动到不存在 /tmp/* 的新命名空间中。它还为应用程序提供了一个新的桥接口，使用--网络=因此，应用程序无法看到 .Xauthority 文件，并且无法与 Xorg 进行通信。因为应用程序通过桥接口进行通信，所以它可以看到互联网/假设允许，但它的视图将受到 br0 等上的防火墙的限制
应用程序本身使用其 Xorg 套接字指针与使用共享内存的 Xorg 进行通信，只要它保留该指针，就可以无限期地这样做。
那么 firejail 安全性依赖于应用程序从内存中完全崩溃并丢失它的 Xorg CONTEXT/指针吗？ 但是黑客可以通过段错误进入应用程序并重写其代码并仍然保留 Xorg 上下文吗？但这是我们必须承担的风险——也许可以通过以下方式避免：Apparmor/SELinux和监控系统调用？
但是我们为什么不使用命名管道反而？创建一个命名管道/.Xauthority 并出口权限并启动应用程序 - 它会阻塞，因此在服务器端，运行一些写入当前 cookie 的程序，并在应用程序启动后更改它。因此，如果应用程序出现段错误，黑客只是普通用户或没有 cookie 的限制：黑客根本没有希望窃取新的 cookie，特别是如果您清除/删除用户/删除他的所有文件并启动重新运行每个应用程序。
firejail 的做法与此有何不同？如果他需要启动应用程序，他必须提供 .Xauthority 和套接字文件.. 那么他会做什么 - 他是否将应用程序移动到新的 NS - 他如何知道何时移动？许多应用程序会多次轮询 .Xauthority，那么 firejail 如何知道何时隐藏这些资源以及它到底如何隐藏这些资源呢？
答案1
监禁 Xorg 应用程序的目的是防止其访问 @/tmp/X11/X0 和 /tmp/X11/X0，然后重新使用其 MIT-MAGIC-COOKIE 来窃取连接到 X 服务器的其他应用程序
不？如果你读过例如本指南,
沙箱用 Xpra 或 Xephyr 服务器取代了常规的 X11 服务器。这可以防止 X11 键盘记录器和屏幕截图实用程序访问主 X11 服务器。
因此，监禁 X 应用程序的目的是完全阻止它访问主服务器，而是让它访问代理服务器。即使应用程序尝试使用代理服务器，也不会影响主服务器。
我不确定你所描述的具体场景是什么，但是任何能够以某种方式访问主服务器的 X 应用程序，即使使用 MIT cookie 的初始授权不是由应用程序本身完成的，也可以在此服务器上执行一些技巧，例如按键记录或访问其他窗口。它不必崩溃才能做到这一点。因此，对应用程序进行初始授权然后阻止其重新授权没有任何帮助。
您是否可能错过了以特定方式启动被监禁应用程序的要点是使其访问代理 X 服务器？
编辑
我只是想了解 firejail 与传统 xauth/.Xauthority 的做法有何不同，以确保被监禁的应用程序的安全。
Firejail 向应用程序显示 X 服务器代理，并阻止应用程序访问主 X 服务器。就这样。传统的 xauth 机制完全相同，无论是应用程序与 X 代理之间，还是 X 代理与主 X 服务器之间。 （是的，当然X代理需要访问主服务器，或者，需要有一个程序可以同时访问主X服务器和X代理。但这些程序是值得信赖的，与应用程序不同）。
然后依赖命名空间并防止 cookie 被泄露......并作为隐藏 Xorg 套接字的附加措施。
不。命名空间的目的是使主要的 X 服务器通信端点不可访问。就像“它们不存在”一样。它并不是真正“隐藏”任何东西（“它在那里，但你看不到它”）。就被监禁的应用程序而言，它已经不存在了。同样，Docker 容器使用命名空间来让容器中的应用程序假装它们在完全不同的环境中运行。
不让被监禁的应用程序看到主 X 服务器通信端点就已经足够了，但是当然，被监禁的应用程序没有理由看到主 X 服务器的有效 MIT cookie。
命名管道确实与此无关。也没有崩溃。 X 身份验证机制的工作方式也没有变化。
答案2
所以我给 Xorg 邮件列表发了电子邮件，他们非常有帮助，所以这就是一切的运作方式。
Xorg -nolisten tcp -nolisten inet -nolisten inet6 -listen unix -nolisten local :0 -seat Seat0 vt7 -novtswitch 是用于关闭侦听的命令，UNIX 域套接字除外（从 debian 中摘取）。
这将导致/tmp/X11/X0 和 @/tmp/X11/X0 抽象套接字正在被创建。
Xorg 通过此管道/套接字接收 cookie（由程序使用Gtk/Qt-->Xlib[.Xauthority]）并将其与 XDM 提供给它的内部 cookie 进行比较。如果它们匹配，Xorg 将创建其内部上下文，并将该上下文与 IP:Port [对于 tcp/ip 连接] 或应用程序 FD [对于套接字][命名管道套接字/FD 创建] 相关联1。
基本上，每个写入 /tmp/X11/X0 的应用程序都会导致 Xorg 在其末尾创建一个唯一的 FD。如果应用程序死亡并退出，则该 FD 会被 Xorg 关闭，但如果应用程序被注入，则该 Xorg FD/上下文不会被破坏，并且病毒/邪恶应用程序可以欺骗该应用程序并继续与 Xorg 通信。如果应用程序使用网络/tcp，那么这会更容易，因为 Xorg 在 XOpenDisplay/MIT-COOKIE 之后仅使用 IP:Port 进行身份验证 [cookie 仅用于对 Xorg 的一个 API 调用]。
如果应用程序愿意，它可以将 COOKIE 保留在内存中，从而允许黑客窃取 COOKIE，但此身份验证位是 Xlib 的工作。 Firejail 并不能真正防止 cookie 被盗。它的作用是使用 Xvfb 渲染应用程序 GUI，然后使用 Xpra 将像素图发送到 Xorg 服务器，该服务器分为两部分 - 客户端 Xpra 和服务器 Xpra（Xpra 文档/自述文件解释了这一点）。因为服务器只能看到像素图，而不会看到来自受信任代理/Xpra 服务器/客户端/任何受 Burqa 保护的 API 调用，因此是安全的。然而，强奸犯仍然四处逃窜，因为 Xorg 软弱可悲，没有任何安全保障:p
它是用很多胶带将它们固定在一起，而且不是很整洁和高效——尽管我认为这是很有争议的。除了一次性 cookie 验证之外，Xorg 的安全性为 0 - 它是为不同时代设计的，所以..到目前为止我还没有任何东西可以工作。我怀疑编写一个 bash 脚本来执行 cgroup/resource-limit 和命名空间会更容易，而不是使用 firejail，它使用各种阴暗的黑客技术，并且出于某种原因使用 C 语言。至于 Xorg.. 我需要读取 Xvfb 并尝试通过监狱提取/发送数据到 Xorg。