macOS Kext with valid signature rejected after 2nd installation (high sierra)

Update

At least one possible cause of that issue is now exactly known, see update Update (2020-04-10) below

---

Kext rejected due to insecure location is no signature rejection IMHO. Where does it say anything about signature? When the signature is the problem, it literary says so. To me that message says the location is insecure.

Have you checked the access permissions of /Library/Extensions? If the permissions are too open, the system will refuse to load kernel extensions with kextload or kextutil. The folder /Library/Extension must be owned by root:wheel and nobody but root must be able to write to that folder.

Same holds true for the access permissions of extensions, which are bundles (.kext) and thus actually directories. They must be owned by root:wheel and only root may have write permission to them.

If you look at the source code of macOS (yes, macOS is widely OpenSource, people tend to forget that), you see that this error is thrown in just one place:

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

Now kextIsInSecureLocation() is very simple:

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

And so is 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;
}

So with SIP disabled, any path is secure, with SIP enabled, volumes w/o SIP support are never secure, otherwise there seems to be a list of trusted paths and I know for sure that /Library/Extensions is such a trusted path, yet only if its permission are set correctly.

To check if your volume supports SIP, open Disk Utility app, select your boot volume and hit CMD+I. A window opens that lists all kind of properties and among these should be one saying:

System Integrity Protection supported : Yes

If it says no, you definitely would have a problem, but I have no idea which one as no way to en-/disable SIP for individual volumes is known, I only imagine that certain file systems or volumes mounted over the network may not be able to support SIP.

Update (2018-07-31)

Contacting Apple about this, they gave me the following tip:

Also, in case it is useful, sudo kextcache --clear-staging allows a user to clear the /Library/StagedExtensions folder without booting into recovery.

Not sure if this solves the problem in similar cases, just sharing this information with you here.

Update (2020-04-10)

Apparently the output of ls -alO@u /Library/Extensions should look like this:

drwxr-xr-x 5 root wheel restricted 160 Oct 24 12:18 .
drwxr-xr-x@ 3 root wheel restricted 96 Mar 25 13:00 ..
com.apple.rootless 25
drwxr-xr-x 15 root wheel restricted 480 Oct 24 12:18 Extensions

Yet on some affected systems it looks like this:

drwxr-xr-x 4 root wheel - 128 Apr 6 18:58 .
drwxr-xr-x 3 root wheel - 96 Apr 6 18:56 ..
drwxr-xr-x 13 root wheel - 416 Apr 6 18:57 Extensions

As you can see, the com.apple.rootless file attribute is missing and the folders are not marked restricted. Please note, that this is the output of a system that does have SIP enabled and where the user has never disabled it himself.

Unfortunately restoring that attribute is impossible. The value of that attribute is:

# xattr -p com.apple.rootless /Library/StagedExtensions
KernelExtensionManagement

But even with disabled SIP, the following command will fails:

sudo xattr -w com.apple.rootless KernelExtensionManagement \
    /Library/StagedExtensions

It returns [Errno 1] Operation not permitted. So if one of the work around tricks don't work that others have been posting here (and for some people none of them works!), be prepared to re-setup your system as it's seriously broken and that isn't your fault but Apple is not providing any help here.

I had the same issue.

The flag of /Library/StagedExtensions must be "restricted":

ls -laO /Library/StagedExtensions/

drwxr-xr-x@ 4 root wheel restricted 128 Nov 15 2017 StagedExtensions

If not, try below cmd from recovery mode:

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

Reboot and try installing the kext.