第二次安装后拒绝有效签名的macOS Kext（高山脉）

问题描述 投票：8回答：3

在之前安装了我的产品的机器中，由于kext签名拒绝，第二次安装失败。

我在某些地方看到了相同的错误，例如：https://support.eset.com/kb6570，但是即使在恢复模式下清除kext_policy表并在设置中手动批准kext - >下次启动时的安全性，kext仍然似乎未经批准。

例如，运行kextutil提供以下内容：

Kalyan:~ KalyanPentakota$ sudo kextutil /Library/Extensions/mycompanyAT.kext/
Password:
Kext rejected due to insecure location: <OSKext 0x7f8e9ff02e20 [0x7fffa11c8af0]> { URL = "file:///Library/StagedExtensions/Library/Extensions/mycompanyAT.kext/", ID = "com.mycompany.at" }
Kext rejected due to insecure location: <OSKext 0x7f8e9ff02e20 [0x7fffa11c8af0]> { URL = "file:///Library/StagedExtensions/Library/Extensions/mycompanyAT.kext/", ID = "com.mycompany.at" }
Diagnostics for /Library/Extensions/mycompanyAT.kext:

数据库中的kext批准状态：

sqlite> select * from kext_policy;
XE2XNRRXZ5|jp.co.canon.bj.print.BJUSBLoad|1|Canon Inc.|8
KBVSJ83SS9|com.citrix.kext.gusb|1|Citrix Systems, Inc.|8
MK9BR98H51|com.mycompany.at|1|My Company Ltd|1

Kext证书验证：

Kalyan:~ KalyanPentakota$ codesign -dvv /Library/Extensions/mycompanyAT.kext/
Executable=/Library/Extensions/mycompanyAT.kext/Contents/MacOS/mycompanyAT
Identifier=com.mycompany.at
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=8179 flags=0x0(none) hashes=250+3 location=embedded
Signature size=4651
Authority=Developer ID Application: My Company Ltd (MK9BR98H51)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Signed Time=Jun 5, 2018 at 6:05:21 AM
Info.plist entries=22
TeamIdentifier=MK9BR98H51
Sealed Resources version=2 rules=13 files=1
Internal requirements count=1 size=212

我也尝试删除/ Library / StagedExtensions / Library /，但它也没有改变任何东西。

macos macos-high-sierra kernel-extension
3个回答
5
投票

我遇到过同样的问题。

/ Library / StagedExtensions的标志必须“受限制”：

ls -laO /Library/StagedExtensions/

drwxr-xr-x @ 4根轮限制2017年11月15日StagedExtensions

如果没有，请在恢复模式下尝试以下cmd：

chflags -R restricted /V*/*/Library/StagedExtensions

重新启动并尝试安装kext。

1
投票

此解决方法目前解决了我们在生产中遇到的所有情况：

您应该加载恢复模式，禁用sip，重新启动，使kext缓存无效，再次重新启动恢复，然后重新启用sip。

详细步骤：

  1. 从Apple菜单中选择重新启动。
  2. 当Mac重新启动时，请在听到启动铃声后立即按住Command（⌘）+ R键。按住键直到出现Apple徽标，使计算机进入恢复模式。
  3. 计算机现在处于恢复模式。从Apple菜单中选择Utilities - > Terminal
  4. 运行命令：csrutil disable
  5. 从Apple菜单中，选择重新启动。
  6. 加载macOS后，打开终端并键入：sudo kextcache -invalidate /
  7. 如果您的kext位于非标准位置，请添加自定义kext路径，例如： sudo kextcache -invalidate /Library/MyApp/MyApp.kext
  8. 从Apple菜单中，选择重新启动。
  9. 当Mac重新启动时，请在听到启动铃声后立即按住Command（⌘）+ R键。按住键直到出现Apple徽标，使计算机进入恢复模式。
  10. 计算机现在处于恢复模式。从Apple菜单中选择Utilities - > Terminal
  11. 运行命令：csrutil enable
  12. 从Apple菜单中，选择重新启动。
  13. 现在你的kext应该运行..
0
投票

Kext rejected due to insecure location没有签名拒绝恕我直言。签名在哪里说什么？当签名是问题时，文学就这么说了。对我来说，这个消息说位置不安全。

你检查过/Library/Extensions的访问权限了吗？如果权限过于开放，系统将拒绝使用kextload或kextutil加载内核扩展。文件夹/Library/Extension必须由root:wheel拥有，除root外，没有人必须能够写入该文件夹。

对于扩展的访问权限也是如此，这些扩展是bundle（.kext），因此实际上是目录。它们必须由root:wheel拥有，只有root可能拥有写入权限。

如果你看一下macOS的源代码（是的，macOS是广泛的OpenSource，人们往往会忘记这一点），你会发现这个错误只出现在一个地方：

if (authOptions->requireSecureLocation) {
    if (!kextIsInSecureLocation(theKext)) {
        OSKextLogCFString(NULL,
                          kOSKextLogErrorLevel | kOSKextLogValidationFlag,
                          CFSTR("Kext rejected due to insecure location: %@"),
                          theKext);
        result = false;
        goto finish;
    }
}

现在kextIsInSecureLocation()非常简单：

Boolean
kextIsInSecureLocation(OSKextRef theKext)
{
    NSURL *url = (__bridge NSURL *)OSKextGetURL(theKext);
    if (!url) {
        return false;
    }
    return pathIsSecure(url.path);
}

pathIsSecure()也是如此：

Boolean
pathIsSecure(NSString *path) {
    Boolean is_secure = false;
    BOOL is_protected_volume = rootless_protected_volume(path.UTF8String) ? YES : NO;
    BOOL is_trusted_path = rootless_check_trusted_class(path.UTF8String, "KernelExtensionManagement") == 0 ? YES : NO;

    if (isSIPDisabled()) {
        // SIP is disabled so everything is considered secure.
        is_secure = true;
    } else if (!is_protected_volume) {
        // SIP is enabled and the volume is not protected, so it's insecure.
        is_secure = false;
    } else {
        // SIP is enabled and it is a protected volume, so it's only secure if it's trusted.
        is_secure = is_trusted_path;
    }
    return is_secure;
}

因此，在禁用SIP的情况下，任何路径都是安全的，启用SIP后，没有SIP支持的卷永远不会安全，否则似乎有一个可信路径列表，我确信/Library/Extensions是一个可靠的路径，但只有当其权限设置正确。

要检查您的卷是否支持SIP，请打开Disk Utility应用程序，选择您的启动卷并点击CMD+I。将打开一个窗口，列出所有类型的属性，其中应该是一个说法：

System Integrity Protection supported : Yes

如果它说不，你肯定会有问题，但我不知道哪一个无法为单个卷启用/禁用SIP已知，我只想象通过网络安装的某些文件系统或卷可能不是能够支持SIP。

更新（2018-07-31）

联系Apple有关此事，他们给了我以下提示：

此外，如果有用，sudo kextcache --clear-staging允许用户清除/Library/StagedExtensions文件夹而无需启动恢复。

不确定这是否解决了类似情况下的问题，只是在这里与您分享这些信息。

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.