macOS High Sierra 10.13 introduces a new feature that requires user approval before loading newly-installed third-party kernel extensions.

donmontalvo
Esteemed Contributor III

My apologies, this is likely covered by NDA...moving to BETA forum.

Jamf: any way to mask subject to avoid wrath of Apple? :D:D:D

https://www.jamf.com/jamf-nation/discussions/24744/macos-high-sierra-10-13-introduces-a-new-feature-...

--
https://donmontalvo.com
3 ACCEPTED SOLUTIONS

donmontalvo
Esteemed Contributor III

Hot off the press:

Prepare for changes to kernel extensions in macOS High Sierra
https://support.apple.com/en-us/HT208019

--
https://donmontalvo.com

View solution in original post

emily
Valued Contributor III
Valued Contributor III
In macOS High Sierra, enrolling in Mobile Device Management (MDM) automatically disables SKEL. The behavior for loading kernel extensions will be the same as macOS Sierra.

The implication here is that if macOS sees MDM present, it disables SKEL. In a future version, it will be something that MDM can turn on/off/manage and allow whitelisting. I guess we complained loudly enough about it that Apple made some changes.

View solution in original post

bpavlov
Honored Contributor

I think it's relying on the MDM profile.

View solution in original post

65 REPLIES 65

nwiseman
Contributor

