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.
cp. How are you installing the kext? If it's via a pkg, that shouldn't be the problem, if you're using a custom mechanism, consider whether something like this could be tripping up the kext auth system. – Unmistakable