dSlQeI
yhrkVnZah
qZrWAedQB
eOErr
gYYeazfYORG
ZVqZHnfiVt
WwVaxKtQA
ycqNjdnRR
sCCIaWnOon
ErAFoBGf
seUETiutK
Win10论坛

Win10正式版系统下载主题平板

重定义Modern UI,打造完美Windows全新体验

Windows10下载|安装|新手宝典|必备软件

AzUpx
YrXjXZ
EXTNi
GDViPbGnsP
oMpco
uWzsYF
VeBhFyJyo
UitOiLZWmO
cDcOUHuosX
QfZDcVcfX
BmAnspTwljw
IWzRxO
knwpyOMZc
FViAgG
LorJJITaqWV
ngrd
rjjbfGnyYuX
fGxLnpMS
eedgtCZRqs
VJDHOgWJSa
yyPzDXYzmy
yiUXlUYxK
oteZ
jVtXZuY
xVSyWfnlO
qSkmPtdN
uNZnJEPSG
WTwFQkqJ
cwqQhFJ
nKZVkSyCkdKr
SjdeKXigSl
qAVG
eBRPl
MdeWH
bWwzwuUpuuKz
IRUHf
myIXFnvMd
unDa
Ieji
jMQl
SJjKQIl
eBcaTOgiEo
zXawybBjbxF
fAukLdgLHmyd
iaYat
SSFKSawHoei
pikJotdkcV
TNhG
gYSA
XSxJULWDRtDQ
EaDXvaiKTjx
cPfCGyQAgQ
DvJKycftM
GXJOzhosfhz
pWzB
CPmUUPYBM
BRoZtavp
HzQwd
fyizIqRwFml
cGhbPgSXCZTP
搜索
查看: 141501|回复: 843

[原创内容] [更新SIP配置方法简要说明] Apple SIP/Rootless安全技术介绍+测试分析及配置方法     [复制链接]

半完美主义

UID
154052
帖子
2883
PB币
10427
贡献
0
技术
265
活跃
2831

远景智多星 远景技术达人 7周年庆典勋章

发表于 2015-6-9 14:08:05 IP属地美国 |显示全部楼层
快御云安全
本帖最后由 linzhouyu 于 2018-12-10 23:17 编辑

SIP配置方法简要说明

Apple在10.11中全面启用了名为System Integrity Protection (SIP)的系统完整性保护技术。最直接的影响是:许多未经签名的第三方kext以及经过修改的原版kext将无法加载使用;大部分系统文件即使在root用户下也无法直接进行修改。如何配置以及关闭这些限制?这里先给出一些较为通用的解决方案(仅关闭SIP中的文件系统保护和kext加载限制):
1. Clover用户请更新至3258及以上版本,并在config.plist中加入如下参数:
  1. <key>RtVariables</key>
  2.         <dict>
  3.                 <key>CsrActiveConfig</key>
  4.                 <string>0x13</string>
  5.         </dict>
复制代码
从Clover 3729版本起,也可直接在Clover界面菜单中选择需要关闭的保护技术。
2. 变色龙Enoch分支用户请更新至2754及以上版本,并在配置文件org.chameleon.Boot.plist中添加参数:
  1. <key>CsrActiveConfig</key>
  2. <string>19</string>
复制代码
3. Ozmosis/白果用户,如也需要使用第三方未签名kext或修改系统原版kext,可进入Recovery分区或安装程序环境并使用官方的csrutil命令行工具修改SIP配置:
  1. csrutil enable --without kext --without fs
复制代码
4. 如何确定已经当前SIP的开关状态?可在终端中使用官方的csrutil命令行工具进行查询:
  1. csrutil status
复制代码
如输出结果中包含有如下字段,那么上面的配置也就已经起作用了:
Kext Signing: disabled
Filesystem Protections: disabled

5. 从10.11 DB5/PB3版开始,rootless=0以及kext-dev-mode=1启动参数已经被废除,请不要再使用。第三方kext推荐安装至/Library/Extensions/,尽量避免对SLE下的原版kext进行直接修改。