[http://blog.eriknicolasgomez.com/2017/07/25/Kextpocalypse-High-Sierra-and-kexts-in-the-Enterprise/](link URL)

I just sent in feedback to Apple and contacted our Apple TAM about this.

I'd say we all need to do the same. Relying on users to "Allow" something we as Admins are trying to install on their systems is a huge concern. If this is the direction Apple wants to go, that's fine, but there needs to be some way for us to continue doing our jobs.

I may not like SEP, but it has to be on my systems. This new feature is going to make that a much bigger problem than it already is.

jhbush
Valued Contributor II

@donmontalvo I don't think you are breaking NDA based on the location of this. Technical Note TN2459
Secure Kernel Extension Loading

donmontalvo
Esteemed Contributor III

Lots of folks are not happy about this...

d3c260b9da464048b744311bc36df183

Done...

f511292c7fa34422950e8853c623e80c

--
https://donmontalvo.com

donmontalvo
Esteemed Contributor III

Hot off the press:

Prepare for changes to kernel extensions in macOS High Sierra
https://support.apple.com/en-us/HT208019

--
https://donmontalvo.com

dgreening
Valued Contributor II

So it sounds like if we have our devices already enrolled in MDM we are good to go? Or are we limited somehow to MDM based distribution?

emily
Valued Contributor III
Valued Contributor III
In macOS High Sierra, enrolling in Mobile Device Management (MDM) automatically disables SKEL. The behavior for loading kernel extensions will be the same as macOS Sierra.

The implication here is that if macOS sees MDM present, it disables SKEL. In a future version, it will be something that MDM can turn on/off/manage and allow whitelisting. I guess we complained loudly enough about it that Apple made some changes.

bazcurtis
New Contributor III

Sorry if this is a silly question. When you say "sees MDM present" does that mean just having the Casper agent installed or the Mac has to be DEP enrolled?

bpavlov
Honored Contributor

I think it's relying on the MDM profile.

bazcurtis
New Contributor III

OK, is there a way in Casper to add these blocked Kernel Extensions via policy or script?

Kaltsas
Contributor III

@bazcurtis

Clients enrolled with an MDM solution revert to 10.12 behavior, there won't be any blocked kexts in 10.13. 10.13 looks at the Mobile Device Management payload for this determination. Currently there is no management per se, other than disabling the functionality by enrolling with MDM. It is expected there will be more functionality added to the MDM framework in the future.

See TN2459 linked above for more information, [https://www.jamf.com/jamf-nation/discussions/24743/macos-high-sierra-10-13-introduces-a-new-feature-that-requires-user-approval-before-loading-newly-installed-third-party-kernel-extensions#responseChild150100](link URL)

donmontalvo
Esteemed Contributor III

(duplicate)

--
https://donmontalvo.com

donmontalvo
Esteemed Contributor III

alexjdale
Valued Contributor III

This is absolutely infuriating. We can't be expected to rely on users to take these actions in order to secure our systems with apps that use kernel extensions. I'm mad enough about MDM being forced down our throats, now it has to be MDM installed by the user?

gachowski
Valued Contributor II

Yep,

Don't think this is going to be easy for Mac Admins.

http://www.openradar.me/35307623

C

Hopefully this will get some more dialogue going and people to reach out to Apple : )

DirkM2012
Contributor

My apologies if the next question is stupid but after enrolling a Mac I see the JSS MDM profile in Profiles but installing McAfee ENS via policy still pops up the message that McAfee must be approved in Settings. Is there anything I have to do in JSS to disable SKEL or do I need to deploy Mcafee via MDM and not via JSS computer policy. If so, any hints on how to deploy a pkg via MDM?

Thanks,
Dirk

emily
Valued Contributor III
Valued Contributor III

So long as the MDM is put in place prior to the installer running there should be no prompt… assuming you are on 10.13.1 or .0. There are changes to this behavior in 10.13.2. If you're unfamiliar I recommend reaching out to your local Apple SE and requesting access to the AppleSeed for IT program.

alexjdale
Valued Contributor III

It's kind of ridiculous they would have a workflow that provides a better result when you upgrade the OS after preparing the system. This entire thing reeks of poor planning and a lack of concern for Enterprise customers.

If I were implementing this, I would have a "first boot only" option where the OS could ingest a config profile file from a specific location and only during the first boot of the OS (so we could use programmatically built DMGs). This profile could disable SKEL (now called UAKEL, apparently) in the same manner as MDM while being secure, since I can only assume they are trying to prevent malware with root access from disabling SKEL silently through an MDM enrollment. Hence the user acceptance requirement.

dgreening
Valued Contributor II

I definitely reached out to our SE on this one. We aren't in a position (huge global company) where DEP is feasible at this point. We also can't have users essentially "opt out" of security settings distributed via Config Profiles. Please raise hell with your SE if you can! Poor planning indeed!

DirkM2012
Contributor

Well, I don't have an Apple SE but I do have about 50 Macs and 5000 Windows computers. If the solution is to wait for 10.13.2 I'm fine with that and will just wait. The low number of Macs doesn't justify a fancy deployment process, so we are just wiping them and reinstall from USB in the field or a NetRestore in my case because it is so much faster. After a fresh OS install they enroll in JSS and get the standard software installed as part of the enrollment. The JSS MDM profile should be part of the enrollment but if a restart is required between installing the MDM and disabling SKEL then that would explain why McAfee still fails to install properly.

I will take McAfee out of the enrollment process and see what happens after the first restart. Is there a shell script that would tell if SKEL is enabled?

alexjdale
Valued Contributor III

I am not aware of a way to check the status of SKEL, but it is a topic I asked about last week: https://www.jamf.com/jamf-nation/discussions/26006/skel-monitoring-reporting-extension-attribute

What I did was create an extension attribute to use kextstat to check on our SEP kexts. If SEP is installed with the process running but the kexts are not loaded, I know there is a problem and it's almost certainly SKEL.

jzeles
New Contributor II

It appears that regular MDM is not going to work to disable SKEL, it must be DEP-initiated SKEL. In fact, MDM itself does not appear to be trusted or functional until the user approves it (unless, again, it was enabled by DEP). I have no idea how this will be supportable in an enterprise environment. Any MDM that is deployed by ANY method other than DEP appears to require user approval. 0e7563eafe0044eabf2c22673fbd9a2b

howie_isaacks
Valued Contributor II

This may sound stupid, but I keep reading and hearing about contacting my Apple SE. I have no Apple SE, so how do we get one? I was just told this by Jamf support, and the rep I spoke to was unable to elaborate. I am a managed service provider, not a member of an IT department of a specific company. My clients purchase their Apple products directly from Apple, and sometimes from resellers. Currently, none of them are using DEP, even though I have been trying to convince the larger clients to get on DEP.

beatlemike
Release Candidate Programs Tester

Yeah, this is a bit ridiculous, and clearly a power grab to try and make sure enterprise is only buying NIB machines, because Apple refurbs can not get DEP, and more than likely purchasing from Apple directly now.

I love DEP, but we have tons of machines already in use from before we began purchased with it and as a large university, I can't control where our departments purchase from, nor can I blame them for saving money on refurbished items. But now we have to handhold the setup of every non DEP machine beyond just convincing the unenlightened user to just install this "quickadd" thing without asking questions.

Fun stuff.

gachowski
Valued Contributor II

@beatlemike

I don't think it's about money at all... I bet in a year or so you will be able to add macs to DEP just like you can do now with iPhones... I think it's about security ... yes it's a pain but in a year or two the MacOS will be significantly more secure.

C

beatlemike
Release Candidate Programs Tester

@gachowski and in the meantime... we are left with this. This isn't a year or two in the future this is now. And just because I may be able to add Macs to DEP, won't change the fact that to do so to a deployed machine will mean I will have to wipe it, and even to attempt so means prying it from the cold dead hands of faculty and staff who already have them in the wild.

More secure, sure, assuming no more processor flaws or 0day kernel flaws rear their ugly head at that time lol.

You have far more trust in the intentions of corporate America than I, clearly, but this is an issue in the here and now, not the future. My Apple SE is great, but even he said there is nothing to really be done, that's just the state of security on the Mac now.

howie_isaacks
Valued Contributor II

Since I and my coworkers personally touch each Mac as it's being enrolled using a quickadd package, this has not been as horrible as I thought it would be. The only annoyance has been that I scope a configuration profile that blocks the Profiles preference pane from being opened, so we have to wait to deploy the configuration profile after we have approved the MDM profile.

I asked earlier in this thread how someone goes about getting an Apple SE. I would really appreciate it if someone could answer that question. People keep telling me to talk to my Apple SE and I don't have one!

beatlemike
Release Candidate Programs Tester

@howie_isaacks We do the same with the preference pane blocking, and I had to change how it is deployed as well. With machines were my team sets them up, this is not an issue, however we could never get to all our older machines if that was the only way to enroll them.

Being an education institution we just have always had an SE. That's all I've worked for since I left Apple. I couldn't tell you were to start to get one, wouldn't hurt to call Apple yourself.

TexasITAdmin
New Contributor III

Any solutions on this?
I'm testing 10.13 now before we do a district wide refresh this summer and running across this problem that after imaging I have to log in and manually "Approve" the config profiles.
I tried DEP but for these graphic design computers we really need all the Adobe and video editing software PRE-INSTALLED before it ever gets to the students so a netboot and configuration task sequence is the best way to push this all at once.

cwaldrip
Valued Contributor

You can manage them through an MDM profile. Not sure if Jamf 10 supports that just yet (I'm still on 9 and we're not deploying 10.13 yet)

donmontalvo
Esteemed Contributor III

Managing KEXT white listing isn't limited to JSS 10.x.

We're hoping Jamf Pro 10.4 (long ways away) will inventory KEXT across the macOS computer, so the data can be used to create a white list within Jamf Pro. #shinyButton

No need to wait though, since you're able to use a Configuration Profile with a KEXT whitelist using TeamID (vendor) or TeamID and BundleID (vendor and KEXT).

  • If you whitelist by TeamID (vendor), then all BundleIDs (KEXT) for the vendor are whitelisted.
  • If you whitelist by TeamID and BundleID, every KEXT from that vendor that you want to allow will need to be included in the whitelist. Every. Single. One. Else, any non whitelisted KEXT for that vendor will not load.

We've been working on...

  1. Create whiltelist on a computer using @franton's awesome script, which creates an XML you can import into a Configuration Profile (Custom Settings).

  2. Use @henryxyz's sqlite3 command to list of TeamID/BundleID for KEXTs that have been approved (User Approved Kernel Extension Loading) and save as CSV. From there, you'll have a way to collaborate/share the list with your colleagues, and Security who may be tasked with approving KEXTs now that it's a security thing.

  3. Open a ticket with Jamf to see if we can import a TeamID/BundleID into a Configuration Profile using API...if so, we can update the CSV and re-upload to globally allow the KEXTs. #aGuyCanDream

  4. Make a lot of coffee (Bustello por favor...varoom!!! 🏍🏍🏍️ ), and try to come up with a script that can merge the CSVs in #3. Hoping it's as simple as I think it should be.

Script to pull a list of TeamID/BundleID for KEXTs that have been approved (User Approved Kernel Extension Loading):

#!/bin/sh
# Stealing @henry123's (Jamf Nation) command to compile list of TeamID/BundleID for KEXTs that have been approved (User Approved Kernel Extension Loading). 20180313 DM

# Create folder
/bin/mkdir -p /Library/Company/SearchResults/
/usr/sbin/chown root:admin /Library/Company/SearchResults/
/bin/chmod 755 /Library/Company/SearchResults/

# Get list

/usr/bin/sqlite3 -csv /var/db/SystemPolicyConfiguration/KextPolicy "select team_id,bundle_id from kext_policy" > /Library/Company/SearchResults/checkKEXTs.csv

exit 0

EA to display the CSV created by the above script...yea...we know line returns are bonked in EAs...but for what it's worth:

#!/bin/sh

folder=/Library/Company/SearchResults
file=checkKEXTs.txt
list=$( cat ${folder}/${file} )

if [[ ${list} == "" ]]; then
    echo "<result>"NoResult"</result>"
else
    echo "<result>"${list}"</result>"
fi

The CSV would look like this (heavily redacted/sanitized) when you cat it:

# cat /Library/Company/SearchResults/checkKEXTs.csv 
4C6364ACXT,com.parallels.kext.hypervisor
4C6364ACXT,com.parallels.kext.netbridge
4C6364ACXT,com.parallels.kext.usbconnect
4C6364ACXT,com.parallels.kext.vnic
6HB5Y2QTA3,com.hp.kext.io.enabler.compound
EG7KH642X6,com.vmware.kext.vmci
EG7KH642X6,com.vmware.kext.vmioplug.15.2.1
EG7KH642X6,com.vmware.kext.vmnet
EG7KH642X6,com.vmware.kext.vmx86
GT8P3H7SPW,com.McAfee.AVKext
GT8P3H7SPW,com.McAfee.FMPSysCore
GT8P3H7SPW,com.McAfee.SFKext
GT8P3H7SPW,com.McAfee.kext.AppProtection

Jamf Pro would display that file (list) in an EA like this:

4C6364ACXT,com.parallels.kext.hypervisor 4C6364ACXT,com.parallels.kext.netbridge 4C6364ACXT,com.parallels.kext.usbconnect 4C6364ACXT,com.parallels.kext.vnic 6HB5Y2QTA3,com.hp.kext.io.enabler.compound EG7KH642X6,com.vmware.kext.vmci EG7KH642X6,com.vmware.kext.vmioplug.15.2.1 EG7KH642X6,com.vmware.kext.vmnet EG7KH642X6,com.vmware.kext.vmx86 GT8P3H7SPW,com.McAfee.AVKext GT8P3H7SPW,com.McAfee.FMPSysCore GT8P3H7SPW,com.McAfee.SFKext GT8P3H7SPW,com.McAfee.kext.AppProtection

Off to do #3 and #4...I'm good until the Bustelo wears off...

HTH
Don

--
https://donmontalvo.com

alexjdale
Valued Contributor III

Has anyone successfully managed the kext whitelist using a custom profile payload? I've only been able to do it with 10.2.2 since it offers it natively, but 9.101.4 just won't work. The profile is installed by user-approved MDM but it just isn't taking effect.

PhillyPhoto
Valued Contributor

I'm just trying to wrap my head around this issue. So 10.13.* now requires users to let kernel extensions to be enabled. This behavior can be bypassed by enrolling the device in an MDM, or installing a config profile with a payload whitelisting teams or specific Kexts, but you don't need both, correct? I've had no need to install the white list profile and my AV software installs fine when building devices. So my question is, the whitelisting would only be for devices you don't want to enroll completely in the MDM for some reason?

When I run the script @donmontalvo posted above, I don't get any results, since they were installed via policy on an MDM-enrolled device. Even looking directly at the kext_policy DB, it's empty:

5ff8be25745849e09f9c19a033be0628

If I run the script from Richard Purves' blog, I see all my kexts that are actually installed.

For those of us enrolling our devices in the MDM, is this just to prepare us for when Apple finally transitions everyone over to having to whitelist kexts regardless of MDM enrollment? I just want to make sure I'm not misunderstanding the issue and not configuring devices correctly.

gachowski
Valued Contributor II

@PhillyPhoto

The only "bypass" for this (SKEL) is DEP. Jamf's new 10.3 Profile enrollment process still require a whitelist config profile. I think most places are going to need both DEP and a whitelist config profile as DEP won't work everywhere.

C

dgreening
Valued Contributor II

@gachowski In my testing it looks like non-DEP MDM profile based (instead of QuickAdd) User Initiated Enrollment (in 10.3) produces UAMDM, and as such the SKEL config profile is allowed to be installed like any other profile would be at enrollment, and before any apps which need it are installed.

gachowski
Valued Contributor II

Yep, that is what I was trying to say... : ) sorry while english is my 1st language typing and writing are not . : )

C

KyleEricson
Valued Contributor II

I created a profile for Sophos AV and it doesn't do anything. This is a non-DEP mac where I approved the MDM profile.

Read My Blog: https://www.ericsontech.com

allanp81
Valued Contributor

@kericson Have you checked on the management for the device in the JSS? In my environment it fails to install the kext policy because the MDM profile needs user acceptance. Even after approving MDM the config profile stays under a failed status and therefore never applies to the machine until I go in and manually clear the error.

As it is I can't see how we can roll out High Sierra in this state. We don't use DEP and are unlikely to for general imaging of our mac rooms.

KyleEricson
Valued Contributor II

I checked and it installs fine without any issues just doesn't do anything.35baf4f1a2e54c9b802152011e13344b

Read My Blog: https://www.ericsontech.com

PhillyPhoto
Valued Contributor

I've tested upgrading a device to 10.13.4 and then installing the kext profile. Even with approving the MDM profile and seeing the correct whitelist profile get installed and finally rebooting, I still get prompted to allow kernel extensions. What's the point of this whitelist profile if it doesn't actually work?