We’re migrating product documentation to docs.vmware.com, starting with Carbon Black Cloud. Learn more.

macOS 10.13.4 Kext Approval Changes

macOS 10.13.4 Kext Approval Changes

Summary

Our products (as well as other kernel-based products) are running into a situation in which kernel extensions (kexts) are no longer approved. Kexts approved in previous macOS versions by MDM (or other distribution systems like JAMF) are no longer approved once they've upgraded to 10.13.4.

 

This does not seem to impact kexts that were user (locally) approved prior to the 10.13.4 upgrade.

 

Recommendation

Prior to macOS 10.13.4, software distributions systems (i.e. MDM or JAMF) did not require user-approval to load any properly signed kexts. With 10.13.4, user-approval is no longer disabled for software distributions systems. For enterprise deployments where it is necessary to distribute software that includes kexts without requiring user approval, you will need to configure the Apple Team IDs for our Carbon Black products in your MDM profile.

 

Team ID for our products are:

Cb Protection: 7AGZNQ2S2T

Cb Response: 7AGZNQ2S2T

Cb Defense (3.0 and lower):  JA7945SK43

Cb Defense (3.1 and higher): 7AGZNQ2S2T

 

KEXT Bundle IDs for our products are:

 

Cb Protection:

  • com.bit9.b9notifier
  • com.bit9.Kernel
  • com.bit9.KernelSupport
  • com.bit9.SystemProxy
  • com.bit9.KernelKauth

Cb Response:

  • com.carbonblack.CbOsxSensorProcmon
  • com.carbonblack.CbOsxSensorNetmon
  • com.bit9.cbsystemproxy (6.2.3-osx versions and earlier)
  • com.carbonblack.cbsystemproxy.<Major><Minor>fc<Maintenance> (6.2.4-osx versions and later)
    • ex: 6.2.4-osx = com.carbonblack.cbsystemproxy.62fc4

Cb Defense:

  • 3.0 and lower: com.confer.sensor.kext
  • 3.1 and higher: com.carbonblack.defense.kext

 

Please note that the next Cb Defense Mac Sensor release (3.1) will require KEXT approval regardless of previous approval status due to an updated code signing certificate and bundle ID associated with the forthcoming 3.1 release.

 

Please also note that there is new behavior in 10.13.4 after the KEXT approval. A dialog will pop up telling users they need to reboot. This is a proactive measure by Apple. The Cb Defense Mac Sensor will not require a reboot and it will reload its KEXT immediately after the approval is done.

 

We are currently doing more research on this issue and will share any additional information as soon as it becomes available.

Labels (3)
Comments

This post is a bit inaccurate. User-Approved MDM (UAMDM) has been around since 10.13.0. User-Approved Kernel Extension Loading (UAKEL) has similarly been around but kernel extensions present when upgrading to HS were "grandfathered in."

Apple has been telegraphing this change for months: https://developer.apple.com/library/content/technotes/tn2459/_index.html

That document was last updated in September.

Thank you for your note, trademarkable​ .

The problem is, if a product with a KEXT was installed via MDM in an earlier version of 10.13, where all KEXTs are whitelisted, when the user upgrades to 10.13.4, that 'approval' is no longer honored. MDM enrollments prior to 10.13.4 are converted to user-based enrollments, thus generating the prompt.

It is now necessary to include the TeamID for the product that contains the KEXT in the MDM configuration.

More information can be found on Apple’s site at https://support.apple.com/en-us/HT208488

and on a sample MDM vendor’s site at https://www.jamf.com/jamf-nation/discussions/27654/system-extensions-blocked-after-upgrading-to-high...

I hope that helps clarify this a bit.

When adding the Team ID in Apple Profile Manager, custom settings, The preference Domain is "com.apple.syspolicy.kernel-extension-policy" the main Key is "AllowedTeamIdentifiers" as an "Array" type with string values. If "7AGZNQ2S2T" is the String value for "Cb Protection: 7AGZNQ2S2T" mentioned above. Do you know what would the Key value be for this Team ID String in bold?

Configuration Profile Reference

Precisely, yes. Just wanted to make the (slightly snarky) point that this shouldn't have been a surprise for Cb.

As a side note/question:

What will the approval request say in system preferences? What developer will be named as the kext has to be manually approved?

Just putting in the Team Identifier doesn't seem to work for me. Not sure if it's because we are running an old version of MDM. If I put in both the application bundle ID and Team Identifier, it works like a charm.

Could you please share the list of CB bundle IDs?

Hi thefifthavenue​,

Thank you for providing some clarification on this issue. I have added the bundle IDs for Protection and Response to the post above. Thanks!

Will this information be added to all of the User Guides for all of the Carbon Black platforms?  When is that expected?  Is there any reason this was not captured earlier in these User Guides?  I hope Carbon Black is tracking changes with the vendors, and that document was originally posted by Apple 9 months ago.  I also assume Cb tests new OS patches as soon as Apple releases them.  Was this caught by Carbon Black or by a client?

Doing some digging around on formatting of MDM profiles, it seems like it would end up looking like this for Cb Defense. Does this look correct, mclausentsmith​?

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

    <key>AllowUserOverrides</key>

    <false/>

    <key>AllowedTeamIdentifiers</key>

    <array>

        <string>JA7945SK43</string>

    </array>

    <key>AllowedKernelExtensions</key>

    <dict>

        <key>JA7945SK43</key>

        <array>

            <string>com.confer.sensor.kext</string>

        </array>

    </dict>

</dict>

</plist>

Those ID's look good to me, but keep in mind 3.1 for CbD will have a new Team ID

Thanks dbrousseau​,

We appreciate your feedback on this. We will continue to look for a more improved way of providing our Carbon Black Apple Team/Bundle IDs (and similar information) to our users and will strongly consider adding this in the next User Guide versions for each of our Cb products.

Carbon Black continues to beta test new Operating Systems for each of our products as soon as the OS is made available. Any compatibility issues surfaced during our beta testing (or review of documentation) will continue to be communicated out to our users via User Exchange posts as soon as we can provide it.

jthoming​ Please note that currently only the KEXT bundle IDs are required to be configured in the MDM profile (we can drop the daemon, PKG and UI bundle IDs).  Also, the document has been updated to include the Cb Defense 3.1 KEXT Team ID and bundle ID. The proposed MDM profile can include them in preparation for 3.1.

Thank you, adam.malinowski​!

Hello adam.malinowski​, jthoming​,

To summarize both of your useful inputs, does the following MDM profile should work for both 3.0 and 3.1 sensors?

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

  <dict>

    <key>AllowUserOverrides</key>

    <false/>

    <key>AllowedTeamIdentifiers</key>

    <array>

        <string>JA7945SK43</string>

        <string>7AGZNQ2S2T</string>

    </array>

    <key>AllowedKernelExtensions</key>

    <dict>

        <key>JA7945SK43</key>

        <array>

            <string>com.confer.sensor.kext</string>

        </array>

        <key>7AGZNQ2S2T</key>

        <array>

            <string>com.carbonblack.defense.kext</string>

        </array>

    </dict>

  </dict>

</plist>

Regards,

haro

Thanks haro​ for sharing this updated profile.  From Cb Defense perspective, it looks good for both 3.0 and 3.1,  I'm just not too familiar with MDM profiles schema.

ddb

I'm doing a POC with Airwatch.  I've configured the profile and it has landed on the device. However, the kexts are not being whitelisted on the device and i am still getting the error message in System Preferences. Any ideas?

Screen Shot 2018-05-17 at 5.12.25 PM.png

Hi ddb​,

I haven't used AirWatch, but looking at the screenshot, I am wondering if you would also need to add the TeamIDs under the Allowed Team Identifiers section just above the Allowed Kernel Extensions area already filled out. Have you already added them and they just are collapsed on this view? It seems like in relation to the MDM profiles you have to list the allowed TeamIDs first, and then list the allowed TeamIDs and BundleIDs together to show how they relate to each other. Let us know if that helps at all!

ddb

Thank you for your reply. It seems that the profile was fine, there is just a delay of over 30 min from when the profile lands to when the profile authorizes the kext.

Thank you for that clarification, and I'm glad it ended up working for you, ddb​!

Article Information
Author:
Creation Date:
‎04-10-2018
Views:
11845
Contributors