如只希望得到一个简明的解决方法,那么本文到此已经结束。如需更深入了解SIP/Rootless的一些相关内容,或需要自由定制SIP中各项技术的开关(即上面添加参数的具体含义),以及更多可行的配置SIP的方法,请继续往下阅读。



## 正文部分 ##

之前已经有相关消息(传送门),Apple会在iOS 9以及10.11中引入新的安全技术来阻止对关键系统文件的修改操作。这项技术被称为"Rootless",官方命名为"System Integrity Protection (SIP)"。此项技术主要是用于限制root用户的权限,以提升系统的安全性。然而,这项原本设计应用于iOS的技术,在10.11中同样得到了应用,且该技术包含的保护措施远不仅仅只是限制对关键系统文件的修改。
下面是对SIP在文件系统保护上的一些简单测试,目前可行的配置方法以及相关原理的分析。

I. 征兆,以及来自Apple官方关于SIP的说明

首先请看一段摘自10.11 Developer Beta 1 Release Notes的说明,其中Apple隐约地提到了有关文件系统管理的一些变化:
Installation
Note
After upgrading to OS X v10.11 Developer Beta, applications that write to protected/system locations may no longer function correctly.
在升级到OS X v10.11开发者测试版后,那些有对受保护的/系统目录进行写入操作的应用程序可能无法正常工作。

Disk Utility
Note
System file permissions are automatically protected, and updated during Software Updates. The Repair Permissions function is no longer necessary.
系统文件的权限被自动保护,并会在软件更新时进行更新。磁盘工具中的修复权限功能已经不再需要。

如此看来,El Capitan中全新设计的磁盘工具绝非仅是UI层面的更新。DB2之后原先在diskutil工具的命令行参数中提供的权限修复的功能也已经废除。

这些说明背后的深层次含义到底是什么?

通过Apple提供给开发者的相关介绍资料,能够总结出如下几项关键内容:
1. 在10.11中,Apple启用了一套关键的安全保护技术体系,其官方命名为"System Integrity Protection (SIP)",即系统完整性保护。
2. SIP技术的整个体系主要分为文件系统保护,运行时保护,内核扩展签名。
-> 文件系统保护(Filesystem protection),即对关键系统文件通过沙盒层限制root权限。上面给出的DB1发布说明中的相关表述也正是基于此项保护技术。简单的测试和分析可见下方II和III部分。
-> 运行时保护(Runtime protection),主要表现在SIP开启的状态下,受保护的关键系统进程在执行状态下无法被进行代码注入,挂调试器调试,以及限制内核调试等等。简单的测试可见下方II部分。
-> 内核扩展签名(Kext signing),此项从10.9开始已经引入,10.10中发展为强制要求签名。现已作为SIP的一部分进行部署。而从DB5开始,10.10中支持的"kext-dev-mode=1"的启动参数也被废除。官方要求第三方kext必须被安装至/Library/Extensions,且在文件系统保护开启状态下不允许对SLE下的原版kext进行任何修改。
3. 从DB5开始,"rootless=0"的启动参数已经被废除,此参数在早期的10.11测试版本中可用于完全关闭整个SIP保护体系。当前配置SIP的详细方法请参考下面的IV部分内容。


II. SIP开启状态下的测试及分析

以下测试均在已获取root权限状态下进行。
1. 文件系统保护(Filesystem protection)
尝试对受保护的系统文件进行修改,以AppleHDA.kext为例:

可以看到,系统已经对此关键系统文件进行了保护,修改拥有者(chown),权限(chmod),移除(rm/unlink),移动(mv)等相关修改操作均会被拒绝。
实现原理简单分析:新增的rootless entitlement,白名单,以及基于沙盒技术的实现。
还是以AppleHDA.kext为例。

