web-dev-qa-db-ja.com

2回目のインストール後、有効な署名を持つmacOS Kextが拒否されました（High Sierra）

以前に製品をインストールしたマシンで、kext署名が拒否されたため、2回目のインストールが失敗しました。

いくつかの場所で同じエラーが発生しました。たとえば、ここでは https://support.eset.com/kb657 ですが、リカバリモードで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 /も削除しようとしましたが、何も変更されませんでした。

macosmacos-high-sierrakernel-extension
8
IdoT

この回避策は現在、本番環境で発生したすべてのケースを解決しました。

リカバリモードでロードし、SIPを無効にし、再起動し、kextキャッシュを無効にし、リカバリで再起動してから、SIPを再度有効にする必要があります。

詳細な手順：

  1. Appleメニューから[再起動]を選択します。
  2. Macが再起動したら、起動音が聞こえたらすぐにCommand（⌘）+ Rキーを押し続けます。 Appleロゴが表示されてコンピュータがリカバリモードになるまで、キーを押し続けます。
  3. これでコンピュータはリカバリモードになります。 Appleメニューからユーティリティ->ターミナルを選択します
  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メニューからユーティリティ->ターミナルを選択します
  11. コマンドを実行します：csrutil enable
  12. Appleメニューから、[再起動]を選択します。
  13. これでkextが実行されます。
0
IdoT

同じ問題がありました。

/ Library/StagedExtensionsのフラグは「制限」されている必要があります。

ls -laO /Library/StagedExtensions/

drwxr-xr-x @ 4ルートホイール制限128 2017年11月15日StagedExtensions

そうでない場合は、回復モードから以下のコマンドを試してください：

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

再起動してkextをインストールしてみます。

5
7aadi

_Kext rejected due to insecure location_は、署名の拒否ではありません。それは署名についてどこに言っていますか？署名が問題であるとき、それは文学的にそう言っています。私には、その場所は安全ではないというメッセージが表示されます。

_/Library/Extensions_のアクセス許可を確認しましたか？権限が開かれている場合、システムはkextloadまたはkextutilを使用したカーネル拡張のロードを拒否します。フォルダー_/Library/Extension_は_root:wheel_が所有していて、誰もrootがそのフォルダーに書き込めないようにする必要があります。

バンドル（_.kext_）であり、実際にはディレクトリである拡張機能のアクセス許可についても同様です。それらは_root:wheel_によって所有されている必要があり、rootのみが書き込み権限を持っている可能性があります。

MacOSのソースコード（そうです、macOSは広くオープンソースですが、人々はそれを忘れがちです）を見ると、このエラーが1か所でのみスローされていることがわかります。

_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_を押します。すべての種類のプロパティを一覧表示するウィンドウが開きます。これらのプロパティの1つは、次のようになります。

_System Integrity Protection supported : Yes
_

いいえと表示されている場合は、間違いなく問題がありますが、個々のボリュームのSIPを有効/無効にする方法がないことがわかっているので、特定のファイルシステムまたはボリュームがマウントされていると思いますネットワークを介してSIPをサポートできない場合があります。

アップデート（2018-07-31）

これについてAppleに連絡すると、彼らは私に次のヒントをくれました：

また、便利な場合は、_Sudo kextcache --clear-staging_を使用すると、起動せずに_/Library/StagedExtensions_フォルダーをクリアできます。

これで同様の場合の問題が解決するかどうかはわかりません。この情報をここで共有してください。

2
Mecki