macOS KEXT whitelisting teamid / bundle id using a profile

Did you try this script from @franton ?
https://www.jamf.com/jamf-nation/discussions/26583/kextpocalyse-2-the-remediation-blog-post-by-our-own-franton

My script as linked will generate a plist based on the current configuration of your Mac. You can then upload that into a custom profile in Jamf. Job's a good one.

Can someone talk me off the ledge here, I’m starting to freak out!

I’m curious to know what strategy folks are considering to combat this impending chaos?
Clearly we need to create and pre-deploy a whitelist profile. And @franton your scripts to identify installed kext’s (on a given machine) and build a plist are most excellent and super helpful.

However, spot checking a few machines is simply not going to cut it for any of us with more than a few dozen Macs. How in the world are we supposed to identify the stuff we need to whitelist from all over a large fleet?

At minimum, using franton’s script, my average machine is reporting back about 20 kexts. I know McAfee, Wacom, and Citrix are in scope for me; but there are others that I have no clue what they are, and others I suspect Apple installed (third party) and would expect to not need explicit whitelisting (since Apple installed them, right ?)

Stuff like this, I have no idea what to do with, not everything seems to be throwing an alert.

Team ID: K3TDMD9Y6B  Bundle ID: com.Accusys.driver.Acxxx
Team ID: 34JN824YNC  Bundle ID: com.Areca.ArcMSR
Team ID: EG27766DY7  Bundle ID: com.FTDI.driver.D2XXHelper
Team ID: DX6G69M9N2  Bundle ID: com.highpoint-tech.kext.HighPointRR

Two options I see, which both suck big time… whitelist every damn kext you can find in your environment or set up a war room to receive complaints, research and review, add to whitelist reactively.

What are you going to do?

I'm not going to whitelist anything that a user installs on their own. If they want it, they will authorize the kext to load.

The only concern I have is our security stack, which a user does not necessarily need or want, and cannot be relied upon to authorize. So my scope is simply those kexts.

If it's not throwing an alert, it's because it doesn't need to be authorized. The kexts you are listing are also on every Mac we have (storage drivers, for example), and I'm assuming they are part of the OS and already allowed to load by Apple.

Our approach has been a mix of using @franton's awesome script (for full inventory of all KEXTs on a system), as well we posted a way we are able to list KEXTs that have been approved on the system:

KEXT inventory data

We have compiled a CSV of all TeamID (vendors), and are working on getting them injected into an array in an XML that can be then imported into a Configuration Profile (whitelist)...this way we can easily update/deploy the updated whitelist.

Unless of course our superhero nerd @franton gets to it first. :)

Hey,

I might have missed something but I used @franton's awesome script to extract the format of the required plist, kept only the main software that needed approval and pushed that to our JSS (9.101.4) in a custom configuration profile. I then pushed said profile to a machine that hadn't updated yet, updated that machine only to find the KEXTs hadn't been approved.

Is that down to the old JSS version or did I actually miss something?

Thanks again @franton for the awesome script.

@franton is awesome and his script rocks!

We currently need to wrangle a CSV Of our User Approved Kernel Extension Loading (approved) KEXTs into a whitelist. We automated that process so far.

His script does a lot more, but in our case we have a CSV containing a single column of TeamIDs, compiled using a script and an EA.

Looking for a programmatic way to get that into an array within an XML that then is brought into a Config Profile.

The intent is to manage the whitelist going forward. All is automagicated, except for that last step.

Our dev team is tied up, and I’m not sure how to do that thing.

@alexjdale wrote:

I'm not going to whitelist anything that a user installs on their own. If they want it, they will authorize the kext to load.

Is that going to be possible now with 10.13.4?

@donmontalvo wrote:

I'm not going to whitelist anything that a user installs on their own. If they want it, they will authorize the kext to load. Is that going to be possible now with 10.13.4?

Isn't the an option to allow users to accept kexts? The "AllowUserOverrides" boolean in the plist I believe, hopefully I understood your question correctly.

For me, reality has not shown whitelisting being effective. I whitelisted the kexts in my environment, and install the config profile (both the one created in my JSS - version 10.2, and uploading the plist file to the custom payload) on my test devices. When I either upgrade to 10.13.4 or it gets installed on an existing machine, I still get the "Allow" button in Security & Privacy for some kexts. The ones that every machine gets and I see all the time are Symantec and CrowdStrike. I only whitelisted by Team ID, and not specific kexts, so everything should go through. I even got an email from CrowdStrike today and verified the Team ID they sent is what I had already. I'm not using DEP yet, if that makes a difference.

On a side note, in case anyone else runs in to it, the MDM Profile has to be accepted physically on the machine in order for the config profile with the kext whitelist payload to be able to be installed. Also, the "Allow" button in System Preference > Security & Privacy has to be clicked on the physical machine as well, remote connections don't work.

just got this from jamf rep. works well.

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

just got this from jamf rep. works well.

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

@jalcorn Your link to the richard-purves site is by the same person that authored the script that is here: Kextpocalyse 2: The Remediation Blog post by our own @franton

It's my understanding that the script that @franton has on JamfNation is newer than what he posted on his website. I haven't done a compare, but it is stated in the Jamfnation post. You might want to try out the newer script.