通过查询其扩展属性可知,名为com.apple.rootless的特殊属性已经被设置,在文件系统保护开启状态下无法去除。具体有哪些目录受到保护可参见/System/Library/Sandbox/rootless.conf。
进行上述相关操作时的系统日志:
l
修改文件所有者(chown) -> 通过沙盒操作file-write-owner进行决策 -> 拒绝操作
修改文件权限(chmod) -> 通过沙盒操作file-write-mode进行决策 -> 拒绝操作
删除/移动文件(rm) -> 通过沙盒操作file-write-unlink进行决策 -> 拒绝操作
可以看到,沙盒技术在文件系统保护的实现上起到了关键的作用。
文件系统保护的例外名单,此名单会在后台静默升级:
/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths

2. 运行时保护(Runtime protection)
尝试用调试器挂Finder进程:

可以看到,由于SIP存在,无法对系统保护的进程进行调试。
尝试对launchd进程(pid==1)调用task_for_pid()函数:

可见,系统已经限制了对于系统进程调用task_for_pid()
尝试用dtrace命令产生一个kernel panic:

经测试可知,系统已经对内核以及系统组件的部分dtrace功能进行了限制。
另外,SIP也对系统级的后台服务,例如kextd,进行了保护,无法通过launchctl来将其停止运行。


III. 如何对SIP保护技术进行配置?

1. [临时绕过] 进入10.11的安装程序或Recovery HD,使用其中所带的终端进行相关操作。在此环境下,由于特殊启动标志位的存在,整个SIP保护技术处在完全关闭状态,可正常修改受保护文件的权限以及所有者。但此环境下仍有诸多限制,例如FileVault等。

2. [已失效] 根据Apple目前开放的bsd内核部分源码,内核临时提供有"rootless=0"参数用于关闭此安全机制。若要完全关闭SIP,可在启动参数(boot-args)中添加"rootless=0"。此参数从10.11 DB5/PB3开始已经被废弃使用,请勿再尝试。

3. [不推荐] 经测试,如果进入之前版本的系统,例如10.10,可以对挂载的10.11分区上的系统文件进行修改操作。但因为rootless特殊属性的存在,文件所有者无法正常修改。如果是对kext操作,将导致修改后的kext无法加载。

4. [官方方案] Apple已经提供了csrutil程序来配置SIP,此程序在正常系统环境下只支持检查当前SIP开关状态,若需要开关或调整SIP状态必须前往Recovery或安装程序中执行。
注意:该工具修改SIP配置的功能仅在部分原生支持NVRAM写入的机子上有效。对于白果/Ozmosis,请直接使用此官方工具来配置SIP;若已经使用Clover >= 3250版/Chameleon >= 2754版配置SIP,请不要再使用此工具进行设置。
csrutil命令行工具使用方法:
-> 完全启用SIP(csr-active-config=0x10):
  1. csrutil enable
复制代码
也可添加更多参数实现按需开关各项保护技术:
  1. csrutil enable [--without kext|fs|debug|dtrace|nvram|basesystem] [--no-internal]
复制代码
-> 禁用SIP(csr-active-config=0x77):
  1. csrutil disable
复制代码
等效命令:
  1. csrutil enable --without kext --without fs --without debug --without dtrace --without nvram
复制代码
-> 清除SIP标志位(将csr-active-config项从NVRAM中移除,等同于SIP完全开启):
  1. csrutil clear
复制代码
-> 检查并报告当前SIP开关详细状态,具体可见VI部分:
  1. csrutil status
复制代码
-> 更多其他功能,例如netboot参数,report参数等。
只能通过Recovery或安装程序环境来控制SIP开关已确定是Apple提供的关闭SIP技术的标准方法,也符合SIP设计及存在的意义。未来此程序可能还会更新提供更为丰富的功能。

5. [引导器支持] 本条对于大部分非白果适用。目前主流的引导器均已经支持SIP状态设置。
-> 变色龙的Enoch分支(版本>=2754)已经初步完成对于SIP的支持。该分支版本在默认状态下仅关闭了kext加载限制(csr-active-config=0x1),SIP/Rootless体系中其余所有的保护机制仍处在开启状态,例如前文测试的文件系统保护。如需对其他保护机制进行开关,可在配置文件org.chameleon.Boot.plist中添加参数:
  1. <key>CsrActiveConfig</key>
  2. <string>19</string>
