How to identify extensions blocked by Gatekeeper

Question

In macOS High Sierra, System Prefs > Security, it says "Some system software was blocked from loading. I see a list there of three developers, and I don't recognize all of them. I'm guessing these are kext files in /L/E or /S/L/E, but how can I identify exactly which kext corresponds to each developer name? I tried grep -rn "Intel Corporation Apps" /System/Library/Extensions but that doesn't find it.

EDIT: Adding to this question because it was never fully answered and I have now encountered another stubborn kext I can't remove in Mojave. It appears in Disabled Software but not in System Preferences security pane.

I have grepped /L/E and /S/L/E and /Library/StagedExtensions and the only result I find is in /System/Library/Extensions/AppleKextExcludeList.kext/Contents/Info.plist

kextutil can't find it so where else can I look?:

# kextutil -b cn.com.bwstor.filesystems.enfs
Can't find extension with identifier cn.com.bwstor.filesystems.enfs

Answer 1

I figured it out. In System Information > Software > Disabled Software, it shows a list of these extensions with their bundle identifier. In my case, that was enough info to understand what the app is, but to locate the actual kext file requires more digging. Example:

grep -r "com.aladdin.kext.aksfridge" /Library/Extensions finds nothing.

grep -r "com.aladdin.kext.aksfridge" /Library/Application Support found it.

I'm not sure if there is a documented list of locations that are allowed to load kexts, but you could grep the whole hard drive for the bundle ID and that would surely find it.

Be prepared to wait as grep -r scours your entire hard drive...

If you find your file is an extension located in: /Library/StagedExtensions/Library/Extensions/

sudo rm -rf will not work, you can only remove it using:

sudo kextcache --clear-staging

Answer 2

I had a similar experience today. I thought it might be of help for you.

"System Preferences > Security & Privacy > General" tab showed me a blocked system software. It mentioned developer 'Jongwoo Choi' which I didn't recognize. What software is this? Where is it installed? After searching the internet regarding these blocked software extensions they appear to be "kernel extensions" or .kext files.

Some more searching taught me this:

• "System Information > Software > Extensions" shows all the extensions installed on your machine. Give it some time to load, the list might be long.
• Now, too find the blocked extension by this developer, I ordered the list by "Obtained from". If you have an extension name, you can order by "Extension name" column. Most of the extensions are obtained from Apple so I guess these can be skipped. Also those with "Loaded" value "yes" can be skipped as well since the software is blocked from loading. I then checked each item from "Identified Developer" or "Not Signed".
• You now should be able to find the developer or company name (that was mentioned in the "System Preferences > Security & Privacy > General" tab list of blocked software) in the details you get for each item in the window below the extensions list. Check the value for "Signed By". For me there was only one entry for that specific developer.
• Once you found it, the value for "Location" will show you where the .kext file is located. The value for "Bundle ID" might also help to explain what this is about.

Since the kernel extensions wasn't loaded I decided to remove it.

sudo rm -rf path/to/the/kext/file

I then rebooted (not sure if it is needed). "System Preferences > Security & Privacy > General" didn't show me the blocked software message. Hooray!

However, "System Information > Software > Disabled Software" DID still show me one entry of disabled software. I recognised the entry title from the detailed information in the extension list earlier on. It is the one I just removed. For me this was "F3YNT8UCP3 - net.sf.tuntaposx.tap"

Why is it still there while I removed the .kext file? As Elliott mentioned in a comment above, it seems that there is a SQLite db that tracks information about the approval of installed software. Deleting the .kext file does not remove the entry from the database.

How to remove the entry from the db to remove it from the "System Information > Software > Disabled Software" list is described in here on Stack Overflow. The first part of the disabled software entry is the Team ID (F3YNT8UCP3 in my case). You'll need this ID to specify which entry to delete from the SQLite db.

So removing the .kext file should remove the warning in "System Preferences > Security & Privacy > General". Removing the item from the SQLite db should remove the disabled software entry in "System Information > Software > Disabled Software".

Answer 3

Adding to your own answer, Elliott, you can then feed this bundle ID to kextutil:

sudo kextutil -b "com.hp.kext.hp-fax-io"

Which will then tell all you ever wanted to know about it including the location of the .kext file:

