在Linux 安全马戏团：关于 GUI 隔离 - The Invisible Things Lab 的博客中，Joanna Rutkowska 描述了来自一个 X11 应用程序对另一个应用程序的攻击以及缺乏 GUI 级隔离的一般问题，以及它如何从本质上消除所有桌面安全性。
一个应用程序可以嗅探或向另一个应用程序注入击键，可以对属于另一个应用程序的窗口所占用的屏幕进行快照，等等。
关于 X11 安全模型如何随时间发生变化并且不适合 Linux 的一点很有趣。她将Qubes OS (Beta 1)推销为一种安全的替代方案。
我的问题：
可以避免主动攻击（注入击键）吗？我似乎记得很久以前默认情况下关闭了主动攻击。但是一个快速的谷歌建议 XTest 扩展无效（如何将组合键映射到键盘按钮？）。
大多数 Linux 发行版正在迁移到Wayland作为 X11 的替代品。它是否提供了应用程序之间的良好隔离？
桌面安全有希望吗？:)
基本上，任何可以成功连接到 X11 服务器的进程都可以完全访问该服务器上发生的事情。X11 安全模型假定攻击者在连接时被拒绝。通常的安全系统是客户端必须发送一个特定的“magic cookie”作为其第一条消息的一部分，该 cookie 是一个随机 blob，它在服务器启动时或作为登录过程的一部分创建；cookie 也被复制到只有“允许”应用程序才能访问的位置。在类 Unix 系统上，cookie 传统上在$HOME/.Xauthority文件中，但可能在其他地方（在我最近的 Linux 系统上，它似乎在 的子目录中的某个地方/var/run/gdm/），关键是该文件仅对单个文件可读Unix 用户。转发 X11 连接时，SSH 使用xauth 命令将当前 cookie 从客户端透明地传输到服务器（以便在远程主机上启动的应用程序可以在它们连接回来时发送 cookie）。
因此，X11 存在隔离——但它是在用户之间（由操作系统控制），而不是在代表同一用户执行的应用程序之间。
在过去，魔术 cookie 并不常见，因此一些应用程序（尤其是 xterm）包括诸如拒绝合成事件（即来自XSendEvent()调用的事件，而不是来自硬件的事件）等对策。这些措施是在多年来在 X11 协议上发展的许多扩展之前出现的，例如 XTest，这使得它们大多过时且无用。
Qubes是一个基于 Xen 构建的操作系统，用于将一些应用程序相互隔离——每个 VM 都有自己的专有显示，与其他 VM 的 X11 服务器没有可能的交互。我在同一个句子中阅读“Beta 1”和“安全”时遇到了麻烦，虽然......
对于 X11 部分，与 Xnest 相同的隔离已经存在了很多年（更新后的继任者称为Xephyr）：您在特定的、隔离的用户 ID 下运行潜在邪恶的应用程序，并让它只连接到 Xephyr 实例，该实例它本身连接到主 X11 服务器，就好像它是一个简单的应用程序一样。为了逃避这种隔离，应用程序应该劫持 Xephyr（例如通过缓冲区溢出）。Qubes 解决方案更彻底，因为它用更大的 VM 层取代了 Unix 基本隔离（“不同的用户 ID”）。
Wayland 似乎没有宣传任何关于隔离的内容，因此可以肯定的是，它在这方面没有做任何事情。此外，Wayland 在可能的情况下尝试为应用程序提供几乎直接的硬件访问权限，因此在这种情况下，任何安全模型都将与未记录的 3D 硬件和闭源驱动程序如何协作以避免错位 DMA 传输以获得额外权限有关——这看起来不是建立安全性的最佳方式。