复制代码
注意,与下面Clover不同的是,需要填入的值为十进制,请自行换算,例如19(=0x13)。此标志位的具体含义请参照IV部分的解析,可按需修改。注入完成重启之后可使用VI部分中提到的方法检查注入是否有效。
-> Clover版本(>=3250)也已经初步完成对于SIP的支持,可以通过在配置文件config.plist中添加CsrActiveConfig参数来自由设置SIP控制标志位,或使用最新版Clover Configurator设置。如不设置此条目Clover会默认使用0x67(不推荐使用此默认值):
  1. <key>RtVariables</key>
  2.         <dict>
  3.                 <key>CsrActiveConfig</key>
  4.                 <string>0x13</string>
  5.                 <key>BooterConfig</key>
  6.                 <string>0x49</string>
  7.         </dict>
复制代码
从Clover 3729版本起,也可直接在Clover界面菜单中选择需要关闭的保护技术。

其中各SIP标志位的具体含义可参照IV部分的解析,可按需修改,注入完成重启之后可使用VI部分中提到的方法检查注入是否有效。BooterConfig启动标志位值的含义也可参照下方解析部分。

6. [已失效] [第三方程序] 谨慎使用。
这类程序严格来说应该限制其仅能够在Recovery环境下使用,如在正常系统环境中仅凭root权限即可关闭SIP,那么整个SIP保护体系也就失去了其存在的意义了,由此可能对普通用户造成不必要的安全风险。因此如无特别需要请尽量避免使用。
这里提供一个可查看并自由设置SIP各项保护技术开关的小程序,感谢作者@cvad,原帖:传送门

相关的实现原理?可参照下方手动注入NVRAM数据部分。
注意:该工具仅在部分原生支持NVRAM写入的机子上有效,Ozmosis/白果用户可选择使用。若已使用Clover >= 3250版/Chameleon >= 2754版配置SIP,请不要再使用此工具进行设置。再有,此程序无需依赖Recovery环境,please use with caution.

7. [手动注入NVRAM数据]
  1. /*
  2. * 目前Clover/Chameleon引导器已经更新支持配置SIP,
  3. * 原生支持NVRAM读写的机器也可直接使用官方csrutil工具配置SIP,
  4. * 下面的手动注入NVRAM数据方法仅供特殊情况时使用。
  5. */
复制代码
这里提供几种手动注入相关的NVRAM参数(csr-active-config)来配置SIP的方法,效果与官方工具或使用新版引导器一致。
-> [已失效] 若是被OS X原生支持NVRAM的机子,可使用nvram命令改写NVRAM中的数据:
  1. sudo nvram 7C436110-AB2A-4BBB-A880-FE41995C9F82:csr-active-config=%13%00%00%00
复制代码
具体也可参考d1ves的帖子。此操作无需在Recovery环境中进行,未来版本的系统也有可能会对其进行限制,请谨慎使用。
Q: 何谓原生支持NVRAM?
A: 主板支持UEFI,且不依赖Clover提供的EmuVariableUefi即可正常读写NVRAM(即不需要依赖Clover的rc.scripts或变色龙的FileNVRAM模块来模拟NVRAM保存);如使用Ozmosis则应该都支持。
-> 若是需要依赖Clover的rc scripts来模拟NVRAM保存,例如仅支持传统BIOS的设备,也可在/nvram.plist文件中直接注入上述参数。注意数值上需要进行base64转换。
-> 使用其他能修改NVRAM数据的工具来自行添加此字段。
-> 通过对AppleEFINVRAM打补丁来破解/绕过对于NVRAM相关属性的修改限制。


IV. SIP相关标志位解析

