实现 macOS 内核监控的几种方法
作者：keenjoy95
随着 macOS / iOS 普及程度的提高，mac 平台的内核监控与攻防也渐渐地成为了热门话题。
笔者近期实践了一些可行的监控方案，这些方案将有助于构建完整的内核监控系统。
Kernel Authorization
首先值得关注的是 KAuth 机制，该机制于 12 年前引入 Mac OS X 10.4 Tiger 内核。这一可以称得上是简陋的回调接口由苹果官方认可，我们可以在开发者中心找到详细的示例代码和文档 [1]。
实践后可发现 KAuth 机制很容易上手，但天花板也随之而来。正如 Jonathan Levin 在《*OS Internals Volume III》[2] 一书中总结的那样，作为 KPI (Kernel Programming Interface) 的 KAuth 机制缺乏细粒度的监控能力，基于它去设计安防软件一定会捉襟见肘。
以进程监控回调 KAUTH_FILEOP_EXEC 为例，我们可以得到进程路径，但无法取得命令行参数。类似的情况还有文件创建时的 fmodep 上下文等。
不过这种限制不应该难倒我们，通过反汇编引擎和动态栈回溯我们可以挖出这些信息。下图是 Google Chrome 运行时那冗长的启动参数：
MAC (Mandatory Access Control) Framework
在 Mac OS X 10.5 Leopard 的 SDK 中苹果“错误的”为大家引入了一种新的监控机制 —— Mandatory Access Control Policy Framework。很快苹果公司纠正了这一错误，彻底将这一接口私有化。在文档 QA1574 [3] 中苹果明确的指出第三方不应该使用 MAC 机制，它不属于 KPI 的一部分。
这意味着只有苹果公司才能够调用这套相对灵活而强力的接口，例如：Apple Seatbelt Sandbox [4]、TMSafetyNet (Safety net for Time Machine) [5]、AMFI (Apple Mobile File Integrity) [6] 等等。
MAC Version 47 的接口细节如下：
https://github.com/opensource-apple/xnu/blob/10.12/security/mac_policy.h#L6192
我依稀记得微软公司也曾经有过类似的私货，结果这些 Undocumented API 的使用差点让微软被起诉到分家，罪名是私用 Undocumented API 涉嫌不公平竞争。
言归正传，因为 XNU 源代码公开，MAC Policy Framework 的使用非常容易上手。但另一个问题也随之而来，如何监控系统或第三方使用 MAC Framework 的情况？
上述需求的一个隐含问题是：如何保证遍历系统内部数据结构时的安全，即持有（不导出的）锁是个关键。这种小问题也不应该难倒我们，通过阅读 XNU 相关源代码，我们可以很快找到一个解决方案：
在民风彪悍的参数检查之后
https://github.com/opensource-apple/xnu/blob/10.12/security/mac_base.c#L652
https://github.com/opensource-apple/xnu/blob/10.12/security/mac_base.c#L655
https://github.com/opensource-apple/xnu/blob/10.12/security/mac_base.c#L658
https://github.com/opensource-apple/xnu/blob/10.12/security/mac_base.c#L661
是获取 mac_policy_mtx 锁的代码
https://github.com/opensource-apple/xnu/blob/10.12/security/mac_base.c#L671
在释放锁之前
https://github.com/opensource-apple/xnu/blob/10.12/security/mac_base.c#L780
系统给了第三方驱动两次回调的机会
https://github.com/opensource-apple/xnu/blob/10.12/security/mac_base.c#L770
https://github.com/opensource-apple/xnu/blob/10.12/security/mac_base.c#L774
这两次宝贵的机会是持锁的，我们可以用它来安全地 dump 相关内核数据结构。
下图展示了 TMSafetyNet、Apple Mobile File Integrity 以及 Apple Seatbelt Sandbox 对于 MAC Policy 回调的使用情况：
当然，对于研究苹果的沙箱设计与实现，这也会是一个好的起点。
另外，大量的 macOS 安全监控类软件也无视警告的使用了这个接口。例如：objective-see 的 BlockBlock [7] 以及 FireEye Mandiant 的 Monitor.app [8]。
使用上述方案针对 FireEye Mandiant 的 Monitor.app 做一次分析可以发现，它一共注册了五种回调：
1.mpo_cred_label_update_execve
2.mpo_file_check_mmap
3.mpo_pty_notify_grant
4.mpo_pty_notify_close
5.mpo_kext_check_load
值得说道的是，这五个回调是五次独立注册的结果。出于优化的考虑也许应该是“一次注册五个回调函数”而不是“五次注册五个回调函数”。回想 Windows XP 时代，大家为了争抢 PsSetCreateProcessNotifyRoutine 那 8 个名额拼的你死我活，现在的内核程序员还真是奢侈呢。
作为该分析的一个攻防副产物，我们可以任意 Unregister 系统或第三方的回调。现在再去看微软 CmRegisterCallback 函数中引入 Cookie 概念 [9] 感觉真的是明智的。
Kernel Inline Hook
由于没有类似 Patchguard [10] 的内核防护机制，在 64 位 macOS 内核中实现一个 Inline Hook 引擎并不是什么难事，最多就是需要在 lldb 不给力的情况下见识一下 Panic 的兄弟姐妹。
我们可以给 Inline Hook 引擎加大一些难度，给目标函数实现 Pre 和 Post Callback 回调。Pre Callback 可以用作参数过滤、Post Callback 可以用作结果篡改，这种设计会非常方便。
作为演示，我以 OSKext::start() 驱动加载例程作为练手，可以看到：
(1) 钩子监控到驱动程序被加载
(2) 结合反汇编引擎找到目标驱动入口
(3) 在 Pre Callback 中实现参数过滤、驱动代码篡改、强制错误返回等
(4) 在 Post Callback 中得到返回值，甚至再次篡改返回结果等
(5) 系统的后知后觉
当然，我们可以对任意一个我们所关心的内核函数做这样的事情，Inline Hook 的使用仅受制于想象力。
小结
1.上述功能点在开发 Rootkit 和 Anti-Rootkit、调试漏洞时都用得着。
2.祝您 lldb 内核调试愉快。
引用
[1] https://developer.apple.com/library/content/technotes/tn2127/_index.html
[3] https://developer.apple.com/library/content/qa/qa1574/_index.html
[5] https://support.apple.com/en-us/HT201250
[6] https://www.theiphonewiki.com/wiki/AppleMobileFileIntegrity
[7] https://www.synack.com/2015/11/17/monitoring-process-creation-via-the-kernel-part-i/
[8] https://www.fireeye.com/services/freeware/monitor.html
[9] https://msdn.microsoft.com/en-us/library/windows/hardware/ff541918(v=vs.85).aspx