“安全键盘输入”映射到此处EnableSecureEventInput描述其概念的功能。基本上，应用程序本身并不访问硬件。他们从操作系统获取事件（例如关于击键）。操作系统中的某些元素根据其访问权限和 GUI 状态来决定哪个应用程序获得什么事件（根据哪个应用程序“在前台”有详细信息）。

应用程序可以相互“监视”，这意味着（在这种情况下）机器上运行的应用程序可以要求操作系统向其发送所有击键的副本，即使它们是用于另一个应用程序的，和/或注入自己的合成事件。这是一个功能：它允许诸如“密码钱包”（从应用程序的角度输入密码，就像用户输入密码一样）或“键盘查看器”（基于 GUI 的键盘，允许您可以用鼠标“键入”字符，还可以随时显示实际按下的键）。EnableSecureEventInput为调用它的应用程序阻止此功能。试试看 ！运行 Terminal.app，启用“键盘查看器”，并看到启用“安全键盘输入”

所有这些事件路由都是在一些用户空间进程中完成的，该进程以root. 这依赖于内核强制执行的进程分离：普通用户进程不能随意摆弄为根进程分配的内存。内核本身不知道“事件”的用户级概念。事件的管理，特别是 的执行（或不执行）EnableSecureEventInput是由非内核代码进行的。

上面链接的页面的一个有趣摘录如下：

的原始实现EnableSecureEventInput是这样的，当进程启用安全输入输入并具有键盘焦点时，键盘事件不会传递给拦截进程。但是，如果将安全输入进程移到后台，系统将继续将键盘事件传递给这些拦截进程，因为键盘焦点不再是安全输入进程。

最近，发现了一个安全漏洞，即使在启用了安全事件输入并且安全事件输入进程在后台的情况下，拦截进程也可以捕获键盘事件。此问题的解决方法是在任何进程启用安全事件输入时停止将键盘事件传递给任何拦截进程，无论该进程是在前台还是后台。这意味着启用安全事件输入并在程序期间保持启用安全事件输入的进程可能会影响所有键盘拦截进程，即使安全事件进程已移至后台也是如此。

这意味着事件路由系统实际上在该功能的第一部分中出错了。现在应该解决这个问题。

即使假设事件路由现在是正确且安全的，这意味着EnableSecureEventInput' 的语义确实得到了强制执行，那么您必须了解这完全与进程分离系统相关。任何根进程都可以随意检查和修改所有其他进程的内存，特别是查看所有事件；根进程也可以挂接到内核，并完全绕过事件的概念检查来自键盘的实际数据。可以以 root 身份安装的键盘记录器就可以做到这一点，而“安全键盘输入”将毫无防备。有关开源概念证明，请参阅此内容。

因此，“安全键盘输入”仅对可以在机器上运行自己的某些代码但无法将其本地权限提升到 root 级别的攻击者是安全的。这是一个相当严格的场景，因为本地特权升级通常是可能的：

• 本地进程可以看到很多机器，因此在这种情况下要防御的“安全边界”是巨大的。防止远程攻击者的入侵要容易得多，但已经相当困难了。

• 在本地特权升级漏洞的情况下，Apple 往往表现出一些缺乏反应性。

总结：我认为“安全键盘输入”可以提供足够的安全性来抵御公共共享计算机上的键盘记录器，我会觉得过于乐观。这不是一个坏特性，但只有在 root 和内核没有恶意更改的情况下，它才会兑现它的承诺，这是一个非常大的“如果”。

还有一些值得牢记的东西——而且，在我看来，它并没有得到广泛的认可：在 POSIX 系统上，任何终端都有自己的“电传打字机”设备。无论您是否启用“安全键盘输入”，您运行的每个进程都可以从该设备读取。（Linus Åkesson 总结了 Unix 系统如何处理终端设备。）

此类设备的名称和权限因系统而异。从 10.14 版开始，macOS 为它们命名tty[p-w][0-f]{1,3}并授予运行终端的用户读/写访问权限（以及对tty组成员的只写访问权限）。

您可以自己尝试通过在iTerm.app中激活“安全键盘输入” ，调用tty以查看它正在使用的终端设备，然后打开，例如Terminal.app并使用从该设备读取cat。您会发现iTerm.app接收一些字符，而Terminal.app接收其他字符。