Still trying to wrap my head around this. I used the @franton script to generate a plist

I put that plist into a configuration profile and pushed to machine before that machine has the software -

As a test I the reboot the machine - and then run franton script and it does not show the ones in the whitelist plist

@bwiessner Same boat, well almost... it looks like your JSS is already on 10 and if you are on 10.2+ then you should have the payload for Kernel Extension Policy so that'd be the way to go instead of a Custom Payload

However for those still on 9.101 (I am for a few more weeks (long story)) I've tried the Custom Payload method and not having any luck, tried using the Team ID only (preferable it seems) and even the Team ID+Bundle IDs method to test, toggled AllowUserOverrides true/false, ensured the domain is com.apple.syspolicy.kernel-extension-policy ... and still getting a pop-up to Allow the kext on a Mac with a User Accepted MDM Mac and the CP installed prior to installation of the kext (Sophos and Parallels)

Anyone else having issues try to hack together a Kernel Extension Policy as a custom payload on JSS 9.101?

This is the super simple payload for Sophos and it is not working for Sophos AV (9.62 that autoupdates to 9.67 after install)

Anyone see a glaringly obvious TL;DR mistake on my part!?

Would really suggest getting off Jamf Pro 9.x and onto Jamf Pro 10.x, as it’s only going to get worse from here.

Thanks "Captain Obvious" @donmontalvo har har ;]

It's been the usual waiting game to let the bugs shake out, seeing Jamf fix MDM bugs that caused massive CPU usage has been vindicating. I think of an alternate universe where I installed earlier v10 releases and had a lot more unplanned emergency rollbacks/upgrades of the JSS and overall less than ideal mornings.

So as I tested the v10.13.1 upgrade from 9.101 with a replica database on a test box (it all went well), I made a Kernel Extension Payload and downloaded it as a mobileconfig. Since it had the same certs as the production boxen it was a bona fide signed and trusted config profile.

It seems Apple has locked down the ability to install kernel extension payloads as as a .configprofile file even if signed by the same MDM server and even if the MDM is User Accepted. Apparently it must "originate from" the MDM server and not as a downloaded file, either... so there you go for anyone wondering if it was possible to hang onto v9 any longer and cheat with v10 created payloads. Uh uh.

edit answered my original question by reimagine the machine and seeing if it worked

Have a new one! Is it better to have one monolithic config profile with every application imaginable or better to have a bunch of smaller ones (in case of changes/updates)?

+1 @jwojda 's question. I was hoping to get some advice on the same thing

I would say to put them all into one, assuming every user gets the same profile. If you need to grant different whitelists to different users, then I would break them down logically along those lines.

@PhillyPhoto you specifically mentioned Crowdstrike and Symantec, and those are the two applications that I'm most concerned with in terms of KEXTs. I created a Configuration Profile in JSS 10.2.2 (we've since upgraded to 10.3.1) for approved KEXTs and entered the following:

When I first booted the computer before creating the Config Profile it gave an error message that KEXTs needed to be approved, after applying the Config Profile and restarting the computer I didn't get the message again so I assumed everything was okay. As far as I know Crowdstrike is working, but if I open SEP there's a message that says "Kernel extensions need authorization."

Were you able to find a way to get this working?

@el2493 Playing around a bit, it seems like the whitelist needs to be installed on the device before you install any software that applies a kernel extension too. I was testing a DEP workflow and before I applied the whitelist to my smart group containing my prestage enrollment devices, it ran through the DEP enrollment and policies fine, but I got the message about the blocked KEXTs. I changed the scope to include the prestage enrollment machines, wiped the device and reinstalled a fresh copy of 10.13.4, and now the whitelist and MDM profile are on the device as soon as I create the user account and sign on for the first time. The DEP enrollment policy kicks in and I never get warnings about the KEXTs when the software gets installed.

So, I believe I'll be pushing the whitelist out to every device and work with customers who need to approve the MDM Profile in those limited cases. This behavior seems to line up with what I've seen with my traditional imaging workflow and having the whitelist installed prior to installing software.

I wish Apple would make the whitelist retroactive and apply immediately once the profile is installed, but I won't hold my breath.

On a side note, I'm whitelisting just the Team ID, and not bothering with the specific packages as those may change in the future.

After removing the individual Approved Kernel Extensions for Symantec (leaving just the Team ID) and restarting the computer, everything seems to be working. If I do kextstat|grep sym it comes up with 3 items rather than the 4 I was expecting, but if I open SEP it no longer says that anything needs authorization.

Hi All,

Nice and informative thread here.

I'm still fighting with KEXTs here, it and seems not working for me at all. Our macs are not DEP, but MDM profiles are manually approved.

Can someone confirm if it really mandatory to have KEXT whitelist profile installed before deploying any software which includes those whitelisted KEXTs?

I'm running on JAMF PRO 10.2.2 and using inbuilt KEXT profile payload.

Also the setting "Allow users to approve kernel extensions" does not do anything at all, ticked/unticked users still can approve KEXTs..

@Rokas you might first consider that a whitelist needs to be managed by the MDM solution the computer is enrolled in...manually installing a whitelist no worky.