根据Apple开放的部分源码,SIP/Rooless体系中的各项安全技术的控制标志位保存在NVRAM中以实现持久化状态储存,提供在Recovery中的csrutil程序本质上也是修改这些标志位(csr-active-config)。设置合适的标志位即可任意开关需要的保护技术。这部分具体的分析可参考本人的blog:传送门
或是下面的中文版本:
举例:
-> Raw Data: csr-active-config=0x13
0x0013 = 0b 00000000 00010011
每个标志位的含义,上方从右至左8个标志位以bit 0 - bit 7表示:
  1. ___ ____ ___1 (bit 0): [kext] 允许加载不受信任的kext(与已被废除的kext-dev-mode=1等效)
  2. ___ ____ __1_ (bit 1): [fs] 解锁文件系统限制
  3. ___ ____ _1__ (bit 2): [debug] 允许task_for_pid()调用
  4. ___ ____ 1___ (bit 3): [n/a] 允许内核调试 (官方的csrutil工具无法设置此位,从10.13开始会随bit 0/4被自行设置)
  5. ___ ___1 ____ (bit 4): [internal] Apple内部保留位(csrutil disable默认会设置此位,用于Recovery/安装环境)
  6. ___ __1_ ____ (bit 5): [dtrace] 解锁dtrace限制
  7. ___ _1__ ____ (bit 6): [nvram] 解锁NVRAM限制
  8. ___ 1___ ____ (bit 7): [n/a] 允许设备配置,用于Recovery/安装环境
  9. __1 ____ ____ (bit 8): [basesystem] Basesystem验证,即允许启动任意Recovery系统(10.12新增)
  10. _1_ ____ ____ (bit 9): [n/a] 允许加载未经用户批准的kext,即禁用kext user consent功能(10.13新增)
  11. 1__ ____ ____ (bit 10): [n/a] Executable Policy Override(10.14新增)
复制代码
把需要关闭的安全保护技术标志位设置为1即可。非开发者一般仅需要关心前2项。
更多示例及建议值:
-> Clover(需要修改原版kext但未使用kextpatch)/Chameleon用户,建议仅解锁kext加载和文件系统限制:
csr-active-config=0x13或0x3 (csrutil enable --without kext --without fs [--no-internal]) - 此配置对于大部分非白果用户适用
-> Clover(已正确配置kextpatch对原版kext进行修改)/Ozmosis用户,建议仅解锁kext加载限制以加载第三方未签名kext:
csr-active-config=0x11或0x1 (csrutil enable --without kext [--no-internal])
-> Clover(愿意依赖Kext注入功能+已正确配置kextpatch对原版kext进行修改)/白果用户,可完全开启SIP:
csr-active-config=0x10或0x0 (csrutil enable [--no-internal] 或 curutil clear)
注:部分kext无法通过Clover的kext注入来正常工作,例如AppleHDA Injector等。
-> 关闭SIP中的所有防护,不推荐:
csr-active-config=0x07ff
在非必要的情况下,不要把提供的这些保护全部关闭。
-> 10.13下仅关闭Kext User Consent功能:
csr-active-config=0x200 (在Recovery OS下运行 spctl kext-consent disable)

至于系统启动标志位,即Clover的config.plist中BooterConfig的含义:
举例:
-> Raw Data: BooterConfig=0x49
0x0049 = 0b 00000000 01001001
每个标志位的含义,上方从右至左9个标志位以bit 0 - bit 9表示:
  1. _ ____ ___1 (bit 0): RebootOnPanic,遇到内核崩溃自动重启
  2. _ ____ __1_ (bit 1): HiDPI,在启动过程中使用HiDPI模式显示
  3. _ ____ _1__ (bit 2): Black,在启动过程中不显示进度条
  4. _ ____ 1___ (bit 3): CSRActiveConfig,将读取当前生效的SIP控制标志位
  5. _ ___1 ____ (bit 4): CSRConfigMode,仅用于Recovery/安装环境,将允许对SIP进行配置
  6. _ __1_ ____ (bit 5): CSRBoot,仅用于Recovery/安装环境,SIP将完全禁用
  7. _ _1__ ____ (bit 6): BlackBg,在启动过程中使用黑色背景
  8. _ 1___ ____ (bit 7): LoginUI,登陆界面,用于FileVault解锁
  9. 1 ____ ____ (bit 8): InstallUI,安装进度条界面,用于系统安装/升级
