从dylib加载C函数指针时如何限制权限保障应用安全

• 你的顾虑完全成立：加载到进程地址空间的dylib代码会继承主应用的所有权限，在关闭App Sandbox的场景下，可执行所有主应用有权限操作，包括读写用户目录、发起网络请求、访问钥匙串数据、调用系统敏感API等。
• 正如Craig Estey提到的，dlopen操作本身就存在风险：如果库路径校验不严格，可能被攻击者篡改路径加载恶意dylib，不需要你主动调用导出函数，dylib的构造函数（__DATA,__mod_init_func段逻辑）、Objective-C的+load方法会在dlopen执行阶段自动运行恶意代码，后续的权限限制操作完全来不及生效。

1. 首选XPC隔离方案（安全等级最高） #

这是苹果官方推荐的插件类功能实现方案，从根源规避同进程加载的权限泄漏问题：

• 将第三方dylib的加载、调用逻辑全部放到独立的XPC服务进程中运行，给该XPC进程单独配置最小必要权限，比如仅允许读写指定临时目录、禁止网络访问、禁止钥匙串访问等，和主应用的权限完全隔离。
• 主应用和XPC进程仅通过预设的XPC接口通信，仅传递必要的输入参数和执行结果，第三方代码完全接触不到主进程的内存、敏感权限资源。就算dylib包含恶意代码，也只能在受限的XPC沙箱环境中运行，无法影响主应用和用户数据安全。

2. 同进程加载的防御措施（仅适用于来源可控场景） #

注意：该方案无法100%规避恶意代码攻击，仅作为风险降低措施，不能替代XPC隔离
如果业务场景必须同进程加载dylib，需做好以下多层校验：

• 前置签名&哈希校验：dlopen执行前先校验dylib的代码签名，仅允许加载你信任的开发者签名、或者你自己二次签名的dylib，同时校验文件哈希和预设白名单匹配，拒绝未签名、签名不符、哈希不匹配的库。
• 禁止自动执行逻辑：要求提供的dylib不能包含构造函数、OC +load方法这类自动执行代码，加载前可以用otool相关逻辑校验dylib的段信息，避免dlopen阶段暗地执行未知代码。
• 调用层参数隔离：不要直接把dylib返回的函数指针暴露到主业务逻辑，在中间包装层对函数的输入输出做严格校验，禁止传入敏感数据（用户隐私、主进程内存地址、敏感文件路径等），也禁止dylib函数直接调用主进程的敏感接口。
• 路径防篡改校验：dylib必须存放在应用沙箱内的固定目录，加载前校验路径没有被符号链接篡改，避免路径劫持加载恶意库。

3. 需规避的错误方案 #

• 不要尝试在同进程内对已加载的代码做权限锁定：进程的权限是全局属性，同地址空间内的所有代码都可以调用系统API修改权限、访问全部内存，没有办法单独限制某一段代码的权限，所有同进程“权限锁定”方案都只能防御非刻意的恶意操作，无法对抗有针对性的攻击。
• 不要依赖dlclose做安全保障：如果dylib已经执行了恶意代码，哪怕你调用dlclose卸载库，恶意逻辑已经执行完成，造成的危害无法挽回。

内容的提问来源于stack exchange，提问作者Div