内核授权文件操作范围在小牛队中已损坏

Kernel Authorization File Operation Scope broken in Mavericks

本文关键字：已损坏 授权 文件 操作 范围 内核      更新时间：2023-10-16

我开发了一个系统，需要使用 kext 监控文件，它注册到文件操作范围 （KAUTH_SCOPE_FILEOP）。在OSX 10.8及更早版本中，一切都按预期工作，程序的执行将提供开始执行的程序所需的pid，ppid和文件名。

在虚拟节点范围内，我按照"Mac OS X Internals"一书中的建议在回调中检索 pid，如下所示： -

data.pid = vfs_context_pid((vfs_context_t)arg0);

对于我使用的文件范围：-

proc_t self = proc_self();
data.pid = proc_pid(self);
proc_rele(self);

我在 Mavericks 中看到的问题发生在应用程序通过 xpc 生成帮助程序应用程序时。例如，安装软件包 （.pkg） 会启动 Apple 的安装程序，该安装程序使用关联的"运行器"帮助程序应用程序。

当 filescope 报告执行"runner"时，文件路径是正确的，但报告的 pid 和 ppid 是父应用程序安装程序的 pid 和 ppid，而不是帮助程序应用程序的 pid 和 ppid。

测试时，注册到 VNode 范围 （KAUTH_SCOPE_VNODE） 会报告正确的 pid 和 ppid。

如Apple文档中所述，文件操作范围可用于实施防病毒扫描程序。

在这种情况下，如果将帮助程序应用的 pid 和 ppid 报告为其父应用的 pid 和 ppid，则可能无法检测到帮助程序应用。

有人可以告诉我在 Mavericks 中注册文件操作范围时如何检索帮助程序应用程序的正确 pid 和 ppid 吗？

问题是由于Apple正在用posix_spawn替换对fork/exec的调用。

posix_spawn的性质意味着在创建实际进程之前通知文件范围，这是看到父 pid 而不是子 pid 的原因。

KAuth 和文件范围早于 posix 生成，这就是它在这种情况下无效的原因。

解决方案是改用 VNode 作用域。

相关文章：