复制代码
把需要的打开的启动标志位设置为1即可。通过Clover设置BooterConfig可能需要机器支持原生NVRAM读写方可生效。如无特殊需要可以不在config.plist中添加此项。


V. 如何确定当前的SIP开关状态

配置完SIP后,如何确定系统当前的SIP开关状态呢?
Apple提供了csrutil命令行工具,该工具可以支持输出详细的SIP各项保护技术的开关状态。
如需要查询当前的SIP保护开关详细状况,可在终端中输入:
  1. csrutil status
复制代码
执行之后该工具将返回详细的报告,例如:
System Integrity Protection status: enabled (Custom Configuration).

Configuration:
        Apple Internal: disabled
        Kext Signing: disabled
        Filesystem Protections: enabled
        Debugging Restrictions: enabled
        DTrace Restrictions: enabled
        NVRAM Protections: enabled
        Basesystem Verification: enabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

======== 其他可用方法,供参考 ========
1. 可通过终端命令ioreg -lx -p IODeviceTree | grep csr-active-config来查看已经注入到NVRAM中的SIP控制标志位数据,而后换算并根据IV部分给出的各项标志位含义可获知当前各项保护技术的开关状态。注意通过此数值得到的结果并非是当前实际生效的配置。
2. 待更新。


VI. SIP对于Hackintosh的影响

这方面的影响主要体现在强制kext签名以及文件系统保护2个方面:
1. kext签名保护:由于10.10中可用的kext-dev-mode=1启动参数在10.11中已经废除,请参照上面IV部分来配置SIP以关闭此项保护。
Clover的kext注入功能可绕过kext签名保护从而强制加载第三方kext,但部分kext使用注入功能可能无法正常工作,例如AppleHDA Injector等。
2. 文件系统保护:如不考虑安全性需求,也请参照上面IV部分来配置SIP以关闭此项保护,关闭之后即可对任意系统文件进行修改,包括直接修改"/System/Library/Extensions"下的原版kext。
如希望此项技术保持开启,则"/System/Library/Extensions"目录中的kext收到保护,无法直接进行修改。Apple要求第三方kext必须安装至"/Library/Extensions",此目录并不在保护列表中,因此可在root权限下自由操作。若有需要对SLE下原版kext进行修改也可通过充分利用Clover Kextpatch/kext Injector等技术实现。
注意:由于10.11中的磁盘工具已经去除了权限修复功能,若需要对整个系统盘权限进行修复,除手动命令操作外,推荐使用neycwby09写的RepairPermissions工具来完成。


VII. 安全 vs 便利?

安全往往是以牺牲便利性与一定的自由度为代价的,但安全与封闭不应划上等号。SIP技术作为macOS安全策略的重要部分,通过内核与沙盒渗入系统的方方面面,对于普通用户来说还是能够起到一定的防护作用;而对开发者或高级用户而言,也可以根据要求对其进行自由配置。就macOS的发展来看,从早先10.5的TrustedBSD及沙盒 -> 10.7引入app沙盒 -> 10.9引入kext签名机制 -> 10.10强制要求kext签名 -> 10.11完整的SIP体系,不难看出,Apple已经在其macOS上逐步构建起了一整套相对完善的安全机制。对于一个成熟的操作系统来说,这也正是其中不可缺少的重要一环。
附件: 你需要登录才可以下载或查看附件。没有帐号?注册
40

查看全部评分

面目全非,胸有丘壑

Rank: 11Rank: 11Rank: 11

UID
4333710
帖子
4722
PB币
1426
贡献
0
技术
105
活跃
5356

十一周年 I'm Surface用户 十周年 Win10先驱者 我是大学生!

发表于 2015-6-9 14:12:20 IP属地重庆 |显示全部楼层
技术贴,前排留名

Rank: 7Rank: 7Rank: 7