file:///Library/StagedExtensions/System/Library/Extensions/hp_fax_io.kext/ is in hash exception list, allowing to load
Kext rejected due to system policy: <OSKext 0x7fe302c19730 [0x7fffa5fc38f0]> { URL = "file:///Library/StagedExtensions/System/Library/Extensions/hp_fax_io.kext/", ID = "com.hp.kext.hp-fax-io" }
Code Signing Failure: not code signed
Warnings:
    Personality CFBundleIdentifier differs from containing kext's (not necessarily a mistake, but rarely done):
        HPF00072 FAX - 2
        HPF00006 FAX - 2
[…]

Also it seems you can generally find all those extensions in that directory:

$ ls -la /Library/StagedExtensions/System/Library/Extensions
drwxr-xr-x@ - root 14 Feb  2013 hp_fax_io.kext
drwxr-xr-x@ - root 19 Aug  2013 hp_Inkjet1_io_enabler.kext
drwxr-xr-x@ - root 19 Aug  2013 hp_Inkjet9_io_enabler.kext
drwxr-xr-x@ - root 31 Okt  2014 intelhaxm.kext
drwxr-xr-x@ - root 22 Mai  2012 JMicronATA.kext
drwxr-xr-x@ - root 16 Aug  2012 Pen Tablet.kext
drwxr-xr-x@ - root 23 Jul  2016 SiLabsUSBDriver64.kext
drwxr-xr-x@ - root 23 Jul  2016 Wacom Tablet.kext

Answer 4

I came to this discussion while trying to validate kexts migrated from 10.13 to 10.15 which weren't loading. I seem to have found an explanation and a workaround.

The kexts were valid for 10.15 but hadn't been installed under 10.15, as they arrived with a system migration. I assume the same problem would occur with an OS upgrade. (It goes without saying that I'm deeply disappointed in Apple for not foreseeing this eventuality.)

I came across the following advice regarding installing SATSMART drivers in the FAQ on binaryfruit.com which has some relevance to the question:

How to rebuild macOS kernel extensions/driver cache

When the macOS boots – it saves all currently used kernel extensions (drivers) into a cache for faster booting next time – and if you move things around in “/Library/Extensions/” and “/System/Library/Extensions/” – you won’t see those changes reflected until the caches are rebuilt. Also, due to bugs in some versions of macOS – kext cache becomes outdated or corrupted, especially in the case of system upgrades. Manual kext cache rebuild could fix many troubles with drivers (kernel extensions).

Type in the terminal following commands:

sudo kextcache -i /

sudo kextcache -system-caches

The first command brings up a complete list of kexts that were not loading for a number of reasons - including (but not limited to) Kext rejected due to system policy meaning permission had not been granted in Security & Privacy - along with their locations.

In my experience, kexts blocked for reasons other than needing user approval show up here, even if they don't appear amongst Disabled Software.

Addressing the OPs original question more specifically regarding knowing who the kext developers are, since this may not directly correspond to the software branding, these can be parsed from package inspector apps such as Pacifist and then compared with the kext names output by the terminal command above.

My personal preference is to open an installer package in Suspicious Package, where the developer and their 10 character alphanumeric TeamID are easily readable. For kexts simply awaiting user approval this does, of course, correspond with the TeamID found in Disabled Software, as explained by the OP above. However, not only is this user friendly, it also exposes kexts that won't load for other reasons.

Once the TeamID is known, the kext can safely be approved in Security and Privacy when the blocked kext alert is next shown (eg when installing a different kext).

Not everybody wants to install a new kext in order to approve earlier ones and some sources (such as this MIT knowledge base) advise that a team ID can be granted kext approval via terminal commands in Recovery Mode, but I can't personally verify whether this works in a specific OS.

Answer 5

I don’t have a complete answer, but there are amazing reverse engineering efforts and information sharing that might get you the final piece or a foothold enough to roll your own.

Richard Purves has done amazing work to cover “kextpocalypse” and scripting and most major MDM vendors have specific examples how to push white lists and deal with this user approved kernel extensions.

Also, be aware the behavior isn’t fully set as Apple is refining and changing how this works each release (lately) so YMMV more than usual.

• https://www.richard-purves.com/2017/11/12/kextpocalyse-2-the-remediation/

Michael Lynn also is way above and beyond what I’d expect from a paid consultant putting out powerful scripts and documenting them expertly.

• Querying active SIP status directly from the kernel, bypassing nvram and csrutil, via python on macOS