注意，是猜想。因为，作者没有对实际关闭Rootless进行验证，因为只有一部Mac舍不得。

非用户态关闭Rootless其实大家都熟知，只要在保护模式下通过csrutil命令即可解除或者开启。非虫和邢俊杰在其合著的《macOS软件安全与逆向分析》中有逆向跟踪这个命令的讲述，最终主要是设置IODeviceTree:/potions中csr-active-config的值。其中，也讲述了之前几种关闭Rootless的方式，如在macOS10.11.1中存在的提权漏洞，通过覆盖堆栈调用_csr_set_allow_all()函数来关闭Rootless；或者通过加载内核模块，在内核中控制_csr_set_allow_all()达到同样的目的；其实，原理都是一样的，最终都是通过_csr_set_allow_all()函数关闭Rootless的。但是，在macOS10.11.4之后，系统内核取消了这一接口关闭Rootless的功能，意味着在用户态突破Rootless没有了思路。但是，在作者看来并非没有可能。

无论是保护模式下通过csrutil关闭Rootless还是通过镜像文件加入脚本，都是在非用户态下的方式，对于用户态下的突破其实没有意义。也正是这，导致macOS相对来说较为安全。

在开始之前，我个人谈一下Mac OS与Windows两大操作系统底层安全保护策略上的不同。Windows其实是采用了封装的保护策略，这种策略和其整体架构有关系，就是通过限制层层暴露的API的权限达到保护底层代码的安全；不过也正是这，导致了一个问题，就是只要获得底层的函数，其实就可以绕过或者躲避上层的安全机制，比如躲避杀软的查杀、突破防火墙等；也正是因为这，导致很多病毒和木马做的越来越底层；因为越底层越安全。但是，对于Mac OS来说，保护策略是完全不同的，其实macOS采用的是标签验证的保护策略，就是系统对内存、进程、文件、线程、设备驱动等均打了标签，通过标签对不同的用户设置不同的权限，这种机制的经典应用就是沙河机制Sandbox，其实，macOS底层的安全保护均是采用这种机制，准确的说是MAC，这里的MAC是指Mandatory Access Control(强制访问控制)，最早属于Trusted BSD，在苹果Free BSD5.X版本时引入，这是一种安全框架，允许在用户和非用户下制作组件，通过插件的形式进行系统的内核扩展，这种扩展其实就是安全策略，比如代码签名验证；MAC强制访问控制是苹果系统安全保护的基础，包括OSX和IOS。

我们看看MAC是系统什么时候加载启动的：苹果系统启动过程中，先调用i386_init()进行平台初始化，进而调用kernel_bootstrap,在这个模块中会调用mac_policy_init初始化MAC框架所需要的内存资源，以及保存MAC标签使用的zone，在这个函数末尾会启动系统的第一个线程kernel_bootstrap_thread,这个线程会做进一步的系统初始化工作，完善建立各种子系统，在这过程中，会调用mac_policy_initmach完成MAC模块的初始化工作，接下来才是bsd_init进行的BSD系统的初始化工作；由此过程看来，MAC强制访问控制机制是在BSD系统初始化之前就已经完成的，这就不难理解，为何在非用户态关闭Rootless必须要进入保护模式或者在镜像系统完成启动前植入脚步才能够达到目的了，因为一旦系统完成启动，Rootless就已经被初始化了。（这里仅仅是个人猜想，并未做出验证）

但是，无论是OS X还是IO S在初始化之后并未启动验证保护例程，为何这样说，因为这时候系统没有启动任何进程，真正在启动launchd之后才进入用户态。我们关系的核心问题正是，如何在用户态不进行系统重启状态下绕过或者关闭Rootless。在本篇开头，用户态下曾经可以调用_csr_set_allow_all()函数关闭Rootless，至少说明一个问题，用户态存在逆向关闭Rootless的通道或者说可能性，即使现在版本的OS关闭了这一通道，但是说明至少之前是可行的。其实，核心的思路就是逆向分析_csr_set_allow_all()函数的被调用、调用过程看看是否存在通向关闭Rootless的通道即可。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课