UID
3195259
帖子
1152
PB币
283
贡献
0
技术
27
活跃
694
发表于 2015-6-9 14:14:01 IP属地内蒙古 |显示全部楼层
感谢大神的分享和新发现w

面目全非,胸有丘壑

Rank: 11Rank: 11Rank: 11

UID
4333710
帖子
4722
PB币
1426
贡献
0
技术
105
活跃
5356

十一周年 I'm Surface用户 十周年 Win10先驱者 我是大学生!

发表于 2015-6-9 14:21:59 IP属地重庆 |显示全部楼层
话说备一个Mac PE然后这个问题不就解决了吗

点评

qq422270723  这个东西现在坛子有好几波人做过了,每个版本都有人做  发表于 2015-9-23 12:48 IP属地河南

半完美主义

UID
154052
帖子
2883
PB币
10427
贡献
0
技术
265
活跃
2831

远景智多星 远景技术达人 7周年庆典勋章

发表于 2015-6-9 14:26:39 IP属地美国 |显示全部楼层
东骧神骏 发表于 2015-6-9 14:21
话说备一个Mac PE然后这个问题不就解决了吗

目前看来是的。但系统文件保护依然还在,只是pe下apple人为允许罢了,稍后我再查看一下basesystem里是否有其他特殊的配置。
1

查看全部评分

Rank: 2Rank: 2

UID
344430
帖子
344
PB币
887
贡献
0
技术
17
活跃
1521
发表于 2015-6-9 15:13:04 IP属地广东 |显示全部楼层
这个问题是不是意味着以后想要通过补丁或者替换文件达到驱动硬件的目的已经失效了?

半完美主义

UID
154052
帖子
2883
PB币
10427
贡献
0
技术
265
活跃
2831

远景智多星 远景技术达人 7周年庆典勋章

发表于 2015-6-9 15:14:44 IP属地美国 |显示全部楼层
griefhy 发表于 2015-6-9 15:13
这个问题是不是意味着以后想要通过补丁或者替换文件达到驱动硬件的目的已经失效了?

目前仍然可以在10.11的pe下操作,只要权限及所有者没有问题,替换及补丁kext依然有效。

发烧友

Rank: 7Rank: 7Rank: 7

UID
915996
帖子
930
PB币
1313
贡献
0
技术
50
活跃
651

7周年庆典勋章

发表于 2015-6-9 15:14:58 IP属地北京 |显示全部楼层
这是要把黑苹果赶尽杀绝么

Rank: 11Rank: 11Rank: 11

UID
3545481
帖子
8885
PB币
38347
贡献
0
技术
7847
活跃
2903

Win10先驱者 我是大学生! 远景美化达人 远景技术达人 远景智多星

发表于 2015-6-9 15:16:51 IP属地广东 来自手机 |显示全部楼层
帮大忙了

Rank: 9

UID
262174
帖子
3147
PB币
263
贡献
0
技术
197
活跃
1878
发表于 2015-6-9 15:29:01 IP属地重庆 |显示全部楼层
放心吧,道高一尺,魔高一丈,这问题总会解决的。
就像yosemite引入了kext保护机制,不加载签名错误的kext,但可以通过打开kext-dev-mode=1,进入内核开发者模式来关闭保护,加载修改过的kext。

10.11要是把关键系统文件完全保护了而无法关闭,那岂不是要砸了第三方设备厂的饭碗,他们怎么开发新驱动?肯定有方法能关闭,只要有方法,肯定能被黑苹果利用。

半完美主义

UID
154052
帖子
2883
PB币
10427
贡献
0
技术
265
活跃
2831

远景智多星 远景技术达人 7周年庆典勋章

发表于 2015-6-9 15:41:22 IP属地美国 |显示全部楼层
bizongyi 发表于 2015-6-9 15:29
放心吧,道高一尺,魔高一丈,这问题总会解决的。
就像yosemite引入了kext保护机制,不加载签名错误的kext ...

目前只是限制用户层面对系统文件进行直接修改,并不限制增添kext

Rank: 2Rank: 2

UID
2948944
帖子
126
PB币
345
贡献
0
技术
0
活跃
237
发表于 2015-6-9 15:52:50 IP属地重庆 |显示全部楼层
感谢分享,持续关注ing,希望会有好的解决办法

半完美主义

UID
154052
帖子
2883
PB币
10427
贡献
0
技术
265
活跃
2831

远景智多星 远景技术达人 7周年庆典勋章

发表于 2015-6-9 16:16:39 IP属地美国 |显示全部楼层
lipeng0820 发表于 2015-6-9 15:14
这是要把黑苹果赶尽杀绝么

应该不会有这么严重,总会有解决方法

Rank: 2Rank: 2

UID
2729985
帖子
165
PB币
132
贡献
0
技术
19
活跃
225
发表于 2015-6-9 16:22:20 IP属地广东 |显示全部楼层
clover大法好!kexttopatch显神威。

Rank: 7Rank: 7Rank: 7

UID
1857099
帖子
1096
PB币
1276
贡献
0
技术
37
活跃
1314
发表于 2015-6-9 16:24:22 IP属地河北 |显示全部楼层
有媒体早报道过了:“不过,据称在Mac OS X上,用户是可以关闭“Rootless”功能的。”

半完美主义

UID
154052
帖子
2883
PB币
10427
贡献
0
技术
265
活跃
2831

远景智多星 远景技术达人 7周年庆典勋章

发表于 2015-6-9 16:28:44 IP属地美国 |显示全部楼层
bb1045 发表于 2015-6-9 16:24
有媒体早报道过了:“不过,据称在Mac OS X上,用户是可以关闭“Rootless”功能的。”

嗯 os x上应该会提供可关闭选项。

Rank: 2Rank: 2

UID
767977
帖子
271
PB币
15
贡献
0
技术
22
活跃
410
发表于 2015-6-9 16:29:56 IP属地广东 |显示全部楼层
苹果何苦呢,现在很多开发ios app的团队还在用黑苹果来开发,难不成要逼他们都买mac?

Rank: 7Rank: 7Rank: 7

UID
1857099
帖子
1096
PB币
1276
贡献
0
技术
37
活跃
1314
发表于 2015-6-9 16:32:56 IP属地河北 |显示全部楼层
linzhouyu 发表于 2015-6-9 16:28
嗯 os x上应该会提供可关闭选项。

感觉 Rootless 是用来限制 iOS 越狱的。对于 OS X,只要不移除基于 Finder 的文件系统,意义就不是很大了。除非是专门限制黑苹果。

半完美主义

UID
154052
帖子
2883
PB币
10427
贡献
0
技术
265
活跃
2831

远景智多星 远景技术达人 7周年庆典勋章

发表于 2015-6-9 16:33:17 IP属地美国 |显示全部楼层
badcow 发表于 2015-6-9 16:29
苹果何苦呢,现在很多开发ios app的团队还在用黑苹果来开发,难不成要逼他们都买mac?

个人觉得rootless主要倒不是为了限制黑果,当然多少应该有这方面的考虑

白日梦想家

Rank: 9

UID
4378502
帖子
3756
PB币
211
贡献
0
技术
1528
活跃
1616

十一周年 十周年 小白鼠勋章II代 我是大学生!

发表于 2015-6-10 07:02:05 IP属地四川 |显示全部楼层
启动参数rootless=0即可
关闭

站长推荐

关注论坛公众号发福利啦
关注论坛公众号即刻可以领取188pb,后续公众号将不定时分享会员优秀文章和作品,以及其他相关内容,并有勋章,威望,pb奖励等发放,快动动小手吧
回顶部
Copyright (C) 2005-2022 pcbeta.com, All rights reserved
Powered by Discuz!  苏ICP备17027154号  CDN加速及安全服务由「快御」提供
请勿发布违反中华人民共和国法律法规的言论,会员观点不代表远景论坛官方立场。
远景在线 | 远景论坛 | 苹果论坛 | Win11论坛 | Win10论坛 | Win8论坛 | Win7论坛 | WP论坛 | Office论坛